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 <
[email protected]> 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) <[email protected]>
> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/grow
>>
>
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
