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

Haibo,

Sure I get your objective here.

The point is that sending anything in dynamic routing protocol is sound
only when receivers perform well defined actions on the received data.

Here you however still need a process (likely management driven) to trigger
telemetry sessions as any to any for all negotiated capabilities hardly
makes sense. Leave alone clock sync point I mentioned before what BGP (I
hope) will not be asked to signal.

So this proposal creates a local database with remote telemetry peers and
their capabilities on each BGP speaker. What if I want to use In-situ Flow
Information Telemetry between my 10 sites over Internet ? That means that
millions of other Internet routers will now have to carry this extended
community (or extension to NH Capability Attribute) ?

How would it even work for my use case if lot's of ISPs filters extended
communities and NH Capability Attribute is non-transitive by design ?

I am still not convinced this is good idea to add this as general extension
to BGP.

Many thx,
R.

On Thu, Mar 17, 2022 at 12:53 PM Wanghaibo (Rainsword) <
rainsword.wang@huawei.com> wrote:

> Hi Robert,
>
>
>
>        [Bottom line - not everything that can be fitted into a BGP
> attribute should be carried by BGP protocol.]
>
>     I agree with this point.
>
>
>
>     But I still think the iFit extension here is appropriate.
>
>   The Pub-sub model is a centralized service model, it’s complexable for
> dynamic changed service.
>
>     The iFit extension here is a distributed service driven model. Service
> routes advertised with iFit capability will bring simplifying deployment.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, March 12, 2022 4:33 AM
> *To:* Jeffrey Haas <jhaas@pfrc.org>
> *Cc:* idr@ietf. org <idr@ietf.org>; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] Adoption call for
> draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)
>
>
>
> Hello Jeff & WG,
>
>
>
> I am a big supporter of In-Situ Telemetry. Well modulo the fact - and in
> fact show stopper - that to make it really useful very precise nano seconds
> clock synchronization is required and that by itself is not an easy task to
> accomplish in WAN or MAN networks. The only tools I see to help here are
> PTP or gPTP but PTP mostly is deployable in DCs not in WANs.
>
>
>
> As far as BGP is concerned I must ask why do we really need p2mp
> signalling to spray such information to all BGP speakers ? In Situ
> telemetry can be deployed end to end beyond BGP speaking network elements
> so it will not help.
>
>
>
> Moreover we are really stepping again on using BGP protocol as a network
> management carrier. Such distribution would be much better served by the
> pub-sub model. Such model can be realized by any message bus or by
> leveraging a recent proposal from Tony -
> https://datatracker.ietf.org/doc/draft-li-lsr-liveness/  Yes this
> currently was done to address IGP node liveness propagation, but nothing
> stands against reusing such idea for pub-sub distribution of other node
> capabilities like ifit.
>
>
>
> Bottom line - not everything that can be fitted into a BGP attribute
> should be carried by BGP protocol.
>
>
>
> Kind regards,
>
> R.
>
>
>
>
>
> On Fri, Mar 11, 2022 at 7:17 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> Sue and Working Group,
>
> I'm generally supportive of IFIT for BGP.
>
> For this particular document, I think it'd be helpful if the authors
> provided some more detail on the scoping of the BGP Extended Community
> attributes and their security considerations.
>
> In particular:
>
> On Thu, Mar 10, 2022 at 09:38:43AM -0500, Susan Hares wrote:
> > 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?
>
> >From the Security Considerations for draft-ietf-idr-sr-policy-ifit-03:
>
> :   IFIT data MUST be propagated in a limited domain in order to avoid
> :   malicious attacks and solutions to ensure this requirement are
> :   respectively discussed in [I-D.ietf-ippm-ioam-data] and
> :   [I-D.ietf-6man-ipv6-alt-mark].
>
> 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.
>
> Please note that forms of this question were raised both on the mailing
> list
> in prior threads and also during IDR IETF sessions.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>