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

[Abhishek Chakraborty <[e-mail]>]

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://aka.ms/AAb9ysg>



Juniper Business Use Only

________________________________
From: Ketan Talaulikar <[e-mail]>
Sent: Thursday, February 15, 2024 7:47:30 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,

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