Skip to main content

Early Review of draft-ietf-idr-sr-policy-safi-01

Request Review of draft-ietf-idr-sr-policy-safi
Requested revision No specific revision (document currently at 04)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2024-02-29
Requested 2024-02-15
Requested by Susan Hares
Authors Stefano Previdi , Clarence Filsfils , Ketan Talaulikar , Paul Mattes , Dhanendra Jain
I-D last updated 2024-03-04
Completed reviews Rtgdir Early review of -00 by Zhaohui (Jeffrey) Zhang (diff)
Tsvart Early review of -00 by David L. Black (diff)
Opsdir Early review of -01 by Nagendra Kumar Nainar (diff)
draft-ietf-idr-sr-policy-safi has specific needs for review based on the area:

OPS-DIR + RTG-DIR - This draft contains the procedures in draft-ietf-idr-bgp-segment-routing-te-policy for segment types A and B. 
Please note this has a dependency on the format of [RFC9012], but the SR Policy Tunnel type only uses the envelope of [RFC9012] TEA attribute.  None of the TLVs in [RFC9012] are required, and none of the validation of [RFC9012] are required.  The Validation is done in the SRPM module specified by Spring (RFC9252].  Therefore, the syntax validation is in BGP and the context validation is in the SRPM. 

Please consider this in your review.  Is this a problem? 

This draft split the procedures for segment types A-B away from segment types C-L (contained in draft-ietf-idr-bgp-sr-segtypes-ext-02) since segment types C-L did not have the required 2 implementations. Is this going to be a problem? 

Please review the validation procedures. 

INT/Transport Area Review team: 
This routing document (draft-ietf-idr-sr-policy-safi) extends the color functions in the BGP Extended Community Color to aid the steering of traffic flows into particular routing paths.  Color tagging is part of the Intent-based signaling of upper-layer desire for VPNs within routing technology. Other drafts that provide functions to carry Intent are draft-ietf-idr-bgp-car (via color) and draft-ietf-idr-bgp-ct (via class). 

It would be good to get a transport reviewer to help see if we are really Transport/INT functions being defined.
Assignment Reviewer Nagendra Kumar Nainar
State Completed
Request Early review on draft-ietf-idr-sr-policy-safi by Ops Directorate Assigned
Posted at
Reviewed revision 01 (document currently at 04)
Result Has issues
Completed 2024-03-04

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing SR Policy NLRI and the relevant TLVs
along with the handling procedures. Overall this is a well written document and
addresses all potential operational aspects. I am marking it as "Has issues"
only to get some clarification on the below as I could not get any clarity
based on my reading.

More details below:

An SR Policy intended only for the receiver will, in most cases, not
   traverse any Route Reflector (RR, [RFC4456]).

--> Normally, it is expected to have BGP session between the PEs and the RRs.
The above statement appears to give an impression that - in addition to the
PE-RR session(s), does this machinery require additional/adhoc sessions between
the PEs?. Or is this statement only applicable for the PCE-PE scenario?. Can
you clarify the same?

It has to be noted that if several candidate paths of the same SR
   Policy (endpoint, color) are signaled via BGP to a headend, then it
   is RECOMMENDED that each NLRI uses a different distinguisher.  If BGP
   has installed into the BGP table two advertisements whose respective
   NLRIs have the same color and endpoint, but different distinguishers,
   both advertisements are passed to the SRPM as different candidate
   paths along with their respective originator information (i.e., ASN
   and BGP Router-ID) as described in section 2.4 of [RFC9256].

--> What happens when the BGP receives several candidate paths for the <Color,
Endpoint> but with the same distinguisher?. Will it override or the preference
sub-TLV will handle it?. I was looking into the related drafts/RFCs but I am
not sure if this is handled properly and would like to add here to clarify as

--> What happens if a node receives the SR Policy NLRI with the length field of
the Binding SID Sub-TLV set to 6 and the label value from the reserved range
(0-15 may be)?

--> Section 2.4.3 describes the Sub-TLV for SRv6 BSID. Any reason why section
2.4.2 includes a length field and describes another way to represent SRv6 BSID?