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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>