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

Hi Robert，

This solution depends on the application scenario.
Generally, this configuration is not applicable to common Internet services. This solution is deployed in a limited domain.

Regards,
Haibo

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Thursday, March 17, 2022 8:38 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>; 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)

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<mailto: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<mailto:idr-bounces@ietf.org>] On Behalf Of Robert Raszuk
Sent: Saturday, March 12, 2022 4:33 AM
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; Susan Hares <shares@ndzh.com<mailto: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<mailto: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<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr