Jump to: navigation, search

BGP LS PCEP:Lithium Operations Guide

BGP

Inserting routes

The only RESTCONF operation in BGP is population the RIB of application peer. First you have to configure your application peer. Check the User Guide on how to do that. If your peer is configured, you can populate the RIB in various ways, for example, by making following POST call to RESTCONF:

RESTCONF URL : http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/

Method: POST

Sample input: for Content-Type: application/xml

 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
   <prefix>1.1.1.1/32</prefix>
   <attributes>
    <ipv4-next-hop>
     <global>199.20.160.41</global>
    </ipv4-next-hop><as-path/>
    <multi-exit-disc>
     <med>0</med>
    </multi-exit-disc>
    <local-pref>
     <pref>100</pref>
    </local-pref>
    <originator-id>
     <originator>41.41.41.41</originator>
    </originator-id>
    <origin>
     <value>igp</value>
    </origin>
    <cluster-id>
     <cluster>40.40.40.40</cluster>
    </cluster-id>
   </attributes>
  </ipv4-route>

This will append your route to existing ones.

Inserting flowspec routes:

RESTCONF URL : http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes

Method: POST

Sample input: for Content-Type: application/xml

  1.     <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
  2.       <route-key>bar</route-key>
  3.       <flowspec>
  4.         <destination-prefix>192.168.0.1/32</destination-prefix>
  5.         <component-type>destination-prefix</component-type>
  6.       </flowspec>
  7.       <flowspec>
  8.         <source-prefix>10.0.0.1/32</source-prefix>
  9.         <component-type>source-prefix</component-type>
  10.       </flowspec>
  11.       <flowspec>
  12.         <protocol-ips>
  13.           <op>equals end-of-list</op>
  14.           <value>6</value>              
  15.         </protocol-ips>
  16.         <component-type>protocol-ip</component-type>
  17.       </flowspec>
  18.       <flowspec>
  19.         <ports>
  20.           <op>equals end-of-list</op>
  21.           <value>80</value>
  22.         </ports>
  23.         <component-type>port</component-type>
  24.       </flowspec>
  25.       <flowspec>
  26.         <destination-ports>
  27.           <op>greater-than</op>
  28.           <value>8080</value>
  29.         </destination-ports>
  30.         <destination-ports>
  31.           <op>and-bit less-than end-of-list</op>
  32.           <value>8088</value>
  33.         </destination-ports>
  34.         <component-type>destination-port</component-type>
  35.       </flowspec>
  36.       <flowspec>
  37.         <source-ports>
  38.           <op>greater-than end-of-list</op>
  39.           <value>1024</value>
  40.         </source-ports>
  41.         <component-type>source-port</component-type>
  42.       </flowspec>
  43.       <flowspec>
  44.         <types>
  45.           <op>equals end-of-list</op>
  46.           <value>0</value>
  47.         </types>
  48.         <component-type>icmp-type</component-type>
  49.       </flowspec>
  50.         <flowspec>
  51.         <codes>
  52.           <op>equals end-of-list</op>
  53.           <value>0</value>
  54.         </codes>
  55.         <component-type>icmp-code</component-type>
  56.       </flowspec>
  57.       <flowspec>
  58.         <tcp-flags>
  59.           <op>match end-of-list</op>
  60.           <value>32</value>
  61.         </tcp-flags>
  62.         <component-type>tcp-flags</component-type>
  63.       </flowspec>
  64.       <flowspec>
  65.         <packet-lengths>
  66.           <op>greater-than</op>
  67.           <value>400</value>
  68.         </packet-lengths>
  69.         <packet-lengths>
  70.           <op>and-bit less-than end-of-list</op>
  71.            <value>500</value>
  72.         </packet-lengths>
  73.         <component-type>packet-length</component-type>
  74.       </flowspec>
  75.       <flowspec>
  76.         <dscps>
  77.           <op>equals end-of-list</op>
  78.           <value>20</value>
  79.         </dscps>
  80.         <component-type>dscp</component-type>
  81.       </flowspec>
  82.       <flowspec>
  83.         <fragments>
  84.           <op>match end-of-list</op>
  85.           <value>first</value>
  86.         </fragments>
  87.         <component-type>fragment</component-type>
  88.       </flowspec>
  89.       <attributes>
  90.         <origin>
  91.           <value>igp</value>
  92.         </origin>
  93.         <as-path/>
  94.         <local-pref>
  95.           <pref>100</pref>
  96.         </local-pref>
  97.         <extended-communities>
  98.           <comm-type>128</comm-type>
  99.           <comm-sub-type>7</comm-sub-type>
  100.           <traffic-action-extended-community>
  101.             <sample>true</sample>
  102.             <terminal-action>false</terminal-action>
  103.           </traffic-action-extended-community>
  104.         </extended-communities>
  105.       </attributes>
  106.     </flowspec-route>

Details:

  • 4-7: destination 192.168.0.1/32
  • 8-11: source 10.0.0.1/32
  • 12-18: protocol 6 (TCP)
  • 19-25: port =80
  • 26-36: destination-port >8080&<8088
  • 37-43: source-port >1024
  • 44-50: icmp-type =0 (for ICMP protocol only)
  • 51-57: icmp-code =0 (for ICMP protocol only)
  • 58-64: tcp-flags 32 (URGENT) [URG=32, ACK=16, PSH=8, RST=4, SYN=2, FIN=0]
  • 65-75: packet-length >400&<500
  • 76-82: dscp 20
  • 83-89: fragment first [first, last, is-a, do-not]

BGP-FS Extended-Communities:

  1.   <extended-communities>
  2.     <comm-type>128</comm-type>
  3.     <comm-sub-type>6</comm-sub-type>
  4.     <traffic-rate-extended-community>
  5.       <informative-as>123</informative-as>
  6.       <local-administrator>0</local-administrator>
  7.     </traffic-rate-extended-community>
  8.   </extended-communities>
  9.  
  10.   <extended-communities>
  11.     <comm-type>128</comm-type>
  12.     <comm-sub-type>7</comm-sub-type>
  13.     <traffic-action-extended-community>
  14.       <sample>true</sample>
  15.       <terminal-action>false</terminal-action>
  16.     </traffic-action-extended-community>
  17.   </extended-communities>
  18.  
  19.   <extended-communities>
  20.     <comm-type>128</comm-type>
  21.     <comm-sub-type>8</comm-sub-type>
  22.     <redirect-extended-community>
  23.       <global-administrator>123</global-administrator>
  24.       <local-administrator>AAAAew==</local-administrator>
  25.     </redirect-extended-community>
  26.   </extended-communities>
  27.  
  28.   <extended-communities>
  29.     <comm-type>128</comm-type>
  30.     <comm-sub-type>9</comm-sub-type>
  31.     <traffic-marking-extended-community>
  32.       <global-administrator>20</global-administrator>
  33.     </traffic-marking-extended-community>
  34.   </extended-communities>

Description:

  • traffic-rate: 123 (2-octet AS) / 0 (discard) [encoded non-zero Bps value]
  • traffic-action: true (sample) / false (terminal-action)
  • redirect: 123 (2-octet AS) / AAAAew== (0x00 00 00 7b -> 123)
  • traffic-marking: 20 (DSCP value)

Removing routes

To remove all routes from application RIB (no XML input needed):

RESTCONF URL : http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/

Method: DELETE

To remove one route from application RIB (no XML input needed):

RESTCONF URL : http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/bgp-inet:ipv4-route/prefix-id

- where prefix-id is the value of <prefix> tag in the input, where '/' is replaced by '%2F', eg. '1.2.3.4/32' will result in '1.2.3.4%2F32'

Method: DELETE

PCEP

Programming tunnels through PCEP is one of the key features of PCEP implementation in OpenDaylight. User can create, update and delete tunnel via RESTCONF calls. Tunnel (LSP - Label Switched Path) arguments are passed through RESTCONF and generate a PCEP message that is sent to PCC (which is also specified via RESTCONF call). PCC sends a response back to ODL. The response is then interpreted and sent to RESTCONF, where, in case of success, the new LSP is displayed.

Following is an example how a stateful initiated PCEP session RESTCONF output looks like:

http://localhost:8181/restconf/operational/network-topology:network-topology/topology/pcep-topology

  1.  <node>
  2.   <path-computation-client>
  3.   <state-sync>synchronized</state-sync>
  4.   <stateful-tlv>
  5.    <stateful>
  6.     <initiation>true</initiation>
  7.     <lsp-update-capability>true</lsp-update-capability>
  8.    </stateful>
  9.   </stateful-tlv>
  10.   <ip-address>43.43.43.43</ip-address>
  11.   </path-computation-client>
  12.   <node-id>pcc://43.43.43.43</node-id>
  13.  </node>

If your output does NOT match the above sample (especially the two flags) DO NOT proceed with tunnel management, as your configuration needs to be adjusted. Consult Troubleshooting sites.

Tunnel Management for draft-ietf-pce-stateful-pce-07 and draft-ietf-pce-pce-initiated-lsp-00

Before proceeding, read carefully drafts draft-ietf-pce-stateful-pce-07 and draft-ietf-pce-pce-initiated-lsp-00 to learn about the user-input values in this section.

Creating LSP

An LSP in PCEP can be created in one or two steps. Making an add-lsp operation will trigger a Pcinitiate message to PCC.

Each RESTCONF operations call requires some xml input that is send via HTTP POST method. Whenever you are sending an xml input, set up HTTP header Content-Type: application/xml.

RESTCONF URL : http://localhost:8181/restconf/operations/network-topology-pcep:add-lsp

Method: POST

Content-Type: application/xml

Sample input:

  1. <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
  2.  <node>pcc://43.43.43.43</node>
  3.  <name>update-tunel</name>
  4.  <arguments>
  5.   <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
  6.    <delegate>true</delegate>
  7.    <administrative>true</administrative>
  8.   </lsp>
  9.   <endpoints-obj>
  10.    <ipv4>
  11.     <source-ipv4-address>43.43.43.43</source-ipv4-address>
  12.     <destination-ipv4-address>39.39.39.39</destination-ipv4-address>
  13.    </ipv4>
  14.   </endpoints-obj>
  15.   <ero>
  16.    <subobject>
  17.     <loose>false</loose>
  18.     <ip-prefix><ip-prefix>201.20.160.40/32</ip-prefix></ip-prefix>
  19.    </subobject>
  20.    <subobject>
  21.     <loose>false</loose>
  22.     <ip-prefix><ip-prefix>195.20.160.39/32</ip-prefix></ip-prefix>
  23.    </subobject>
  24.    <subobject>
  25.     <loose>false</loose>
  26.     <ip-prefix><ip-prefix>39.39.39.39/32</ip-prefix></ip-prefix>
  27.    </subobject>
  28.    </ero> 
  29.  </arguments>
  30.  <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
  31. </input>

Details:

  • 2: node : specifies node-id of the PCC, where you want to send the PCEP message. PCEP states that the PCC recieving this message needs to be set as the source of the LSP, otherwise it will ignore the <source-ipv4-address> tag and create a tunnel with the PCC set as source. This node-id can be found when listing all the PCC connected to ODL: http:/localhost:8181/restconf/operational/network-topology:network-topology/topology/pcep-topology
  • 3: name : name of the LSP
  • 4: arguments : LSP arguments
  • 5: lsp : LSP Object mandatory, you have to specify at least delegate and administrative flags
  • 9: endpoints-obj : Endpoints object, mandatory, stating the source and destination of the LSP
  • 15: ero : Explicit Route Object, mandatory, specifies hops between source and destination nodes (in this order). This object can be also passed in arguments when creating LSP. Note: ODL does NOT change order of hops, nor does it validate them, therefore user is responsible for putting correct hops in correct order.

Updating LSP

Making an update-lsp operation will trigger a Pcupd message to PCC. Updating can be used to change or add additional information to the LSP.

You can only successfully update an LSP if you own the delegation. You automatically own the delegation, if you've created the LSP. You don't own it, if another PCE created this LSP. In this case PCC is only reporting this LSP for you, as read-only (you'll see <delegate>false</delegate>). However ODL won't restrict you from trying to modify the LSP, but you will be stopped by receiving a Pcerr message from PCC.

To revoke delegation, don't forget to set <delegate> to true.

RESTCONF URL : http://localhost:8181/restconf/operations/network-topology-pcep:update-lsp

Method: POST

Content-Type: application/xml

For each update, ERO object is mandatory.

Minimal update-lsp sample input:

  1. <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
  2.  <node>pcc://43.43.43.43</node>
  3.  <name>update-tunel</name>
  4.  <arguments>
  5.  <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
  6.    <delegate>true</delegate>
  7.    <administrative>true</administrative>
  8.  </lsp>
  9.  <ero>
  10.    <subobject>
  11.     <loose>false</loose>
  12.     <ip-prefix><ip-prefix>200.20.160.41/32</ip-prefix></ip-prefix>
  13.    </subobject>
  14.    <subobject>
  15.     <loose>false</loose>
  16.     <ip-prefix><ip-prefix>196.20.160.39/32</ip-prefix></ip-prefix>
  17.    </subobject>
  18.    <subobject>
  19.     <loose>false</loose>
  20.     <ip-prefix><ip-prefix>39.39.39.39/32</ip-prefix></ip-prefix>
  21.    </subobject>
  22.    </ero> 
  23.  </arguments>
  24.  <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
  25. </input>

Details:

  • 2: node : specifies node-id of the PCC, where you want to send the PCEP message. PCEP states that the PCC recieving this message needs to be set as the source of the LSP, otherwise it will ignore the <source-ipv4-address> tag and create a tunnel with the PCC set as source. This node-id can be found when listing all the PCC connected to ODL: http:/localhost:8181/restconf/operational/network-topology:network-topology/topology/pcep-topology
  • 3: name : name of the LSP
  • 4: arguments : LSP arguments
  • 5: lsp : LSP Object mandatory, you have to specify at least delegate and administrative flags
  • 9: ero : Explicit Route Object, mandatory, specifies hops between source and destination nodes (in this order). This object can be also passed in arguments when creating LSP. Note: ODL does NOT change order of hops, nor does it validate them, therefore user is responsible for putting correct hops in correct order.

Removing LSP

Removing LSP from PCC is done via following RESTCONF URL. Making a remove-lsp operation will trigger a Pcinitiate message to PCC, with remove-flag in SRP set to true.

You can only successfully remove an LSP if you own the delegation. You automatically own the delegation, if you've created the LSP. You don't own it, if another PCE created this LSP. In this case PCC is only reporting this LSP for you, as read-only (you'll see <delegate>false</delegate>). However ODL won't restrict you from trying to remove the LSP, but you will be stopped by receiving a Pcerr message from PCC.

RESTCONF URL : http://localhost:8181/restconf/operations/network-topology-pcep:remove-lsp

Method: POST

Content-Type: application/xml

Sample input:

  1. <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
  2.  <node>pcc://43.43.43.43</node>
  3.  <name>update-tunel</name>
  4.  <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
  5. </input>

Details:

  • 2: node : specifies node-id of the PCC, where you want to send the PCEP message. This node-id can be found when listing all the PCC connected to ODL: http:/localhost:8181/restconf/operational/network-topology:network-topology/topology/pcep-topology
  • 3: name : name of the LSP that you want to remove

Tunnel Management for draft-ietf-pce-segment-routing-01

draft-ietf-pce-segment-routing-01 PCEP extension for Segment Routing

Extends draft-ietf-pce-stateful-pce-07 and draft-ietf-pce-pce-initiated-lsp-00, brings new SR-ERO subobject composed of SID (Segment Identifier) and/or NAI (Node or Adjacency Identifier). Segment Routing path is carried in the ERO object, as a list of SR-ERO subobjects ordered by user. The draft redefines format of messages (PCUpd, PCRpt, PCInitiate) - along with common header, they can hold SPR, LSP and SR-ERO (containing only SR-ERO subobjects) objects.

Note: Values used in sample inputs below are illustrative.

Create Segment Routing LSP

Making an add-lsp operation will trigger a Pcinitiate message to PCC.

RESTCONF URL : http://localhost:8181/restconf/operations/network-topology-pcep:add-lsp

Method: POST

Content-Type: application/xml

Sample input:

  1. <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
  2.  <node>pcc://43.43.43.43</node>
  3.  <name>update-tunnel</name>
  4.  <arguments>
  5.    <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
  6.     <delegate>true</delegate>
  7.     <administrative>true</administrative>
  8.    </lsp>
  9.    <path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
  10.     <pst>1</pst>
  11.    </path-setup-type>
  12.    <ero>
  13.      <subobject>
  14.        <loose>false</loose>
  15.        <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
  16.        <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
  17.        <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">12</sid>
  18.        <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
  19.      </subobject>
  20.    </ero>
  21.  </arguments>
  22.  <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
  23. </input>

Details:

  • 9: path-setup-type as per draft-ietf-pce-lsp-setup-type
  • 13: SR-ERO subobject
  • 15: Sid-Type enumeration type ipv4-node-id
  • 16: m bit is set
  • 17: Segment Identifier value is 12
  • 18: Ipv4 Node Identifier address set to 39.39.39.39

Update Segment Routing LSP

Making an update-lsp operation will trigger a Pcupd message to PCC. Update Segment Routing LSP - i.e. enhance path with another segment.

RESTCONF URL : http://localhost:8181/restconf/operations/network-topology-pcep:update-lsp

Method: POST

Content-Type: application/xml

sample input:

  1. <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
  2.   <node>pcc://43.43.43.43</node>
  3.   <name>update-tunnel</name>
  4.   <arguments>
  5.     <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
  6.       <delegate>true</delegate>
  7.       <administrative>true</administrative>
  8.     </lsp>
  9.     <path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
  10.        <pst>1</pst>
  11.     </path-setup-type>
  12.     <ero>
  13.       <subobject>
  14.         <loose>false</loose>
  15.         <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
  16.         <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
  17.         <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">11</sid>
  18.         <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">200.20.160.41</ip-address>
  19.       </subobject>
  20.       <subobject>
  21.         <loose>false</loose>
  22.         <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
  23.         <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
  24.         <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">12</sid>
  25.         <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
  26.       </subobject>
  27.     </ero> 
  28.   </arguments>
  29.   <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
  30. </input>

Remove Segment Routing LSP

Removing Segment Routing LSP works same as in example above.