Rayhaan, Thank you for the presentation.
Homework from your session and discussion @ GROW (including some side discussions) is that I will follow up with Operational Message and perhaps try to get 2nd implementation for it. With that it may just catch momentum and your and few other needs may start to see the light at the end of the tunnel. Cheers, R. On Wed, Jul 28, 2021 at 1:01 AM Rayhaan Jaufeerally (IETF) <i...@rayhaan.ch> wrote: > 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 >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
