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

[Tianran Zhou <[e-mail]>]

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.


“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.

Many thanks,
Tianran

From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 10:41 PM
To: Susan Hares <[e-mail]>
Cc: [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