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

[Ketan Talaulikar <[e-mail]>]

Hi Abhishek,

Please check inline below.


On Fri, Feb 16, 2024 at 10:30 AM Abhishek Chakraborty <[e-mail]>
wrote:

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

KT> The allocation and management of BSID by SRPM is outside the scope of
this document. It is covered by RFC9256.


> 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?
>
> KT> The controller can specify its own BSID value or not. BGP SR Policy
SAFI only provides the way to signal the BSID that the controller wishes to
assign. The headend will allocate a BSID by itself as described in
RFC9256.

>
>    1. 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?
>
> KT> Yes


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

KT> This is covered by RFC9256


>
> Best Regards,
> Abhishek
>
> Juniper Business Use Only
> ------------------------------
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Thursday, February 15, 2024 20:48
> *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,
>
> 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]>
> 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]>
> *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]>
> 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$>
>
>    1. 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$>
>
>
>
>    1. 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:
>
>       1. 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.
>          2. The reverse path or opposite direction PATH sub tlv which can
>          be used by SRPM.
>          1. A new metric Sub TLV addition:
>    1. A metric sub tlv to indicate on what metric the Candidate Path is
>       optimized or computed against.
>       1. Use case:
>          1. 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$>
>    :
>    1. 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:
>
>       1. Already available Active Binding SID for that SR policy.
>          1. Example:
>             1. 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.
>
>                2. 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.
>                2. 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]> on behalf of [e-mail] <
> [e-mail]>
> *Sent:* Thursday, February 15, 2024 14:13
> *To:* [e-mail] <[e-mail]>
> *Subject:* Idr Digest, Vol 238, Issue 9
>
> [External Email. Be cautious of content]
>
>
> Send Idr mailing list submissions to
>         [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]
>
> You can reach the person managing the list at
>         [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]>
> To: "[e-mail]" <[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]
> >
>
> 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]
>
> 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
> ***********************************
>
>
>