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

["Wanghaibo (Rainsword)" <[e-mail]>]

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:[e-mail]] On Behalf Of Robert Raszuk
Sent: Friday, March 25, 2022 5:43 PM
To: Zhuangshunwan <zhuangshunwan=[e-mail]>
Cc: Susan Hares <[e-mail]>; [e-mail]
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=[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,
 Please check inline below with [SW2].

From: Ketan Talaulikar [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, March 25, 2022 11:56 AM
To: Zhuangshunwan <[e-mail]<mailto:[e-mail]>>
Cc: Tianran Zhou <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

Please check inline below with [SW].

Kind Regards,
Shunwan

From: Idr [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Ketan Talaulikar
Sent: Thursday, March 24, 2022 10:47 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 10:41 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr