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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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.

   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:

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


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.


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