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

[Ketan Talaulikar <[e-mail]>]

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

In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM [RFC8986
<https://www.rfc-editor.org/rfc/rfc9256.html#RFC8986>]) 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://www.rfc-editor.org/rfc/rfc9256.html#RFC8986>]) MAY be associated
with the SR Policy.

Thanks,
Ketan


On Fri, Feb 16, 2024 at 12:41 PM Abhishek Chakraborty <[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]>
> *Sent:* Thursday, February 15, 2024 22: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,
>
> Please check inline for responses.
>
>
> On Fri, Feb 16, 2024 at 12:09 PM Abhishek Chakraborty <[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]>
> *Sent:* Thursday, February 15, 2024 21:00
> *To:* Ketan Talaulikar <[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
>
> 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]>
> *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
> ***********************************
>
>
>