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.

Thanks for the clarification. I've got your point.
The definition of "active" aligns with the reporting mechanism(ex: A-Flag
in draft-ietf-idr-bgp-ls-sr-policy)
It means "provisioned/instantiated in the FIB" instead of the "active CP."

Many Thanks,
Nat

On Fri, Mar 15, 2024 at 6:32 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Nat,
>
> There are other considerations as well when we look at the reporting
> aspects where the CP provisioned in the forwarding is reported as "active".
> I hope the updated text and this discussion will clarify these aspects.
>
> Thanks,
> Ketan
>
>
> On Fri, Mar 8, 2024 at 11:08 PM Nat Kao <[e-mail]> wrote:
>
>> Hi, Ketan,
>>
>> I totally agree with you that the CP should be instantiated as stated in
>> RFC9256 Sec. 2.11.
>> My concern is that the term "made active" might be confused with the term
>> "active CP"
>> By the definition in RFC9256 Sec. 2.9, these invalid CPs should not be
>> considered as active CPs.
>>
>> Maybe we can align the term with RFC9256 Sec. 8.2 & Sec. 2.11:
>> "In this situation, the CP with the highest preference amongst those with
>> the "Drop Upon Invalid" behavior is instantiated in the forwarding plane to
>> drop traffic steered over the SR Policy."
>>
>> Many Thanks,
>> Nat
>>
>> On Fri, Mar 8, 2024 at 8:26 PM Ketan Talaulikar <[e-mail]>
>> wrote:
>>
>>> 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
>>>>>
>>>>