Re: [Idr] WG adoption call for draft-chen-mbinding (4/12/2023 to 4/26/2023)

[Ketan Talaulikar <[e-mail]>]

Hi Huaimo,

We seem to be going in circles so I will try to restate my view in a
different way.

1) Without a (SPRING WG?) document covering the Binding SID protection
mechanism, we are missing the base for any routing protocol extension such
as this draft. I hope the authors will address this gap - perhaps along
with the authors of draft-ietf-spring-segment-protection-sr-te-paths
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-sr-te-paths>
as
indicated by SPRING WG chairs?

2) Related to the BGP protocol mechanisms and procedures, based on your
responses, the draft is lacking the necessary details to describe how this
proposal is going to work. Messaging, correlation of the protection path on
what you say is the "PLR" with the actual SR Policy on a headend, etc. need
to be explained. I will look forward to an updated document with those
details before considering WG adoption. In the current state, the document
is not ready IMO.

Thanks,
Ketan


On Mon, May 1, 2023 at 9:34 PM Huaimo Chen <[e-mail]>
wrote:

> Hi Ketan,
>
>     Thanks much for your comments.
>     My responses are inline.
>
> Best Regards,
> Huaimo
> ------------------------------
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Thursday, April 27, 2023 8:23 AM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* Susan Hares <[e-mail]>; [e-mail] <[e-mail]>
> *Subject:* Re: [Idr] WG adoption call for draft-chen-mbinding (4/12/2023
> to 4/26/2023)
>
> Hi Huaimo,
>
> Please check inline below for my response.
>
> On Thu, Apr 27, 2023 at 3:29 AM Huaimo Chen <[e-mail]>
> wrote:
>
> Hi Ketan,
>
>
>
> Thanks much for your comments.
>
> My responses are inline.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Wednesday, April 26, 2023 2:00 PM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* Susan Hares <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] WG adoption call for draft-chen-mbinding (4/12/2023
> to 4/26/2023)
>
>
>
> Hi Huaimo,
>
>
>
> Thanks for your response and more importantly the update to the draft with
> the correct references.
>
>
>
> I now understand from the draft update and the pointer to your
> presentation at IETF 115 that this is about BSID protection.
>
>
>
> However, I still maintain that the draft is not ready for adoption by IDR
> for two reasons:
>
>
>
>    1. The actual framework and procedures for BSID protection are not yet
>    adopted or incorporated in the SPRING WG document. Therefore, it is
>    premature to discuss/evaluate the adoption of the related protocol
>    extensions in IDR.
>
> [HC]: As I said in the previous responses. The procedures for BSID
> protection is stable even though it is not adopted (Brief on adoption call
> on the draft: 18 supporters and 2 people not support. Even though those 2
> people do not support the draft, they seems support the protection for
> binding SIDs).
>
>
> KT> I don't know which adoption call and which draft it is that you are
> referring to. Some pointers would help.
>
> [HC2]: The pointer to the call is below
> https://mailarchive.ietf.org/arch/msg/spring/C_6p_1y1JP7BSAe1_8gmkkgci_s/
>
>
>
>
> 2) The procedures in this draft (sec 3) are not clear to me and therefore
> I am unable to evaluate the proposed encodings in section 2.
>
> When a BGP sends a binding to node N in a first Update message, the BGP
> distributes the corresponding binding protection information to the
> possible protecting nodes such as neighbors of node N in a second Update
> message. The first message contains a first SR Policy. The first SR Policy
> includes a binding SID and a path but does not include node N as a
> protected node. The second message contains a second SR Policy. The second
> SR Policy includes the binding SID, the path and node N as a protected node.
> ¶
> <https://datatracker.ietf.org/doc/html/draft-chen-idr-mbinding-01#section-3-1>
>
> What is the "first" and "second" message here? What is the BSID value that
> is carried in both of those? How are the updates for a specific SR Policy
> correlated between the headend and its protecting nodes?
>
> [HC]: BGP as a controller can send different messages to different network
> nodes. Here the "first" and "second" message just mean two different
> messages. One message (i.e., the first one) is sent to node N, the other
> (i.e., second one) is sent to the protecting nodes of node N.
>
>
> KT> Thanks for that clarification. Can you please update the document to
> describe the workflow clearly? As it is written, things are not clear (at
> least for me) to understand and evaluate the proposal in this draft.
> [HC2]: I will update the document accordingly.
>
>
> The BSID value is the same in the two messages. We may consider they are
> correlated through a BSID of node N.
>
>
> KT> As per RFC9256, BSID is not the identification of a SR Policy. So, is
> it even possible to do this correlation using BSID? Also, where is this
> described in the draft? Perhaps you have something in your mind but that is
> not clearly reflected in this draft (at least for me). Hence, my suggestion
> to please get the base framework and procedures for BSID protection
> solidified and adopted in SPRING WG to start with. Then, describe the BGP
> procedures and workflow in this IDR document so the WG can review to
> determine if the proposal is suitable and technically correct.
> [HC2]: BSID is not used as the ID of the SR policy by a protection node
> (PLR). The correlation is not used by a PLR either. The existing FRR for SR
> provides protections for node SID and adjacency SID of a node (say node N)
> when node N fails. When a PLR such as a neighbor of node N detects the
> failure of node N, it provides the protections for the node SID or
> adjacency SID of node N. The node SID or the adjacency SID of node N in a
> SR policy is not used as the ID of the SR policy by the PLR. The PLR does
> not use the correlation about the node SID and adjacency SID either. For
> example, for the adjacency SID of node N, the PLR gets the node SID of the
> remote node (the other end) of the adjacency from node N to the other end,
> replaces the adjacency SID with the node SID of the remote node in the
> packet, and sends the packet to the remote node without going through the
> failed node N. Protecting the BSID of node N is similar to protecting the
> adjacency SID of node N. The PLR replaces the BSID of node N with the SID
> list associated with the BSID in the packet, and sends the packet
> according to the top SID (the first SID in the SID list) without going
> through the failed node N. The information needed by the PLR for protecting
> the BSID of node N is <the BSID, the SID list, the ID of node N>.
>
> Thanks,
> Ketan
>
>
> The SR policy to the headend has a path with the BSID of node N, the SR
> policy to node N has the BSID and a SID list associated with the BSID, the
> message to a protecting node has the BSID of node N, the SID list and the
> ID of node N.
>
>
>
> In my view, this draft should be kept on hold until we have a SPRING WG
> document that describes the mechanism and procedures for BSID protection.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Mon, Apr 17, 2023 at 10:27 PM Huaimo Chen <[e-mail]>
> wrote:
>
> Hi Ketan,
>
>
>
> Thanks much for your further comments.
>
> My response are inline.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Wednesday, April 12, 2023 11:55 PM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* Susan Hares <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] WG adoption call for draft-chen-mbinding (4/12/2023
> to 4/26/2023)
>
>
>
> Hi Huaimo,
>
>
>
> I missed that this was indeed presented at 115 since the datatracker for
> the document didn't reflect that. My apologies.
>
>
>
> That said, I maintain my view that the document is not ready for adoption.
>
>
>
> How can one evaluate this draft for adoption without a proper description
> of the solution itself first? You mentioned some references but they are
> not mentioned in the draft and neither have you shared a pointer in your
> email response to me.
>
> [HC2]: Added references into the draft.
>
>
>
> Once the solution is evaluated (if it has been adopted in some other WG
> then IDR can take that as a basis), then comes evaluation of the part that
> BGP plays in the solution followed by the proposed encoding. As I see it,
> the draft seems to be putting the cart before the horse.
>
> [HC2]: The solution draft has been in SPRING WG for a long time, presented
> and discussed.  Brief on adoption call on the draft: 18 supporters and 2
> people not support. Even though those 2 people do not support the draft,
> they seems support the protection for binding SIDs.
>
>
>
> Thanks,
>
> Ketan
>
> On Wed, Apr 12, 2023 at 9:59 PM Huaimo Chen <[e-mail]>
> wrote:
>
> Hi Ketan,
>
>
>
> Thanks for your comments.
>
> My responses are inline.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Idr <[e-mail]> *On Behalf Of *Ketan Talaulikar
> *Sent:* Wednesday, April 12, 2023 12:21 PM
> *To:* Susan Hares <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Idr] WG adoption call for draft-chen-mbinding (4/12/2023
> to 4/26/2023)
>
>
>
> Hi Sue,
>
>
>
> The draft is so short that it covers only a protocol encoding proposal
> without adequately specifying the details of the "binding protection" and
> how it is actually applied in BGP-only or any network.
>
> [HC]: The details of the "binding protection" is out of scope of this
> draft, and is in other drafts. I will add references to those drafts.
>
>
>
> This is v00 that I don't even recall being presented in any IDR meeting.
> IMHO it needs much more details for at least me to fully understand/grasp
> what the proposal is.
>
> [HC]: I presented this draft in IETF 115.
>
> https://datatracker.ietf.org/meeting/115/materials/agenda-115-idr-01
>
>
>
> The document is not ready for consideration for WG adoption in my opinion.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Apr 12, 2023 at 7:00 PM Susan Hares <[e-mail]> wrote:
>
> This begins a two week adoption call call for draft-chen-idr-mbinding
> (4/12 to 4/26)
>
> https://datatracker.ietf.org/doc/draft-chen-idr-mbinding/
>
>
>
> All authors should reply to this adoption call message with an message
>
> Indicating whether they know of any IPR related to this draft.
>
>
>
> The authors have provided a good summary of the document in the following
> abstract:
>
>
>
>    BGP is used to distribute a binding SID with a list of SIDs to a
>
>    node.  This document describes extensions to BGP for distributing the
>
>    binding SID with the list of SIDs and an identifier of the node.
>
>    When detecting the failure of the node, an neighbor of the node
>
>    protects the binding SID of the failed node.
>
>
>
> This draft is short so it is an easy read.
>
>
>
> Consider in  your comments:
>
> 1) if this addition to segment routing policy
>
> (draft-ietf-idr-segment-routing-te-policy) is needed
>
> by operational networks.
>
>
>
> 2) if the technical specification is clear enough to
>
> begin working group review.
>
>
>
> Cheerily, Sue
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>