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 Nat,

You are right that normally the "active" CP is a valid CP as indicated in
RFC9256 sec 2.9 for the actual forwarding of traffic steered into the SR
Policy. However, in order to drop traffic as well, a CP has to be
instantiated in the forwarding (along with its BSID) and hence that CP is
considered "active" - please also check sec 2.11.

I hope this clarifies.

Thanks,
Ketan


On Wed, Mar 6, 2024 at 2:29 PM Nat Kao <[e-mail]> wrote:

> 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
>>
>