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)

Hi,

I’m not aware of any undisclosed IPR related to this draft.

Thanks.
s.

> On Feb 15, 2024, at 11:12 PM, Susan Hares <shares@ndzh.com> wrote:
> 
> 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/ <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/ <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 <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   
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>