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

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