Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00

[Ketan Talaulikar <[e-mail]>]

Hi Jeffrey,

An update has been posted which includes some of the changes that we've
discussed on this thread.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02

Please let us know if there are any outstanding comments that remain to be
addressed.

Thanks,
Ketan


On Mon, Mar 4, 2024 at 9:37 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Jeffrey,
>
> Thanks for your quick response and feedback on this draft. Please check
> inline below for responses with KT2.
>
>
> On Mon, Mar 4, 2024 at 8:16 PM Jeffrey (Zhaohui) Zhang <[e-mail]>
> wrote:
>
>> Hi Ketan,
>>
>>
>>
>> I was finishing up this email before seeing your email about the posted
>> version. I have not had a chance to go through the changes, but to get my
>> questions to you quicker, let me send this (even though some may have been
>> answered by the updated version).
>>
>>
>>
>> Please see a few points below. I trimmed the text to focus on those.
>>
>>
>>
>>
>>
>>
>>    An SR Policy intended only for the receiver will, in most cases, not
>>    traverse any Route Reflector (RR, [RFC4456]).
>>
>> Is the above paragraph correct/needed. I suppose in most cases
>> they will traverse RR after all - whether it is from a controller or
>> an egress PE.
>>
>>
>>
>> KT> It is needed. RR is not required and not used in many deployments
>> that I know of. It is a direct peering from controller to router.
>>
>>
>>
>> Zzh> OK if you say the most BGP deployment is not through RR 😊
>>
>>
>>
>> How is further propagation prevented after the headend is reached?
>>
>>
>>
>> KT> This is covered in section 4.2.3
>>
>>
>>
>> Zzh> I think a little more text is needed (more below).
>>
>>
>>
>>    *  One or more IPv4 address format route target extended community
>>       ([RFC4360]) attached to the SR Policy advertisement and that
>>       indicates the intended headend of such an SR Policy advertisement.
>>
>> and IPv6? s/format/specific/?
>>
>>
>>
>> KT> Fixed. Use of IPv6 specific RT is not specified in this document.
>>
>> Zzh> I see that it’s based on BGP Identifier which is 4-octet only so
>> that’s reasonable.
>>
>>
>>    It is important to note that any BGP speaker receiving a BGP message
>>    with an SR Policy NLRI, will process it only if the NLRI is among the
>>
>> There are a lot of "processing" before it is deemed "among the bet paths",
>> right? Do you mean the "SRPM" will process it only if the NLRI is among
>> the best paths?
>>
>>
>>
>> KT> Yes and Yes.
>>
>> Zzh> I see that the document intentionally distinguishes between BGP and
>> SRPM. So the above distinction is necessary.
>>
>>
>>
>> 2.3.  Applicability of Tunnel Encapsulation Attribute Sub-TLVs
>>
>>    The Tunnel Egress Endpoint and Color sub-TLVs, as defined in
>>    [RFC9012], may also be present in the SR Policy encodings.
>>
>> Why do we say the above given the following paragraph? They seem to
>> be contractive.
>>
>>
>>
>> KT> There is no contradiction. We don't want the attribute to be
>> considered malformed due to the presence of those sub-TLVs.
>>
>> Zzh> It seems that the above paragraph can be removed – the following
>> paragraph alone is enough.
>>
>
> KT2> Ack - removed for the next update.
>
>
>>
>>    The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel
>>    Encapsulation Attribute are not used for SR Policy encodings and
>>    therefore their value is irrelevant in the context of the SR Policy
>>    SAFI NLRI.  If present, the Tunnel Egress Endpoint sub-TLV and the
>>    Color sub-TLV MUST be ignored by the BGP speaker and MAY be removed
>>    from the Tunnel Encapsulation Attribute during propagation.
>>
>>
>>
>>
>>
>>
>>    When the Binding SID sub-TLV is used to signal an SRv6 SID, the
>>    choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is
>>    left to the headend node.  It is RECOMMENDED that the SRv6 Binding
>>    SID sub-TLV defined in Section 2.4.3, that enables the specification
>>    of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
>>    Binding SID for an SR Policy candidate path.
>>
>> Is there a choice here? Shouldn't the behavior be that traffic with that
>> Binding SID is steered into this policy?
>>
>>
>>
>> KT> What is meant by SRv6 Endpoint behavior is specified in RFC8986 -
>> e.g., End.B6.Encaps, End.B6.Encaps.Red, and others could be defined in the
>> future.
>>
>>
>>
>> Zzh> Now I see that the first “Binding SID sub-TLV” in the above
>> paragraph is not the “SRv6 Binding SID sub-TLV” but the one that can be
>> used for both MPLS and SRv6 (I missed that). Then the paragraph makes sense.
>>
>> Zzh> It helps if the paragraph moves down to after “If the length is 18
>> then the Binding SID contains a 16-octet SRv6 SID” and changes to the
>> following:
>>
>
> KT2> We put it up front so it is more clear - putting it at the end may
> result in it being missed. This is an editorial thing and I prefer keeping
> it as is.
>
>
>>
>>
>> … in this case, the
>>    choice of its SRv6 Endpoint Behavior to be instantiated, e.g., between
>>
>> End.B6.Encaps, End.B6.Encaps.Red [RFC8986], is
>>    left to the headend node.  It is RECOMMENDED that the SRv6 Binding
>>    SID sub-TLV defined in Section 2.4.3, that enables the specification
>>    of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
>>    Binding SID for an SR Policy candidate path.
>>
>>
>>
>>
>>
>>    *  Binding SID: If the length is 2, then no Binding SID is present.
>>       If the length is 6 then the Binding SID is encoded in 4 octets
>>       using the format below.  Traffic Class (TC), S, and TTL (Total of
>>       12 bits) are RESERVED and MUST be set to zero and MUST be ignored.
>>
>>         0                   1                   2                   3
>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |          Label                        | TC  |S|       TTL     |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>     Figure 6: Binding SID Label Encoding
>>
>>       If the length is 18 then the Binding SID contains a 16-octet SRv6
>>       SID.
>>
>>
>>
>>
>>
>> 2.4.4.2.2.  Segment Type B
>>
>>    The Type B Segment Sub-TLV encodes a single SRv6 SID.  The format is
>>    as follows:
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     Type      |   Length      |     Flags     |   RESERVED    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    //                       SRv6 SID (16 octets)                  //
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    //     SRv6 Endpoint Behavior and SID Structure (optional)     //
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>    *  Flags: 1 octet of flags as defined in Section 2.4.4.2.3.
>>
>>    *  SRv6 SID: 16 octets of IPv6 address.
>>
>>    *  SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
>>       Section 2.4.4.2.4.
>>
>> When this is part of a segment list, what is the significance of the
>> Flags and
>> SRv6 Endpoint Behavior and SID Structure?
>>
>>
>>
>> KT> Please refer to sections 2.4.4.2.3 and 2.4.4.2.4 - will elaborate on
>> your further comments on those sections.
>>
>>
>>
>>
>>    The TLV 2 defined for the advertisement of Segment Type B in the
>>    earlier versions of this document has been deprecated to avoid
>>    backward compatibility issues.
>>
>> Why would deprecating them avoid backward compatibility issues?
>> If there are implementations/deployments based on earlier versions,
>> deprecating them won't help.
>> If there are no implementations/deployments based on earlier versions,
>> there is no backward compatibility issue.
>>
>>
>> Perhaps just remove "to avoid ..."?
>>
>>
>>
>> KT> The WG was polled in this matter. While there were no implementations
>> from "known" vendors represented at the IETF, we cannot rule out something
>> being out there.
>>
>>
>>
>> Zzh> I mean that “deprecating them” would not address the backward
>> compatibility issue after all if there is implementation out there already
>> based on the old version?
>>
>
> KT2> The backward compatibility part was why we didn't change those TLV
> formats and used new code-points.
>
>
>>
>>
>>
>> 2.4.4.2.3.  Segment Flags
>>
>>    The Segment Types sub-TLVs described above may contain the following
>>    flags in the "Flags" field defined in Section 6.8:
>>
>>     0 1 2 3 4 5 6 7
>>    +-+-+-+-+-+-+-+-+
>>    |V|   |B|       |
>>    +-+-+-+-+-+-+-+-+
>>
>>    Figure 22: Segment Flags
>>
>>    where:
>>
>>       V-Flag: This flag, when set, is used by SRPM for "SID
>>       verification" as described in Section 5.1 of [RFC9256].
>>
>> I have trouble understanding the V-Flag. How is the headend supposed to
>> verify
>> the BSID or any segment in the segment list?
>>
>>
>>
>> KT> Please refer to section 5.1 of the RFC9256.
>>
>>
>>
>>
>> 2.4.5.  Explicit NULL Label Policy Sub-TLV
>>
>>    To steer an unlabeled IP packet into an SR policy, it is necessary to
>>    create a label stack for that packet, and push one or more labels
>>    onto that stack.
>>
>> Do you mean SR-mpls policy?
>> Perhaps remove ", and push one or more labels onto that stack"?
>> Perhaps changes "Explicit NULL Label Policy" to
>> "Explicit NULL Label Behavior"? The word "policy" here gets tangled
>> with "SR Policy".
>>
>>
>>
>> KT> This is related to SR Policy with the SR-MPLS data plane.
>>
>>
>>
>>
>>
>>
>> When should the BGP update stops being propagated if RT is used?
>> Never? or should a matching RT be removed by each matching receiver
>> and then the propagation stops when there is no RT left?
>>
>>
>>
>> KT> Yes, it can do that using local configuration. See the next paragraph.
>>
>>
>>
>>
>>    By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove
>>    route target extended community before propagation.  An
>>    implementation MAY provide support for configuration to filter and/or
>>    remove route target extended community before propagation.
>>
>> Isn't the above applicable to any AFI/SAFI? Why do we need to specify
>> that?
>>
>>
>>
>> KT> It goes with the previous paragraph - hence required to clarify.
>>
>>
>>
>> Zzh> I think it SHOULD remove the RT that matches its BGP identifier and
>> stop propagating if there are no more RTs left, w/o relying on
>> configuration.
>>
>
> KT2> I can understand where you are coming from and IIRC this option was
> discussed at some point of time during the draft's life as a WG document.
> The decision at that point was to keep it as an explicit policy option and
> to not create an exception in the base BGP propagation mechanism. The way
> it works today is that the BGP Identifier matching is done during "import"
> into SRPM that is specific to the BGP SR Policy SAFI.
>
>
>>
>>
>>
>> 5.  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.
>>
>> Is the above generic BGP handling?
>>
>>
>>
>> KT> Yes, per RFC7606 this needs to be defined for new SAFIs.
>>
>>
>>
>>
>>    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.
>>
>> 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?
>>
>>
>>
>> KT> No, it does not. There is a line between what validation is done by
>> BGP and what is done by SRPM.
>>
>> Zzh> My understanding is that “treat-as-withdraw” is BGP handling (BGP
>> tells SRPM the route is withdrawn) – that’s why I thought that there was a
>> conflict.
>>
>> Zzh> Are you saying that it is ok for BGP not to treat it as withdrawal
>> but for SRPM to treat it as withdrawal (due to the validation in Section
>> 2.4)?
>>
>
> KT2> SRPM does not have the concept of "treat it as withdraw". It does
> have the concept of "invalid CP or SL" as specified in RFC9256 and that is
> how it would handle such semantic errors.
>
> Thanks,
> Ketan
>
>
>> Zzh> Thanks.
>>
>> Zzh> Jeffrey
>>
>>
>>
>>
>>    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.
>>
>>
>>
>> Juniper Business Use Only
>>
>