https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/BGPCEP-444 bgpcep <p>PCEP update complains about missing symbolic path name (error type 6 and value 14) after delegation of the tunnel is revoked. The symbolic path name is learnt by the controller through REST even after delegation is revoked.</p> <p>Snapshot of controllers REST output:</p> <p>&lt;topology <br/> xmlns="urn:TBD:params:xml:ns:yang:network-topology"&gt;<br/> &lt;topology-id&gt;pcep-topology-1&lt;/topology-id&gt;<br/> &lt;topology-types&gt;<br/> &lt;topology-pcep <br/> xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep"&gt;<br/> &lt;/topology-pcep&gt;<br/> &lt;/topology-types&gt;<br/> &lt;node&gt;<br/> &lt;node-id&gt;pcc://10.18.132.98&lt;/node-id&gt;<br/> &lt;path-computation-client <br/> xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep"&gt;<br/> &lt;reported-lsp&gt;<br/> &lt;name&gt;ios_t8&lt;/name&gt;<br/> &lt;path&gt;<br/> &lt;lsp-id&gt;5&lt;/lsp-id&gt;<br/> &lt;ero&gt;<br/> &lt;subobject&gt;<br/> &lt;loose&gt;false&lt;/loose&gt;<br/> &lt;ip-prefix&gt;<br/> &lt;ip-prefix&gt;8.8.8.2/32&lt;/ip-prefix&gt;<br/> &lt;/ip-prefix&gt;<br/> &lt;/subobject&gt;<br/> &lt;subobject&gt;<br/> &lt;loose&gt;false&lt;/loose&gt;<br/> &lt;ip-prefix&gt;<br/> &lt;ip-prefix&gt;7.7.7.2/32&lt;/ip-prefix&gt;<br/> &lt;/ip-prefix&gt;<br/> &lt;/subobject&gt;<br/> &lt;subobject&gt;<br/> &lt;loose&gt;false&lt;/loose&gt;<br/> &lt;ip-prefix&gt;<br/> &lt;ip-prefix&gt;6.6.6.2/32&lt;/ip-prefix&gt;<br/> &lt;/ip-prefix&gt;<br/> &lt;/subobject&gt;<br/> &lt;subobject&gt;<br/> &lt;loose&gt;false&lt;/loose&gt;<br/> &lt;ip-prefix&gt;<br/> &lt;ip-prefix&gt;192.168.254.1/32&lt;/ip-prefix&gt;<br/> &lt;/ip-prefix&gt;<br/> &lt;/subobject&gt;<br/> &lt;ignore&gt;false&lt;/ignore&gt;<br/> &lt;processing-rule&gt;false&lt;/processing-rule&gt;<br/> &lt;/ero&gt;<br/> &lt;lspa&gt;<br/> &lt;setup-priority&gt;7&lt;/setup-priority&gt;<br/> &lt;local-protection-desired&gt;false&lt;/local-protection-desired&gt;<br/> &lt;processing-rule&gt;false&lt;/processing-rule&gt;<br/> &lt;hold-priority&gt;7&lt;/hold-priority&gt;<br/> &lt;ignore&gt;false&lt;/ignore&gt;<br/> &lt;tlvs&gt;&lt;/tlvs&gt;<br/> &lt;include-any&gt;0&lt;/include-any&gt;<br/> &lt;include-all&gt;0&lt;/include-all&gt;<br/> &lt;exclude-any&gt;0&lt;/exclude-any&gt;<br/> &lt;/lspa&gt;<br/> &lt;lsp <br/> xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful"&gt;<br/> &lt;plsp-id&gt;9&lt;/plsp-id&gt;<br/> &lt;create <br/> xmlns="urn:opendaylight:params:xml:ns:yang:pcep:crabbe:initiated"&gt;false<br/> &lt;/create&gt;<br/> &lt;remove&gt;false&lt;/remove&gt;<br/> &lt;administrative&gt;true&lt;/administrative&gt;<br/> &lt;delegate&gt;false&lt;/delegate&gt;<br/> &lt;sync&gt;false&lt;/sync&gt;<br/> &lt;operational&gt;up&lt;/operational&gt;<br/> &lt;processing-rule&gt;false&lt;/processing-rule&gt;<br/> &lt;tlvs&gt;<br/> &lt;lsp-identifiers&gt;<br/> &lt;tunnel-id&gt;8&lt;/tunnel-id&gt;<br/> &lt;ipv4&gt;<br/> &lt;ipv4-tunnel-endpoint-address&gt;192.168.254.1&lt;/ipv4-tunnel-endpoint-address&gt;<br/> &lt;ipv4-tunnel-sender-address&gt;192.168.254.6&lt;/ipv4-tunnel-sender-address&gt;<br/> &lt;ipv4-extended-tunnel-id&gt;192.168.254.1&lt;/ipv4-extended-tunnel-id&gt;<br/> &lt;/ipv4&gt;<br/> &lt;lsp-id&gt;5&lt;/lsp-id&gt;<br/> &lt;/lsp-identifiers&gt;<br/> &lt;path-binding&gt;<br/> &lt;binding-type&gt;0&lt;/binding-type&gt;<br/> &lt;binding-value&gt;AAXcAAA=&lt;/binding-value&gt;<br/> &lt;/path-binding&gt;<br/> &lt;symbolic-path-name&gt;<br/> &lt;path-name&gt;aW9zX3Q4&lt;/path-name&gt;<br/> &lt;/symbolic-path-name&gt;<br/> &lt;/tlvs&gt;<br/> &lt;ignore&gt;false&lt;/ignore&gt;<br/> &lt;/lsp&gt;<br/> &lt;bandwidth&gt;<br/> &lt;ignore&gt;false&lt;/ignore&gt;<br/> &lt;processing-rule&gt;false&lt;/processing-rule&gt;<br/> &lt;bandwidth&gt;AAAAAA==&lt;/bandwidth&gt;<br/> &lt;/bandwidth&gt;<br/> &lt;/path&gt;<br/> &lt;/reported-lsp&gt;<br/> &lt;state-sync&gt;synchronized&lt;/state-sync&gt;<br/> &lt;stateful-tlv&gt;<br/> &lt;stateful <br/> xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful"&gt;<br/> &lt;initiation <br/> xmlns="urn:opendaylight:params:xml:ns:yang:pcep:crabbe:initiated"&gt;true<br/> &lt;/initiation&gt;<br/> &lt;lsp-update-capability&gt;true&lt;/lsp-update-capability&gt;<br/> &lt;/stateful&gt;<br/> &lt;/stateful-tlv&gt;<br/> &lt;ip-address&gt;10.18.132.98&lt;/ip-address&gt;<br/> &lt;/path-computation-client&gt;<br/> &lt;/node&gt;<br/> &lt;/topology&gt;</p> <p>Operating System: All<br/> Platform: All</p> BGPCEP-444

Attempted PCEP Update for a non-delegated LSP throws error type 6 and value 14

Bug Resolved Done Kevin Wang Ajay Chhabria Tue, 19 Apr 2016 19:24:37 +0000 Sun, 3 Mar 2019 11:49:44 +0000 Thu, 26 May 2016 06:57:44 +0000 Bugzilla Migration Bugzilla Migration PCEP 0 3 <p>Attachment Error_6_value_14.PNG has been added with description: PCEP Update after delegation is revoked</p> <p>Ideally the error type should be Error type 19 and value 1.</p> <p>(In reply to Ajay Chhabria from comment #2)<br/> &gt; Ideally the error type should be Error type 19 and value 1.</p> <p>The error (missing symbolic path name) is returned by the PCC, it's not ODL PCE fault. The PCEP stateful draft says anything about the symbolic-path-name TLV inclusion in PcUpd message.</p> <p>Attachment type_bug_5763_pcc_initiated.pcap has been added with description: PCC initiated tunnels</p> <p>Attachment type_bug_5763_pce_initiated.pcap has been added with description: PCE initiated tunnels</p> <p>I noticed that in PCE initiated tunnel, the tunnel eventually gets deleted.</p> <p>It seems that in both cases (PCC or PCE initiated tunnel), the tunnel gets dropped after a while. After the ODL PCE received the report from PCC where the delegation is set to false, ODL removed the tunnel from datastore. In the 2nd update, PCE thought the tunnel was not there anymore, so PCE actually tried to initiate another tunnel.</p> <p>I think there might be a bug in handling the PCEP report whose delegation is set to false. Besides, I don't think update-lsp is supposed to send a tunnel initialization request, it should pop up an error if the tunnel doesn't exist.</p> <p>The following is happening:<br/> "In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of. Receipt of a PCInitiate message with a non-zero PLSP-ID normally results in the generation of a PCErr. If the State Timeout timer is running, the PCC MUST NOT generate an error and redelegate the LSP to the PCE. The State Timeout timer is stopped upon the redelegation. After obtaining control of the LSP, the PCE may remove it using the procedures described in this document."<br/> Ref.:</p> <p>So when you hit updateLsp RPC second time (PCE is not holding the delegation), ODL PCE tries to revoke delegation of the tunnel (send PCInitate message).<br/> You can find a comment in the source code warning about this strange behavior, which can lead to the error, however the procedure is based on the PCE stateful initiated draft.<br/> "// we want to revoke delegation, different type of message<br/> // is sent because of specification by Siva<br/> // this message is also sent, when input delegate bit is set to 0<br/> // generating an error in PCC"</p> <p>Conclusion: What you are experiencing is expected.</p> <p>We should add more karaf log when a tunnel is removed from ODL and specify the reason for it, to help user understand the behavior in the background</p> <p>This bug actually included two parts.</p> <p>The first part is the PCEP tunnel get reverted automatically in controller after you set the delegation to false. According to Milos’s last comment, it’s actually expected. In the 2nd update-lsp request, PCE/ODL thought the tunnel is gone, so it actually sent a LSP initiate message instead of an update message. This is not a bug.</p> <p>The second part of the bug is, the XRv is returning "symbolic path name missing error" in the 2nd update. Per RFC, the PCE is required to include symbolic path name in the LSP object of the initiate message(<a href="https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00#section-3.2" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00#section-3.2</a>) with a PLSP-ID set to 0. It does not mention the inclusion of symbolic path name in update message.</p> <p>Looking at the initiate message in the PCAP file, both PLSP-ID are not set to 0. I think that's the problem. The device is look for a symbolic path with PLSP-ID set to some value, which it cannot find. Thus it returns the value.</p> <p>The result what we expected from the 2nd LSP update:</p> <p>1. PCE/ODL tries to send an initiate message with all required values set and PLSP-ID set to 0. The values should be get from the previous PCEP session.</p> <p>OR</p> <p>2. PCE/ODL tries to send an initiate message with PLSP-ID set to 0, while per the PCAP shows, the endpoint and ero object are missing. It should receive a endpoint object missing or ero object missing error from the device instead.</p> <p>The PCInitiate message is not supposed to re-create the tunnel, but retake a delegation as described here:</p> <p>"In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of. Receipt of a PCInitiate message with a non-zero PLSP-ID normally results in the generation of a PCErr. If the State Timeout timer is running, the PCC MUST NOT generate an error and redelegate the LSP to the PCE."</p> <p>Ref.: <a href="https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00#section-6" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00#section-6</a></p> <p>That's what is happening when you invoke "updateLsp" RPC the second time. Based on the above - ODL PCE set PLSP-ID of the tunnel. But "symbolic path name" inclusion is not mentioned there - for some reason it is required by XRv implementation.<br/> An update message for non-delegated LSP is not send intentionally.</p> <p>May be one think should be fixed in ODL -&gt; the delegation retake should be invoked only for PCE-initiated tunnels. In a case of PCC-initiated non-delegated tunnel, the failure should be returned immediately.</p> <p>Milos,</p> <p>The section you are referring is about PCEP session failure. I don't think it applies to the situation that PCE returns the delegation. In the RFC, I only see it saying "The PCC cannot revoke the delegation for PCE-initiated LSPs for an active PCEP session." But it doesn't say what should happen if PCE revokes the delegation on a PCE-initiated LSP.</p> <p>And in <a href="https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-14#section-5.7.2.1" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-14#section-5.7.2.1</a> , it says<br/> "After an LSP delegation has been revoked, a PCE can no longer update<br/> LSP's parameters; an attempt to update parameters of a non-delegated<br/> LSP will result in the PCC sending a PCErr message with error-type 19<br/> (Invalid Operation), error-value 1 (attempted LSP Update Request for<br/> a non-delegated LSP) (see Section 8.5)."</p> <p>So the problem here is, PCE is not supposed to send an initiate message to retake the delegation, as it has explicitly returned the delegation by user, it should not retake it in the background without user's acknowledge, unless user set delegation flag to true again in the second update.</p> <p>The expected behaviour is:<br/> When trying to send the 2nd update message, ODL should still construct an update message, then return the 19-1 ERROR received from PCC.<br/> Or<br/> It returns this same error immediately without sending any message to PCC in the background.</p> <p>A redelegation should not happen here as it is not a session failure.</p> <p>The same can be applied if session goes down or PCE is not currently holding a delegation - in both cases PCC become the LSP delegation holder for some time.</p> <p>The retaking of the delegation is done based on the user request (the second updateLsp in this particular case). The draft is not mentioning a need for a delegation flag to be set in this case.</p> <p>What should probably be fixed in ODL:<br/> *retaking should be invoked only for PCE-initiated LSPs, otherwise return failure as you propose.<br/> First, I would rather test the router's behavior with PCC-initiated LSPs.</p> <p>Milos,</p> <p>So regarding this issue, even if user explicitly set the delegation to false in the 2nd update request, PCE will still try to retake the delegation back in this case?</p> <p>(In reply to Kevin Wang from comment #15)<br/> &gt; Milos,<br/> &gt; <br/> &gt; So regarding this issue, even if user explicitly set the delegation to false<br/> &gt; in the 2nd update request, PCE will still try to retake the delegation back<br/> &gt; in this case?</p> <p>Correct.</p> <p>Boron:<br/> <a href="https://git.opendaylight.org/gerrit/#/c/39197/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39197/</a></p> <p>Beryllium:<br/> <a href="https://git.opendaylight.org/gerrit/#/c/39289/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39289/</a></p> Duplicate BGPCEP-445 Development External issue ID 5763 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02cbr: