Re: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024)

[[e-mail]]

Hi Sue&WG，

I read the latest version, and I support publication of both of these drafts.

Best Regards，
Ran


Original


From: SusanHares <[e-mail]>
To: [e-mail] <[e-mail]>;
Date: 2024年02月16日 06:13
Subject: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024)

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

 

Greetings IDR: 
 
This begins a 2-week WG LC on the following two drafts created from the text in 
draft-ietf-idr-segment-routing-te-policy-18 – that the IDR WG approved for publication: 
 

draft-ietf-idr-sr-policy-safi-00  (proposed standard)  


https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/

draft-ietf-idr-bgp-sr-segtypes-ext-02 (experimental) 


https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sr-segtypes-ext/
 
The Authors (per IETF policy) are asked to respond to this message with a 
message indicating whether they know of any undisclosed IPR as the documents stand now. 
Please note there are 3 IPR declarations on these drafts.  
 
History:
======
After reviewing draft-ietf-idr-segment-routing-te-policy-18, Andrew Alston (IDR RTG AD) 
asked that draft-ietf-idr-segment-routing-te-policy be split into two parts because 
some segment types (C-L) did not have two implementations.    
Therefore, draft-ietf-idr-bgp-srsegtypes-ext-02 contains the text for 
Segment types C-L.   This split has been discussed at IETF meetings. 
 
Since Andrew Alston had personally implemented this draft, 
he also asked for additional reviews on procedures. 
 
During this review, the procedures regarding the link to RFC9012 were improved. 
 
Issues in call: 
============
During the WG should note that the procedures specified in 
draft-ietf-idr-sr-policy-safi-00 do the following: 
 

Only apply to the SR Policy Tunnel (15) + SR Policy SAFI  

Do not require any of the TLVs defined in RFC9012 for other tunnel types  

May ignore TLVs defined in RFC9012 for other tunnel types 

Do not use the validation process in RFC9012, and depend on the SRPM to validate content. 

Makes changes to Color Extended Community [RFC9012] to add to 2-bits [C, O]   


To support “color-only” (CO)  functions of section 8.8 of [RFC9256] 
 
C0 – type 0 (00) – Specific end-point match (Match endpoint that is BGP NH) 
         type 1 (01) - Specific or null end-point match (BGP NH or null (default gw))
         type 2 (10) – Specific, null, or any end-point match (BGP NH, Null, or any endpoint) 
         type 3 (11) – Reserved   
 
The SR Policy Tunnel functions in this draft use BGP as a transport mechanism for the 
Information contained in the SR Policy.
 
Please note that these procedures split the context validation away from the 
BGP module into the SRPM module.   This split is similar to the BGP-LS split 
syntax validation from context validation.  
 
There are multiple implementations of this technology as detailed at: 
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement
 
The WG members are asked to confirm their agreement to the changes made in this document. 
 
If there are questions, please ask them on this mail thread.  Please note any errors in the call are mine (and not the authors). 
 
Cheerily, Sue