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) - Extended 1 week to 3/7/2024

[Ketan Talaulikar <[e-mail]>]

Hi Sue/All,

Please find attached the diff of the changes for this draft as a result of
review comments received
- changed "optional" to "OPTIONAL" where necessary
- removed redundant text per Jeffrey's comment related to TEA TLVs
- added clarification for the I - flag for invalidation drop
- added reference to BGP-LS SR Policy draft per Boris comment

I will post this version once the submission tool reopens over the weekend.

Please let me know if there are any further comments/feedback.

Thanks,
Ketan


On Wed, Mar 13, 2024 at 10:06 PM Susan Hares <[e-mail]> wrote:

> IDR WG:
>
>
>
> I’m going to hold this WG LC for open until 3/18 (early am) to see if we
> get any responses.
>
>
>
> Cheerily, Sue
>
>
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Tuesday, March 5, 2024 10:38 AM
> *To:* Susan Hares <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* 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) - Extended 1
> week to 3/7/2024
>
>
>
>
>
> Hi All,
>
>
>
> I've received an offline comment from someone that is not subscribed to
> the IDR list on one of the documents related to the need of a clarification.
>
>
>
> The following is a proposal for the text change for the I flag in
> https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-01.html#section-2.4.2
> (as also 2.4.3):
>
>
>
> OLD:
>
> I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is used by
> SRPM as described in section 8.2 in [RFC9256
> <https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-01.html#RFC9256>
> ].
>
>
>
> NEW:
>
> I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is used by
> SRPM as described in section 8.2 in [RFC9256
> <https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-01.html#RFC9256>].
> The flag indicates that the CP is to perform the "drop upon invalid"
> behavior when no valid CP is available for this SR Policy. In this
> situation, the CP with the highest preference amongst those with the "drop
> upon invalid" config is made active to drop traffic steered over the SR
> Policy.
>
>
>
> Request the WG members to please review the same. If there are no
> objections, I would incorporate this in the next version that is due when
> the draft submission tool re-opens.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> On Sat, Mar 2, 2024 at 5:56 PM Susan Hares <[e-mail]> wrote:
>
> This call is extended 1 week to 3/7/2024 to allow others to comment on
> this call.
>
>
>
> Cheerily,
>
>
>
>
>
> 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
>
>