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 the update and the document now looks clearer to me.

Thanks,
Ketan

On Mon, May 9, 2022 at 3:51 PM Zhuangshunwan <zhuangshunwan@huawei.com>
wrote:

> 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:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Monday, May 9, 2022 5:54 PM
> To: i-d-announce@ietf.org
> Cc: idr@ietf.org
> 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
>
> I-D-Announce@ietf.org
>
> 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:ketant.ietf@gmail.com]
> *Sent:* Tuesday, May 3, 2022 10:41 AM
> *To:* Zhuangshunwan <zhuangshunwan@huawei.com>
> *Cc:* Susan Hares <shares@ndzh.com>; idr@ietf.org; wangyali@hauwei.com;
> zhuangshunwan@hauwei.com; guyuan@huawei.com; pangran@huawei.com
> *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=
> 40huawei.com@dmarc.ietf.org> 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 <idr-bounces@ietf.org> *On Behalf Of *Susan Hares
> *Sent:* Monday, April 25, 2022 9:06 PM
> *To:* idr@ietf.org
> *Cc:* wangyali@hauwei.com; zhuangshunwan@hauwei.com; guyuan@huawei.com;
> pangran@huawei.com
> *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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>