Thanks for the feedback here and in the session, I agree that using AFI / MP is a hack and would be better served by an operational style message. I'm not sure how to take that work and adapt it to carry the information for communicating route rejection based on policy. I guess it would be a new draft and cite the operational message in the acknowledgements?
My key takeaways from the discussion in the meeting: - The problem that is to be solved is: "Did the peer accept a route which a speaker sent". - Explicitly say forwarding routes to other peers is out of scope because that depends on other factors that not all networks want to share - A looking glass does not actually show the state of the RIB of the peering router, because provider architectures send the routes from the ASBR through other internal mechanisms before showing up on the looking glass, and as such looking at the LG, it's not clear or not visible at all what happened to a particular route. - It's cleaner to flip the problem statement around: "Did a route that a peer sent get rejected (i.e. not imported to the local RIB or considered as a viable path) for some policy reason?". - There is also value in collecting looking glass addresses, but that's out of scope of what this discussion is about, maybe some kind of DNS SRV record on the peering router's IP or something but look into that separately. Cheers, Rayhaan On Tue, Jul 27, 2021 at 11:25 PM Thomas Mangin < thomas.man...@exa-networks.co.uk> wrote: > Hello everyone, > > While quite a few drafts have been using attributes to carry weird > information into BGP, this one proposes to use MP. > I can see how one may think it would be helpful and reduce implementation > burgen but I am not sure it is wise and I believe it goes beyond what > AFI/SAFI are for. > > Also this reminds me very much of > https://datatracker.ietf.org/doc/html/draft-ietf-idr-operational-message > which I implemented but never saw traction. > So while I can see why this would benefit operational matters, I do not > believe the RFC as proposed should be accepted. > > Sorry for being such a party pooper ! > > Thomas > > On Sat, 24 Apr 2021 at 14:38, Rayhaan Jaufeerally (IETF) <i...@rayhaan.ch> > wrote: > >> Dear GROW chairs and participants, >> >> I would like to propose draft-jaufeerally-bgp-lg-cap-00 ( >> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a >> mechanism for in-band dissemination of looking glass endpoints in BGP, >> using a new OPEN message capability. >> >> The rationale behind this is to facilitate automation around eBGP >> peering, for example to make it possible to automatically detect if the >> peer has accepted some routes which are expected to be accepted. >> >> I'm aware that the underlying RFC8522 is an informational RFC and leaves >> some details unspecified for the response format (i.e. a schema for the >> queries/responses) but I believe that can be further refined in other works >> independent to this proposal. >> >> I would like to hear what the WG thinks, if this is a reasonable proposal >> which fits into the broader charter of GROW? >> >> Thanks, >> Rayhaan >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow