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.