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

[Nat Kao <[e-mail]>]

Hi, Ketan.

If we make this CP "active", isn't it literally the"active path"?

In RFC9256 Sec. 2.9:
"A candidate path is selected when it is valid and it is determined to be
the best path of the SR Policy.
The selected path is referred to as the "active path" of the SR Policy in
this document."

Since this CP is invalid, should we avoid the term "active" here?

Suggestion:
"In this situation, the CP with the highest preference amongst those with
the "drop upon invalid" config is chosen to drop traffic steered over the
SR Policy."

Many Thanks,
Nat

On Tue, Mar 5, 2024 at 11:38 PM Ketan Talaulikar <[e-mail]>
wrote:

> 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
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>