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

[Ketan Talaulikar <[e-mail]>]

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
>