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

[Ketan Talaulikar <[e-mail]>]

Hi Jeffrey,

Thanks for the quick response. I've incorporated that suggested change and
pushed out an update:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-04

Sue, this update also includes the change related to the ENLP values that
you had asked to be brought back into the main body of the ENLP sub-TLV
description instead of just in the IANA section.

Thanks,
Ketan


On Tue, Apr 30, 2024 at 10:29 PM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> Hi Ketan,
>
>
>
> >   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.
>
> Perhaps the following?
>
>
>
>    To steer an unlabeled IP packet into an SR policy, it is necessary to
>    push a label stack of one or more labels to that packet.
>
> I’m all set with this review.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> Juniper Business Use Only
>
> *From:* rtg-dir <[e-mail]> *On Behalf Of *Ketan Talaulikar
> *Sent:* Tuesday, April 30, 2024 12:53 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; Susan Hares <[e-mail]>
> *Subject:* Re: [RTG-DIR] Rtgdir early review of
> draft-ietf-idr-sr-policy-safi-00
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey,
>
>
>
> Thanks for your response. Please check inline below for responses with KT3.
>
>
>
>
>
> On Tue, Apr 30, 2024 at 9:29 PM Jeffrey (Zhaohui) Zhang <
> [e-mail]> wrote:
>
> Hi Ketan,
>
>
>
> Please see see zzh2> below. Only one point about “deprecating” is
> important – others are nits.
>
>
>
>
>
> Juniper Business Use Only
>
> 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
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02__;!!NEt6yMaO-gk!DlUR-MNAN113KrtdcUWpy3xqDeIkpr37AyhMVHGQkv7m3AE7UFo_rGVGp85lOeATMsW-KsOkbi95qfuioez5uA$>
>
>
>
> 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.
>
> Zzh2> I think it should be changed to the following to be clear:
>
>    It is important to note that when a BGP speaker receives a BGP message
>
>    with an SR Policy NLRI, the SRPM will process it only if the NLRI is
> among the
>
>    best paths as per the BGP best-path selection algorithm.
>
>
>
> Zzh2> You don’t need to post a revision for this one alone, though.
>
>
> KT3> Ack - will fix that and queue it up for the next update.
>
>
>
> 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.
>
>
>
> Zzh2> Now I realize that you’re talking about the TLV 2 introduced in
> earlier versions of *this document* - they’re now deprecated/invalid.
> Should we talk about this at all? Shouldn’t it only talk about the final
> procedures/encodings when this becomes an RFC?
>
>
>
> KT3> This was discussed in the WG and the decision was to retain the use
> of the Binding SID TLV also for SRv6 for those early implementations. This
> is now clarified in the latest version based on Sue's suggestion -
> https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-03.html#section-2.4
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-03.html*section-2.4__;Iw!!NEt6yMaO-gk!GPJ53mqzefZz7_bskLAPw1D--N7nF9oQb1FQdFKbay5dUbB8P84wPYLKj4xzROu2MUc2c4Gy4F1Y5Utxm6Nvtw$>
> has the following text:
>
>
>
> An early version of this document included only the Binding SID sub-TLV
> that could be used for both SR-MPLS and SRv6 Binding SIDs. The SRv6 Binding
> SID TLV was introduced in later versions to support the advertisement of
> additional SRv6 capabilities without affecting backward compatibility for
> early implementations.
>
>
>
>
>
>
>
>
> 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.
>
> Zzh2> The wording “create a label stack for that packet, and push one or
> more labels onto that stack” is really strange.
>
> Zzh2> Again, you don’t need to post a revision for this.
>
>
>
> KT3> Would you have some text suggestions?
>
>
>
>
> 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.
>
> Zzh2> The previous paragraphs are:
>
>    SR Policy NLRIs that have the NO_ADVERTISE community attached to them
>
>    MUST NOT be propagated.
>
>
>
>    By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate
>
>    it to any EBGP neighbor.  An implementation MAY provide an explicit
>
>    configuration to override this and enable the propagation of valid SR
>
>    Policy NLRIs to specific EBGP neighbors where the SR domain comprises
>
>    multiple-ASes within a single service provider domain (see Section 7
>
>    for details).
>
>
>
>    A BGP node advertises a received SR Policy NLRI to its IBGP neighbors
>
>    according to normal IBGP propagation rules.
>
> Zzh2> I don’t see “It goes with the previous paragraph - hence required to
> clarify” so my question remains, but it’s not important.
>
> 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.
>
>
>
> Zzh2> Let’s say the SRPM had a valid Candidate Path (CP) earlier. Then an
> update comes and now the same CP is determined as invalid by the SRPM. What
> would happen to the earlier valid CP? Should it be invalidated? I was
> thinking that is like “treat-as-withdrawal”, but I take it that the BGP
> route still remains. Iin the case of “treat-as-withdrawal” in BGP, the
> route will be deleted, right?
>
>
>
> KT3> The new CP will replace the old CP in the BGP table and since it is
> the best path, BGP will send it to SRPM (w/o semantic validation). Now,
> this CP replaces its previous instance in SRPM and upon validation, SRPM
> finds it invalid so it cannot be used in the forwarding. SRPM will try to
> use another CP, if a valid one exists, and if not then the SR Policy will
> be brought down. Meanwhile, this CP will remain in the BGP table (where it
> is not invalid per BGP validation process) - hence it won't be a
> "treat-as-withdraw".
>
>
>
> Thanks,
>
> Ketan
>
>
>
> Zzh2> Thanks.
>
> Zzh2> Jeffrey
>
>
>
> 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
>
>