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

[Ketan Talaulikar <[e-mail]>]

Hi Shunwan,

Please check inline below with KT2.


On Fri, Mar 25, 2022 at 8:09 AM Zhuangshunwan <[e-mail]>
wrote:

> Hi Ketan,
>
>
>
> Please check inline below with [SW].
>
>
>
> Kind Regards,
>
> Shunwan
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Ketan Talaulikar
> *Sent:* Thursday, March 24, 2022 10:47 PM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* [e-mail]; Susan Hares <[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]>
> 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?

Thanks,
Ketan


>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/idr
>
>