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

[Ketan Talaulikar <[e-mail]>]

Hi Jeffrey,

A gentle reminder on this one - could you please respond?

Thanks,
Ketan


On Sat, Mar 16, 2024 at 8:45 PM Ketan Talaulikar <[e-mail]>
wrote:

> 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
>>>
>>