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,

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