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

The draft update has now been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02

Thanks,
Ketan


On Sat, Mar 16, 2024 at 11:05 AM Nat Kao <[e-mail]> wrote:

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