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)

[Nat Kao <[e-mail]>]

Hi, Sue.

I support these 2 drafts.
It's desirable to signal TE paths using fewer protocols to reduce overhead.
These drafts provide a clean architecture to distribute SR-Policy CPs using
existing BGP, which is very useful.

Thanks,
Nat

On Fri, Feb 16, 2024 at 6:13 AM Susan Hares <[e-mail]> 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/
>
>    - 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:
>
>
>
>    1. Only apply to the SR Policy Tunnel (15) + SR Policy SAFI
>    2. Do not require any of the TLVs defined in RFC9012 for other tunnel
>    types
>    3. May ignore TLVs defined in RFC9012 for other tunnel types
>    4. Do not use the validation process in RFC9012, and depend on the
>    SRPM to validate content.
>    5. 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
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>