Re: [Idr] Contents of Idr digest draft-ietf-idr-sr-policy-safi-00

[Abhishek Chakraborty <[e-mail]>]

Hi Ketan,

Got it. This draft then states that for SRMPLS Bsid there can be only one instance of the TLV. That's the meaning of that statement.


Best Regards,
Abhishek

Get Outlook for Android<https://aka.ms/AAb9ysg>



Juniper Business Use Only

________________________________
From: Ketan Talaulikar <[e-mail]>
Sent: Thursday, February 15, 2024 11:33:26 PM
To: Abhishek Chakraborty <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00


[External Email. Be cautious of content]


Hi Abhishek,

They are different sub-TLVs and there is nothing in the draft that says they cannot be signaled together.

More importantly, this is covered in https://www.rfc-editor.org/rfc/rfc9256.html#name-binding-sid<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9256.html*name-binding-sid__;Iw!!NEt6yMaO-gk!AafZcPr0qqsQezFYCyE0Y6i4W82OV5m6tgY0ZzYtuMK5sUBKoNG4XdGfgM7nVQZHbX2uepXeDxE8pHXY268$>

In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM [RFC8986<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9256.html*RFC8986__;Iw!!NEt6yMaO-gk!AafZcPr0qqsQezFYCyE0Y6i4W82OV5m6tgY0ZzYtuMK5sUBKoNG4XdGfgM7nVQZHbX2uepXeDxE8-EKnShA$>]) MAY be associated with the SR Policy in addition to the MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g., with different behaviors like End.B6.Encaps and End.B6.Encaps.Red [RFC8986<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9256.html*RFC8986__;Iw!!NEt6yMaO-gk!AafZcPr0qqsQezFYCyE0Y6i4W82OV5m6tgY0ZzYtuMK5sUBKoNG4XdGfgM7nVQZHbX2uepXeDxE8-EKnShA$>]) MAY be associated with the SR Policy.

Thanks,
Ketan


On Fri, Feb 16, 2024 at 12:41 PM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

"KT> Doesn't the same section 2.4.2 recommend use of the SRv6 Binding SID sub-TLV for such cases? And doesn't section 2.4.3 allow multiple SRv6 Binding SID sub-TLVs?"

CABHI> The draft talks about multiple SRv6 Binding SID. But it doesn't talk about the co-existence of a Binding SID TLV and SRV6 Binding SID TLV for the same policy. I was talking about that use case.

Best Regards,
Abhishek


Juniper Business Use Only

________________________________
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 15, 2024 22:48
To: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00


[External Email. Be cautious of content]


Hi Abhishek,

Please check inline for responses.


On Fri, Feb 16, 2024 at 12:09 PM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

The below statement:

"The Binding SID sub-TLV is optional and it MUST NOT appear more than once in the SR Policy encoding."

There can be a scenario of an SR-MPLS policy have a MPLS Label Binding SID and also an END.BM<https://urldefense.com/v3/__http://END.BM__;!!NEt6yMaO-gk!GkifL4OjeTvSv-hdf3eG2cVQCip-DvQnSFM0J6lEgO_eKrVblXXZLwgPT-SQXO4L1D9FJdJzkv9x6psVmA4$> Binding SID. In that case there can be 2 BSID TLVs right?

KT> Doesn't the same section 2.4.2 recommend use of the SRv6 Binding SID sub-TLV for such cases? And doesn't section 2.4.3 allow multiple SRv6 Binding SID sub-TLVs?

Thanks,
Ketan


Best Regards,
Abhishek



Juniper Business Use Only

________________________________
From: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 15, 2024 21:00
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00

Hi Ketan,

Yes, this is one more approach to skip a BSID TLV and expect the SRPM on the router to allocate one BSID. The method is outside the scope of this document.
But in this case there can be 2 behaviors from the controller:

  1.  The controller doesn't want a BSID and how does it indicate the router to remove it in the next update. Since the control of this Candidate Path is with the controller, do you think in this approach there should be a way to remove the BSID?
  2.  The controller wants to override the router allocated BSID with a value it wants. Then the controller can send a BSID TLV with a value different than the allocated value. Then the SRPM on the router can override the value with controller's value. Now, here if we need to fallback to the router allocated value again, does the controller send the Next Update without BSID TLV?

May be specifying these behaviors make it clear on BSID allocation.

Best Regards,
Abhishek
________________________________
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 15, 2024 20:48
To: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00

[External Email. Be cautious of content]

Hi Abhishek,

The Binding SID sub-TLV is optional and can be skipped. This indicates that the controller is not specifying a BSID and nor is it indicating a behavior like "drop-upon-invalid". In this case, per RFC9256, the SRPM on the router will do the BSID allocation.

Do we really need any flag? If this was not evident, then perhaps we can add text to section 2.4.2 to clarify this.

Thanks,
Ketan


On Fri, Feb 16, 2024 at 9:40 AM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

The binding sid section can we modify with additional flag to request a node to allocate a bsid? It can be a small section added.

I see 2 approaches:
1st approach:
Flag:
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I| D       |
+-+-+-+-+-+-+-+-+

Figure 5: Binding SID Flags

The D flag with a BSID TLV with an empty BSID value indicates the router to dynamically allocate a BSID.

For flag approach update section 6.6.

2nd approach:
No need of new flag. An BSID TLV without any flag set and empty BSID value indicates that the router allocates the BSID.

The next update MUST come with the router allocated BSID learnt by controller through various method outside the scope of this document.
If the controller sent the next update:

  1.  At any given point of time the controller wants to remove the router allocated BSID, MUST send an update with no BSID TLV.
  2.
At any given point of time the controller wants to change the router allocated BSID, MUST send an update with a specified BSID.


Best Regards,
Abhishek

Get Outlook for Android<https://urldefense.com/v3/__https://aka.ms/AAb9ysg__;!!NEt6yMaO-gk!GgJnf55kHDAOoUFb8ZLFk1Dm0ZUliZK7vt7uuSFL9VZ7RlMKCCXfoYp8l2WiMKsLXNhAMwqT5sxACW1jud0$>



Juniper Business Use Only

________________________________
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 15, 2024 7:47:30 PM
To: Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00

[External Email. Be cautious of content]

Hi Abhishek,

Thanks for your review and your suggestions.

Most of your comments seem of the nature of additions/augmentation to this document to me. Would you agree? If so, I would rather that these extensions be done via other/new documents (there are already many of them out there with extensions for this SAFI).

To give some context, this document started as an individual draft in Oct 2015, became WG draft in Jul 2017 and underwent 26+1 versions during its WG life of almost 6 years. I hope that the WG wants to "ship it" at this point after fixing issues (if any) with the current content.

That said, please check inline below for some pointers.


On Fri, Feb 16, 2024 at 4:36 AM Abhishek Chakraborty <[e-mail]<mailto:[e-mail]>> wrote:

Hello Authors,

Please find my comments on the draft draft-ietf-idr-sr-policy-safi-00:

  1.
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-00#section-2.4.4<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-00*section-2.4.4__;Iw!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axe_pN-j0$>
     *
A segment-list sub-tlv can carry its path-id or a segment-list id that can be used in various use cases. One example is telemetry. I believe the Yang Data Model of a segment-list also has a segment-list ID associated. This ID can be reported via BGP-LS to the controller.

KT> Please check https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-seglist-id/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-seglist-id/__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axROHJu2M$>

     *
To be in sync with PCEP multipath draft https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axNtd4IMQ$> can we include the TLVs to advertise:

        *
The backup Path for a segment-list sub tlv. This would help in many use cases to steer the traffic to a backup path when the primary segment-list is unreachable/down. The path ID or segment list ID introduction will help distinguish and map a backup path to its primary path.
        *
The reverse path or opposite direction PATH sub tlv which can be used by SRPM.
  1.
A new metric Sub TLV addition:
     *
A metric sub tlv to indicate on what metric the Candidate Path is optimized or computed against.
        *
Use case:
           *
This metric can be advertised in BGP MED or can be used for BGP best path selection.

KT> Please check https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-metric/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-metric/__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axnsurlKI$>

Thanks,
Ketan

  1.
Introduction of a new flag in https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26#name-binding-sid-sub-tlv<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26*name-binding-sid-sub-tlv__;Iw!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_ax1D89LDw$>:
     *
to indicate the node or router to allocate a Binding SID. In some cases, the controller may want the node to allocate the Binding SID for the Candidate Path depending on:

        *
Already available Active Binding SID for that SR policy.
           *
Example:
              *
PCEP Candidate Path CP1 for Policy P1 requests Binding SID as per draft https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_ax17bWE5I$>. A dynamic BSID is allocated say B1.

              *
BGP-SRTE path requests the router to allocate a dynamic Binding SID for CP2 of policy P1. Router allocates the same Binding SID B1. This helps is fallback cases.
        *
The availability of Binding SID from a range that the node or router knows.

Thanks, and Regards,
Abhishek



  1.




Juniper Business Use Only

________________________________
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 15, 2024 14:13
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Idr Digest, Vol 238, Issue 9

[External Email. Be cautious of content]


Send Idr mailing list submissions to
        [e-mail]<mailto:[e-mail]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK8fo4EyA$
or, via email, send a message with subject or body 'help' to
        [e-mail]<mailto:[e-mail]>

You can reach the person managing the list at
        [e-mail]<mailto:[e-mail]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Idr digest..."


Today's Topics:

   1. 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)
      (Susan Hares)


----------------------------------------------------------------------

Message: 1
Date: Thu, 15 Feb 2024 22:12:55 +0000
From: Susan Hares <[e-mail]<mailto:[e-mail]>>
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [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)
Message-ID:
        <[e-mail]<mailto:[e-mail]>>

Content-Type: text/plain; charset="us-ascii"

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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK0K-D6Q8$

  *   draft-ietf-idr-bgp-sr-segtypes-ext-02 (experimental)

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sr-segtypes-ext/__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZKMrsVAu8$

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://urldefense.com/v3/__https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZKoZPXAok$

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/idr/attachments/20240215/9c1e0641/attachment.htm__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK0bmhsvo$ >

------------------------------

Subject: Digest Footer

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK8fo4EyA$


------------------------------

End of Idr Digest, Vol 238, Issue 9
***********************************