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

Hi Robert,

    Thanks much for your comments.
    My responses are inline.

Best Regards,
Huaimo
________________________________
From: Robert Raszuk <robert@raszuk.net>
Sent: Wednesday, April 26, 2023 2:57 PM
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org <idr@ietf.org>
Subject: Re: [Idr] WG adoption call for draft-chen-mbinding (4/12/2023 to 4/26/2023)

Hi Ketan,

Yup this is exactly the issue I am struggling to understand too.

See aside from the fact that in BGP we do not have notion of first and second messages I fail to understand why first message is not enough.
[HC]: BGP as a controller can send different messages to different network nodes. For example, it can send a SR policy (a message) to a headend node (i.e., ingress node of a SR path), and send another policy (another message) with a BSID and a SID list to node N. In the draft, the first and second messages juse mean different messages. One message (i.e., the first message) is sent to node N, and the other message (i.e., the second message) is sent to the protecting nodes. These two message are different.

When first message is distributed receiving node N get's it so in true BGP p2mp fashion it's peers will also get it. As node N is identified in the message it's pretty trivial for any node to check if their peer is such node N and if configured so reuse this information to apply protection.
[HC]: The message to the protecting nodes for node N is different from the message to node N. In addition to the ID of node N, the SID list in the message to the protecting nodes may be different from the SID list in the message to node N. For example, when BGP as a controller sends node N a message containing a BSID of node N and a SID list with an adjacency SID of node N as the first SID in the list, it may get the node SID of the remote node from the adjacency SID and send a protecting node another message containing the BSID of node N and a SID list containing the node SID of the remote as the first SID.

Why do we need two messages remains unknown. And if we just do what is described above we really do not need this draft at all as all it does is defines a "protected node".
[HC]: Refer to the above.

Many thx,
R.

On Wed, Apr 26, 2023 at 8:00 PM Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> wrote:
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.

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?

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 <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>> wrote:

Hi Ketan,

Thanks much for your further comments.

My response are inline.

Best Regards,

Huaimo

From: Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>>
Sent: Wednesday, April 12, 2023 11:55 PM
To: Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>>
Cc: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
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 <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>> wrote:

Hi Ketan,

Thanks for your comments.

My responses are inline.

Best Regards,

Huaimo

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Ketan Talaulikar
Sent: Wednesday, April 12, 2023 12:21 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
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 <shares@ndzh.com<mailto:shares@ndzh.com>> 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
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr