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-12: Section 2.4 SR Policy SubTLVs #14

Closed suehares closed 1 month ago

suehares commented 4 months ago

RTG-DIR Issue-12: Section 2.4 SR Policy SubTLVs

Text:/

Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, Policy Name, Policy Candidate Path Name, and Explicit NULL Label Policy are all optional sub-TLVs introduced for the BGP Tunnel Encapsulation Attribute [RFC9012] being defined in this section./

Jeffrey: Should the segment-list be mandatory? What does it mean if the segment-list is empty?

Ketant: Without a SL (segment list) or an empty SL, the SRPM would not be able to instantiate the CP in the forwarding. However, that is for the SRPM to decide. We do not bring that sort of validation into BGP.

https://mailarchive.ietf.org/arch/msg/rtg-dir/0NtYL2BshwzJiS5uTCDUYxec0OM/

suehares commented 3 months ago

Stated in RFC9012:

Within a Tunnel Encapsulation attribute that is carried by a BGP UPDATE whose AFI/SAFI is one of those explicitly listed in the first paragraph of Section 6, a TLV that does not contain exactly one Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a malformed Tunnel Egress Endpoint sub-TLV.

Shepherd's comment: The SAFI (1/73) or (2/73) is not listed in the RFC9012 in section 6. Therefore, the Tunnel Egress Endpoint is not validated.

What is concerning is that the SRPM decides whether the SR Policy tunnel is valid or invalid based on this decision. Therefore, BGP is not performing validation of the tunnel endpoint.

This reality needs to be exposed to the reviewer and implementer.

suehares commented 3 months ago

Section 5-01:

Status: Shepherd's required change to Section 5.

Original 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./

Paragraph revised (changed text in bold):/ 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 any error is 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 (comprised of all valid TLVs/sub-TLVs) is not usable.

Section 6 of [RFC9012] referred to by section 13 of [RFC9012] does not apply to a TLV associated with the SR Policy NRLI so the Tunnel Egress Endpoint does not have to exist in the Tunnel Encapsulation Attribute with the tunnel type SR Policy. As noted in section 2.3, the Tunnel Egress Endpoint SubTLV is ignored for tunnel Type SR Policy. Only the SRPM validates the viability of the tunnel signaled through BGP./

suehares commented 1 month ago

closed merged into https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32