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

[Ketan Talaulikar <[e-mail]>]

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?


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

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