Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Susan Hares <shares@ndzh.com> Sat, 26 March 2022 14:18 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B363A08C6 for <idr@ietfa.amsl.com>; Sat, 26 Mar 2022 07:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.94
X-Spam-Level:
X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2dwZWwC1LFw for <idr@ietfa.amsl.com>; Sat, 26 Mar 2022 07:17:56 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4F13A088F for <idr@ietf.org>; Sat, 26 Mar 2022 07:17:56 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.114.225;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
References: <00ca01d8348c$8b05d270$a1117750$@ndzh.com> <CAH6gdPxVQhx5RNtqXTnz7a+L2meiqhAT8evN0VrpgyL=JC6UnQ@mail.gmail.com> <eab3ec97ae0642458c62269a28b3818b@huawei.com> <CAH6gdPwtqXv6jRh3-xOVk51zAX+33PAPYGTqHqsF2cxnJvFaWw@mail.gmail.com> <b294ad1d928544c2a7603a6b6ad6b16f@huawei.com> <CAH6gdPy1eb=h_qx4xyFv0Uf9Hwk4o39MahvwJHYjDoSm3mp=Vg@mail.gmail.com> <daef61bded754c1db548951d2ff03a7a@huawei.com> <CAOj+MMF2-Vs2y0c71LpJSn=+08FtvKaG=fiaDfRiPAeKGRdGWQ@mail.gmail.com> <51ef8aa118b84cbb8be08c4b414e3f83@huawei.com> <e1e9ca6c94374cac940747263c86a73a@huawei.com>
In-Reply-To: <e1e9ca6c94374cac940747263c86a73a@huawei.com>
Date: Sat, 26 Mar 2022 10:17:48 -0400
Message-ID: <070201d8411c$46309b70$d291d250$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0703_01D840FA.BF275FE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQILMVkCQ/KfhDTgaiYAX9qxniU+qwHbjg4+Ajf6W1wBeGGergFXYzqwAk/4oqQBW7Be2QFsWXTkAlnXUP0BnR8uF6vsQPOw
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YQn3huPWMdTurxdSfBIFJTEzszQ>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Mar 2022 14:18:02 -0000

Greetings: 

 

The IDR chairs need to review the discussion here in depth prior to making a decision on this adoption call.   I will summarize the posts for this thread early next week, and indicate what questions I might have for IDR WG members.  

 

After we go through some Q/A, then the IDR chairs will discuss the results prior to making a decision.  It may be 2 weeks (4/8) before you get the final result.   Your feedback is welcome through-out this process.   We encourage discussions to continue on the list. 

 

Sue Hares

(IDR Chair Shepherd for adoption). 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Zhuangshunwan
Sent: Friday, March 25, 2022 6:38 AM
To: Wanghaibo (Rainsword); Robert Raszuk; Zhuangshunwan
Cc: idr@ietf.org; Susan Hares
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

 

Hi all,

 

Regarding the description of the usage of the extended community attributes, we will revise it in the next version based on all your useful suggestions.

If the working group recommends, we can only keep the next hop attribute solution in new version. Resubmission of another draft containing only the extended community attributes in the future will depend on requirements.

 

Additional info:

Almost all current implementations have CLI knobs to control the announcement of the extended community attributes (ECA), by default they are not sending ECA to their peers unless we explicitly enabled knobs on each peer.

Maybe we don't have to worry about a lot of ECAs appearing in the Internet routing table?

Moreover, our solution is used in various VPN scenarios, and the possibility of leakage is very very low.

 

Thanks,

Shunwan

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Wanghaibo (Rainsword)
Sent: Friday, March 25, 2022 6:05 PM
To: Robert Raszuk <robert@raszuk.net>; Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>
Cc: idr@ietf.org; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

 

Hi Robert,

 

The use of solutions should be designed and should not be used arbitrarily.

For this solution, it will mainly be used for VPN service. So I don’t think  it may cause leaking to Internet.

BTW, currently IANA has allocated a large number of EC attributes, does that mean we shouldn't continue to use EC attributes?

 

On the other hand, the author provides two extensions in this draft, and I think we should decide to choose one as the final implementation.

 

Regards,

Haibo

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, March 25, 2022 5:43 PM
To: Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>
Cc: Susan Hares <shares@ndzh.com>; idr@ietf.org
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

 

Zhuangshunwan,

 

I do not follow your logic. 

 

You can still advertise ifit capability per node or per tunnel (effectively per next hop) and have any service use subset of those as it seems fit for the service. 

 

There is no mandate that you must attach it with service routes at all. 

 

As said earlier if you remove idea to propagate this with extended community which is transitive and only limit it to non transitive next hop attribute damaged will be contained and perhaps we could consider adoption. Otherwise the blast radius is just too wide and adopting it encourages implementations which may be very dangerous by polluting the Internet with such ext comms leaking from some domains. 

 

Thx,
R.

 

 

On Fri, Mar 25, 2022 at 8:26 AM Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org> wrote:

Hi Ketan,

 Please check inline below with [SW2].

 

From: Ketan Talaulikar [mailto:ketant.ietf@gmail.com] 
Sent: Friday, March 25, 2022 11:56 AM
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: Tianran Zhou <zhoutianran@huawei.com>; idr@ietf.org; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

 

Hi Shunwan,

 

Please check inline below with KT2.

 

 

On Fri, Mar 25, 2022 at 8:09 AM Zhuangshunwan <zhuangshunwan@huawei.com> wrote:

Hi Ketan,

 

Please check inline below with [SW].

 

Kind Regards,

Shunwan

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, March 24, 2022 10:47 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: idr@ietf.org; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

 

Hi Tianran,

 

Please check inline below.

 

 

On Thu, Mar 24, 2022 at 7:16 PM Tianran Zhou <zhoutianran@huawei.com> wrote:

Hi Ketan,

 

“That said, I don't see the introduction discussing why this is appropriate in BGP. Since it talks about limited domain and overlay service, I am not able to follow how it helps signal only the capabilities of the PEs in a BGP-free core. Are capabilities not required for all nodes?”

 

[ZTR] In the IFIT detection domain, Ingress node inserts IFIT detection header into each selected flow packet, and the egress node remove the IFIT detection header from the packet, make sure IFIT detection header only happened in the IFIT detection domain.

       IFIT detection currently mainstream solution include E2E and hop-by-hop detection.

in E2E detection scenario, only ingress and egress node do the detection, transit node only transparent service flow with IFIT detection header

in hbh detection scenario, all the nodes along the service path can do the detection, and if one transit node does not support IFIT detection, does not impact other nodes working on detection. 

However, only PE nodes(include ingress and egress node) need insert or remove IFIT detection header.

So that, ingress node do the IFIT header insert operation only it makes sure egress node can remove IFIT header, otherwise, egress node will drop the flow packet embedded IFIT detection header due to it does not recognize this packet.

One available solution is that egress node notify ingress node before IFIT start detection, such as through method mentioned in the draft.

 

KT> It would be good if some of this context is described in the draft. A follow-on, if we have a mechanism for signaling IFIT capabilities hop-by-hop then does that not also cover end to end?

 

[SW] Surely, the above context will be added in the future version. We also especially welcome your help in improving this work. 

Yes, the hop-by-hop mechanism will be a long-term solution we pursue,  In the current stage where new and old devices are deployed together, we must first ensure that the tailend node can properly decapsulate the IFIT shim header. Therefore, a solution for signaling the IFIT capability between the headend and tailend nodes is also necessary.

 

 KT2> Fair enough. Look forward to the updates.

  

            

“First, which SAFI routes are these extensions going to get signaled with? Please point me to the text if I am missing something.”

 

[ZTR] This idea mainly suit for VPN scenarios, such as EVPNv4,EVPNv6,L2EVPN(EVPN VPWS and EVPN VPLS) routes... if needed can add the description in the update version.

 

KT> This is now very confusing to me. I thought this was something between PEs - what you refer to as IFIT encapsulating node. I no more understand why this needs to be associated with a service route? 

 

[SW]  This is actually a commonly used approach, such as the EVPN route carrying the Encapsulation Extended Community. Using this approach, service-driven deployment of IFIT can be achieved.

 

KT2> I think we are talking specifics of this draft and not a common approach. My understanding is the follows: IFIT encapsulating nodes are the PE routers. These extensions are about signaling IFIT capabilities - i.e. the capabilities of the PE routers. Then why do they need to be carried in the service routes that are potentially several orders of magnitude larger in scale than those corresponding to the PEs. What am I missing? Seems like the draft is missing quite a lot?

 

[SW2] IFIT deployment modes include node-level, tunnel-level, and service-level. While the current requirement is to provide IFIT deployment at service-level, since different services have different IFIT needs. The node-level and tunnel-level have also been considered, but they cannot meet the current needs. With the service-level solution, different IFIT modes can be deployed for different VPN services.

 

Thanks,

Shunwan

 

Thanks,

Ketan

 

 

Thanks,

Ketan

 

 

Many thanks,

Tianran

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 10:41 PM
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

 

Hi Sue,

 

Summary: I don't believe the draft is ready for WG adoption as yet.

 

Disclaimer: I do not fully understand the IFIT framework to judge if carrying/signaling this information in BGP makes sense. I'll leave that to others that do understand IFIT.

 

That said, I don't see the introduction discussing why this is appropriate in BGP. Since it talks about limited domain and overlay service, I am not able to follow how it helps signal only the capabilities of the PEs in a BGP-free core. Are capabilities not required for all nodes?

 

Coming to the draft itself and the BGP mechanics, there are some issues in the draft.

 

First, which SAFI routes are these extensions going to get signaled with? Please point me to the text if I am missing something.

 

Second, the draft describes two options. I have not seen any discussion either in the draft or on the IDR list on which of the two (or both?) are suitable. The only one to touch on this topic has been Jeff and the response to him was for the WG to pick. I think the WG needs to see those updates and the analysis in the document to be able to make that decision.

 

Alternately, can the proponents pick one? And if both are needed, clarify why?

 

The current draft says that the new community is transitive, but I guess it was meant to be non-transitive based on Shunwan's response? Would be important to fix that.

 

Please see inline responses to your specific questions.

 

1) Do the additions to BGP (2 Communities and

TLV for next-hop-capability attribute)

help the distribute information regarding the  IFIT options

from tail (egress) nodes to head nodes (ingress)?  

 

KT> I don't know since the draft does not specify how this works.

 

Are there any cases where these BGP

Communities should be removed or ignored?  

 

KT> Yes, but a bigger concern is that they are defined as transitive.

 

 

2) Are the mechanisms (2 Communities and

attribute TLV) correctly specified?

 

KT> A concern is why two?

 

3) How do these additions interaction with the

  With SR technology for IFIT described in

   draft-ietf-idr-sr-policy-ifit, and its

   use of RFC9012 (tunnel attributes)?

 

KT> I did not see any reference to RFC9012

 

(Authors an example on how these

technologies work together or

 operate separately would be helpful).

 

4)  Will this addition help network operators

deploying IFIT technology?

 

KT> Unable to determine.

 

Thanks,

Ketan

 

 

On Thu, Mar 10, 2022 at 8:09 PM Susan Hares <shares@ndzh.com> wrote:

Greeting: 

 

This begins a 2 week WG Adoption call (3/10/2022 to 3/24/2022) 

for draft-wang-idr-bgp-ifit-capabilities-04

https://datatracker.ietf.org/doc/draft-wang-idr-bgp-ifit-capabilities/

 

In your comments please consider if: 

 

1) Do the additions to BGP (2 Communities and 

TLV for next-hop-capability attribute) 

help the distribute information regarding the  IFIT options 

from tail (egress) nodes to head nodes (ingress)?  

 

Are there any cases where these BGP 

Communities should be removed or ignored?  

 

 

2) Are the mechanisms (2 Communities and 

attribute TLV) correctly specified? 

 

3) How do these additions interaction with the 

  With SR technology for IFIT described in 

   draft-ietf-idr-sr-policy-ifit, and its 

   use of RFC9012 (tunnel attributes)? 

 

(Authors an example on how these

technologies work together or 

 operate separately would be helpful). 

 

4)  Will this addition help network operators 

deploying IFIT technology? 

 

 

Cheerily, Sue 

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

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