Skip to main content

Early Review of draft-ietf-idr-sr-policy-safi-00
review-ietf-idr-sr-policy-safi-00-tsvart-early-black-2024-02-28-00

Request Review of draft-ietf-idr-sr-policy-safi
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Transport Area Review Team (tsvart)
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-02-28
Completed reviews Secdir Early review of -04 by Vincent Roca (diff)
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)
Genart Last Call review of -09 by Dan Romascanu (diff)
Tsvart Last Call review of -10 by Magnus Westerlund
Comments
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 David L. Black
State Completed
Request Early review on draft-ietf-idr-sr-policy-safi by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/62rqGPrhAashIGcYupmbWZT4axY
Reviewed revision 00 (document currently at 10)
Result On the right track
Completed 2024-02-28
review-ietf-idr-sr-policy-safi-00-tsvart-early-black-2024-02-28-00
The result of this early TSV-ART review's is "On the Right Track" rather than
some form of "Ready" for the sole reason that the scope of this review is
limited to the requested scope, namely:
---
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.
---

In addition to the drafts noted in that request, RFC 9256 (Segment Routing
Policy Architecture) has already introduced the use of color in SR Policy
(Segment Routing Policy).  Section 2.1 of RFC 9256 requires use of color for SR
Policy identification, and section 8 of RFC 9256 makes extensive use of color
in procedures for BGP steering of traffic based on SR Policies.  I don't
believe that RFC 9256's extension of color to this sort of BGP steering poses
any serious transport-related concerns, even if that BGP functionality is used
to realize QoS differences among portions of traffic to the same destination. 
That's just as well, as any such concern would almost certainly also need to be
raised against RFC 9256, a Proposed Standard RFC, and not just against this
draft.

This draft is primarily concerned with how BGP carries SR Policy information
needed to realize the SR Policy functionality defined in RFC 9256.  That does
not raise any transport-related concerns beyond RFC 9256.