search

ietf-wg-idr / draft-ietf-idr-sr-policy-safi

Repository for draft-ietf-idr-sr-policy-safi Issues
0 stars 0 forks source link

RTG-DIR Issue 27 Section 5 - Error Handling and Fault Management - 2 parts to issue #29

Closed suehares closed 1 month ago

suehares commented 4 months ago

RTG-DIR Issue 27: Section 5 - Error Handling and Fault Management - 2 parts

RTG-DIR Issue 27 - Part 1

Text:/

  1. Error Handling and Fault Management

    A BGP Speaker MUST perform the following syntactic validation of the SR Policy NLRI to determine if it is malformed. This includes the validation of the length of each NLRI and the total length of the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the validation of the consistency of the NLRI length with the AFI and the endpoint address as specified in Section 2.1.

    When the error determined allows for the router to skip the malformed NLRI(s) and continue the processing of the rest of the update message, then it MUST handle such malformed NLRIs as 'Treat-as- withdraw'. In other cases, where the error in the NLRI encoding results in the inability to process the BGP update message (e.g. length related encoding errors), then the router SHOULD handle such malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR Policy are being advertised over the same session. Alternately, the router MUST perform 'session reset' when the session is only being used for SR Policy or when it 'AFI/SAFI disable' action is not possible./

Jeffrey: Is the above generic BGP handling? Ketan: Yes, per RFC7606 this needs to be defined for new SAFIs.

text:/ The validation of the TLVs/sub-TLVs introduced in this document and defined in their respective sub-sections of Section 2.4 MUST be performed to determine if they are malformed or invalid. The validation of the Tunnel Encapsulation Attribute itself and the other TLVs/sub-TLVs specified in Section 13 of [RFC9012] MUST be done as described in that document. In case of any error detected, either at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy MUST be applied. This is because an SR Policy update without a valid Tunnel Encapsulation Attribute (comprising of all valid TLVs/sub-TLVs) is not usable./

Jeffrey: The above says the validation of those in Section 2.4 may lead to "treat-as-withdraw" - I assume this is BGP handling. Does that not conflict with the following paragraph?

The validation of the individual fields of the TLVs/sub-TLVs defined in Section 2.4 are beyond the scope of BGP as they are handled by the SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP implementation MUST NOT perform semantic verification of such fields nor consider the SR Policy update to be invalid or not usable based on such validation.

Ketan: No, it does not. There is a line between what validation is done by BGP and what is done by SRPM.

suehares commented 3 months ago

Updated into Shepherd's Review of RTG-DIR as issue SR04-Section 5 Issue 2

suehares commented 1 month ago

closed merged into Shepherd's full review https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32

suehares commented 1 month ago

closing since merged into full review https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32