Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24) - 1 week extension to answer questions [4/25/22 to 5/2/22]

[Zhuangshunwan <[e-mail]>]

Hi Ketan & WG,

We (co-authors) have post a new version to address the comments received. Thanks for everyone's comments and suggestions!
Please help to confirm whether the comments have been resolved, and more comments and suggestions are welcome!


Best Regards,

Shunwan



-----Original Message-----
From: I-D-Announce [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, May 9, 2022 5:54 PM
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action: draft-wang-idr-bgp-ifit-capabilities-05.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Inter-Domain Routing WG of the IETF.



        Title           : BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities

        Authors         : Giuseppe Fioccola

                          Ran Pang

                          Shunwan Zhuang

                          Hiabo Wang

        Filename        : draft-wang-idr-bgp-ifit-capabilities-05.txt

        Pages           : 10

        Date            : 2022-05-09



Abstract:

   This document defines extensions to BGP [RFC4271] to advertise the

   In-situ Flow Information Telemetry (IFIT) capabilities.  Within an

   IFIT domain, IFIT-capability advertisement from the tail node to the

   head node assists the head node to determine whether a particular

   IFIT Option type can be encapsulated in data packets.  Such

   advertisement would be useful for mitigating the leakage threat and

   facilitating the deployment of IFIT measurements on a per-service and

   on-demand basis.







The IETF datatracker status page for this draft is:

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



There is also an htmlized version available at:

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



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-wang-idr-bgp-ifit-capabilities-05





Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts





_______________________________________________

I-D-Announce mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From: Ketan Talaulikar [mailto:[e-mail]]
Sent: Tuesday, May 3, 2022 10:41 AM
To: Zhuangshunwan <[e-mail]>
Cc: Susan Hares <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24) - 1 week extension to answer questions [4/25/22 to 5/2/22]

Hi Shunwan,

Thanks for your responses to Sue's questions as well as the discussions during the WG adoption. It would be great if the authors would post a version that incorporates all the changes and clarifications that came out of the discussion (as also mentioned by you below). This would enable some of us that had concerns to re-review the document and respond if our (blocking IMHO) concerns have been addressed.

Thanks,
Ketan

PS: If the authors prefer the NH capability solution, then please just remove the other one from the document. It will keep the draft focused. Just a suggestion ...


On Sun, May 1, 2022 at 8:09 PM Zhuangshunwan <zhuangshunwan=[e-mail]<mailto:[e-mail]>> wrote:
Hi Sue and WG,

Thank you all for giving us a lot of useful input on this work!
Regarding the following 3 questions, our answers are as follows:

1)  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 requirements. The node-level and tunnel-level have also been considered, but they cannot meet the current requirements. With the service-level solution, different IFIT modes can be deployed for different VPN services.

2) When all devices are upgraded to support IFIT, the hop-by-hop mechanism is suitable.
In the current stage where new and old devices are deployed together, we must first ensure that the tail-end node can properly decapsulate the IFIT shim header, so we need head-end/tail-end way.
Further, different services on the egress node have different IFIT requirements, so the head-end/tail-end way is always required.
Hop-by-hop mechanisms and head-end/tail-end can be used together without conflict.

3) In actual deployment, whether it is Transitive or non-Transitive, the extended community attributes are controlled hop-by-hop via CLI (knob), and there is almost no possibility of the extended community attributes leaking into the Internet routing table.  In this draft, the Extended Communities will be explicitly defined as non-transitive.

In the next version, we will prefer the NextHop Capability solution and move the extended community attributes to the appendix.

Regards,
Authors of draft-wang-idr-bgp-ifit-capabilities

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: Monday, April 25, 2022 9:06 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24) - 1 week extension to answer questions [4/25/22 to 5/2/22]

Greetings:

The adoption call for draft-wang-idr-bgp-ifit-capabilities indicated
Interest in refining this draft.   We had 10+ people interesting
in this draft including 3 operators who felt it was necessary for
operation in their network.  While some of the use cases
were for specific customers, this has not stop adoption of
many SR or BGP-LS features.

However, prior to finalizing adoption, it would be good for
the authors to answer the following questions asked during the
adoption call.

Cheerily, Sue

Questions


1)       [Ketan] 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?


Email thread:
https://mailarchive.ietf.org/arch/msg/idr/qDxpzXvL7wm2KxmUNdyCqvFMXSU/



2)       What is the plan for hop-by-hop mechanisms versus head-end/tail-end



Email thread:

https://mailarchive.ietf.org/arch/msg/idr/qDxpzXvL7wm2KxmUNdyCqvFMXSU/



[Ketan]  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?

[Shunwan] answer:

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 tail-end node can properly

decapsulate the IFIT shim  header. Therefore, a solution for

 signaling the IFIT capability between the head-end

 and tail-end nodes is also necessary.



3)       Next Hop Capability as a Optional Non-Transitive Path Attribute
[Jeff Haas questions]
https://mailarchive.ietf.org/arch/msg/idr/BBE3N6m4HX21euJyVvK6VVa2IZI/


The NextHop Capability leveraged in this draft as part of prior learnings

has specified itself as an Optional, Non-Transitive Path Attribute.  This

means that behaviors can be enforced on a hop-by-hop basis.



BGP Extended Communities are only scoped for as-transitive or not.



It'd be useful for the authors to comment on what the expected behaviors for

BGP speakers downstream of not the IFIT egress. Also, potentially outside

of the IFIT domain.  What are the Security Considerations for such

additional propagation of these Extended Communities?



I'm unclear whether the intent of the Extended Communities is whether they

should ONLY be propagated with the NextHop Capability or not.



_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr