[BGPCEP-443] Get operation of pcep-topology returns wrong prefix mask for next-hop addresses Created: 18/Apr/16  Updated: 03/Mar/19  Resolved: 21/Apr/16

Status: Resolved
Project: bgpcep
Component/s: PCEP
Affects Version/s: Bugzilla Migration
Fix Version/s: Bugzilla Migration

Type: Bug
Reporter: Ajay Chhabria Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: File pcep-prefix2.pcap    
External issue ID: 5743

 Description   

The actual prefix masks for the next hops used in LSP are configured for /24 not /32 as output below from running the following Get REST call. The ERO's reported during the GET operation reflects /32 for all the hops.

http://10.18.133.157:8181/restconf/operational/network-topology:network-topology/topology/pcep-topology-1

<topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
<topology-id>pcep-topology-1</topology-id>
<topology-types>
<topology-pcep xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep"></topology-pcep>
</topology-types>
<node>
<node-id>pcc://10.18.132.89</node-id>
<path-computation-client xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
<reported-lsp>
<name>ios_t0</name>
<path>
<lsp-id>11</lsp-id>
<lspa>
<processing-rule>false</processing-rule>
<setup-priority>7</setup-priority>
<local-protection-desired>false</local-protection-desired>
<tlvs></tlvs>
<hold-priority>7</hold-priority>
<ignore>false</ignore>
<include-any>0</include-any>
<include-all>0</include-all>
<exclude-any>0</exclude-any>
</lspa>
<lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<remove>false</remove>
<ignore>false</ignore>
<processing-rule>false</processing-rule>
<sync>false</sync>
<create xmlns="urn:opendaylight:params:xml:ns:yang:pcep:crabbe:initiated">false</create>
<tlvs>
<lsp-identifiers>
<ipv4>
<ipv4-extended-tunnel-id>192.168.254.3</ipv4-extended-tunnel-id>
<ipv4-tunnel-sender-address>192.168.254.6</ipv4-tunnel-sender-address>
<ipv4-tunnel-endpoint-address>192.168.254.3</ipv4-tunnel-endpoint-address>
</ipv4>
<tunnel-id>0</tunnel-id>
<lsp-id>11</lsp-id>
</lsp-identifiers>
<path-binding>
<binding-value>AAXcMAA=</binding-value>
<binding-type>0</binding-type>
</path-binding>
<symbolic-path-name>
<path-name>aW9zX3Qw</path-name>
</symbolic-path-name>
</tlvs>
<administrative>true</administrative>
<delegate>true</delegate>
<operational>up</operational>
<plsp-id>1</plsp-id>
</lsp>
<ero>
<ignore>false</ignore>
<subobject>
<ip-prefix>
<ip-prefix>10.0.0.16/32</ip-prefix>
</ip-prefix>
<loose>false</loose>
</subobject>
<subobject>
<ip-prefix>
<ip-prefix>2.2.2.14/32</ip-prefix>
</ip-prefix>
<loose>false</loose>
</subobject>
<subobject>
<ip-prefix>
<ip-prefix>100.1.1.37/32</ip-prefix>
</ip-prefix>
<loose>false</loose>
</subobject>
<subobject>
<ip-prefix>
<ip-prefix>192.168.254.3/32</ip-prefix>
</ip-prefix>
<loose>false</loose>
</subobject>
<processing-rule>false</processing-rule>
</ero>
<bandwidth>
<ignore>false</ignore>
<bandwidth>AAAAAA==</bandwidth>
<processing-rule>false</processing-rule>
</bandwidth>
</path>
</reported-lsp>
<state-sync>synchronized</state-sync>
<ip-address>10.18.132.89</ip-address>
<stateful-tlv>
<stateful xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
<lsp-update-capability>true</lsp-update-capability>
<initiation xmlns="urn:opendaylight:params:xml:ns:yang:pcep:crabbe:initiated">true</initiation>
</stateful>
</stateful-tlv>
</path-computation-client>
</node>
</topology>

 Comments   
Comment by Milos Fabian [ 19/Apr/16 ]

Ajay, what ODL version are testing? Could you please share ODL logs with enabled trace logging for PCEP or packet capture to see what bytes are coming to ODL.

Comment by Ajay L [ 19/Apr/16 ]

Looks like the prefix value (/32) is coming as part of ERO subobject in PCRpt. So controller is displaying what it is getting from the XRv

Tried both PCC and PCE initiated scenarios. In both cases prefix reported is /32 (refer packet # 43, 62 and 68 in attached pcap file). I think this is the case because this is operational data i.e. it shows it actual nodes in the path which is identified by /32 prefix. In PCE initiated case, /24 can be mentioned in add-lsp request -> this is the config from which the actual path will be selected and actual node reflected in the operational data

FYI - ERO object is described here: https://tools.ietf.org/html/rfc3209#page-23

An explicit route is described as a list of groups of nodes along the
explicit route. In addition to the ability to identify specific
nodes along the path, an explicit route can identify a group of nodes
that must be traversed along the path. This capability allows the
routing system a significant amount of local flexibility in
fulfilling a request for an explicit route. This capability allows
the generator of the explicit route to have imperfect information
about the details of the path.

The explicit route is encoded as a series of subobjects contained in
an EXPLICIT_ROUTE object. Each subobject identifies a group of nodes
in the explicit route. An explicit route is thus a specification of
groups of nodes to be traversed.

To formalize the discussion, we call each group of nodes an abstract
node. Thus, we say that an explicit route is a specification of a
set of abstract nodes to be traversed. If an abstract node consists
of only one node, we refer to it as a simple abstract node.

Comment by Ajay L [ 19/Apr/16 ]

Attachment pcep-prefix2.pcap has been added with description: Pcap file showing ERO object

Comment by Ajay L [ 19/Apr/16 ]

Reg. versions - I am trying with master (Boron) whereas AjayC is on Lithium SR4

Comment by Milos Fabian [ 20/Apr/16 ]

Ajay, you are right - the pcep-topology-provider is always reflecting data from received PcRpt messages.
Do you agree to close this file as an invalid?

Comment by Ajay Chhabria [ 20/Apr/16 ]

Few things to comment:

1. Firstly, every XRv(hop) is configured with an MPLS TE Router-ID. If an explicit route object is supposed to give the node/abstract node information along the explicit route, shouldn't the XRv send the Router-ID instead of physical interface IP address ?

2. If Controller is reading what XRv is sending and is expecting "node info" along the path to traverse then why does Controller explicit include subnet mask in the ip-prefix schema ? Shouldn't "ip-prefix" be replaced as "node IP" in the operational data ?

Comment by Milos Fabian [ 20/Apr/16 ]

(In reply to Ajay Chhabria from comment #6)
> Few things to comment:
>
> 1. Firstly, every XRv(hop) is configured with an MPLS TE Router-ID. If an
> explicit route object is supposed to give the node/abstract node information
> along the explicit route, shouldn't the XRv send the Router-ID instead of
> physical interface IP address ?
>
> 2. If Controller is reading what XRv is sending and is expecting "node info"
> along the path to traverse then why does Controller explicit include subnet
> mask in the ip-prefix schema ? Shouldn't "ip-prefix" be replaced as "node
> IP" in the operational data ?

1. I am not able to answer, XRv implementation is out of my knowledge/experiences.
2. The ERO's IPv4 prefix sub-object is defined in - https://tools.ietf.org/html/rfc3209#section-4.3.3.2, so 32 prefix length is an equivalent of IPv4 node.
Can you confirm that prefix length would be always "32" no matter what PCC implementation and configuration is communicating to ODL PCE?

Comment by Ajay L [ 20/Apr/16 ]

AjayC, few thoughts on your comments:

1. Each node will have multiple physical interfaces. If Router-ID is used instead of physical interface IP address, it will tell which nodes the path pass through, but not necessarily the actual path itself which can be conveyed using interface IP addresses

2. The ERO object (ref. https://tools.ietf.org/html/rfc3209#page-23) is used to carry both config and operational data. Prefix value is needed for config

Comment by Milos Fabian [ 21/Apr/16 ]

@AjayC:
The ERO Object yang data model is reused in PCEP messages, PCEP RPC inputs and PCEP topology, bringing strait forward DTOs reusing (no transformation needed).
What you are suggesting, would require API changes, that are unnecessary imho.

Comment by Ajay Chhabria [ 21/Apr/16 ]

Thank you Milos and Ajay L for detailed information. Please go ahead and close this bug.

Ajay Chhabria

Generated at Wed Feb 07 19:13:04 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.