Re: [GROW] BGP Looking Glass Capability

["Rayhaan Jaufeerally (IETF)" <[e-mail]>]

Thanks for the reply and the great points Robert,

On Sun, Jul 25, 2021 at 10:58 PM Robert Raszuk <[e-mail]> wrote:

> Dear Rayhaan,
>
> Thank you for working on this draft.
>
> As far as your suggestion to use new SAFI to auto discover presence and
> addresses of Looking Glass servers across ASN boundaries I have
> nothing against.
>

Ah I just realized that you mention SAFI here, but when writing the draft I
was thinking about an AFI. Now that you mention it though, I was initially
thinking how a peer with a multiprotocol session would know which address
family the looking glass is for, if there are multiple. My reasoning here
was that the looking glass itself would allow for selecting the AFI through
its interface, so it does not need to be advertised in band. Now you
mentioned it though, it seems that actually using the proper AFI set (e.g.
IPv4 or IPv6 etc) and then using a new SAFI to carry the looking glass
address would be an elegant design too.


> As you know the alternative to exchange this type of information would be
> via defining a new BGP Message (just like we ddi this in the past in case
> of BGP Operational Message). But here perhaps you want to propagate this
> beyond single ASN peer so new SAFI may work better.
>

Yeah I took a look at the operational message and it is one of the things I
took inspiration from, to make the mechanism extensible to carry other
administrative payloads in the future. I think going down the path
attribute approach would be easier to implement since it reuses the
existing semantics of the multiprotocol path attributes. For example, I can
imagine looking glass reachability can use MP_REACH and then when the
looking glass is no longer reachable it can be withdrawn with MP_UNREACH,
without needing to add that complexity into the looking glass message
itself.


>
> I however have one major concern on how are Looking Glasses going to help
> to address your original problem ie. to check if my prefix was announced
> and accepted by peering AS.
>
> Note that ASBRs normally send only best paths. If best path was learned
> over IBGP (tie breaker was Local Pref or MED) ASBR may receive and accept
> your route, but that route would not be advertised to LGs.
>

Interesting, I hadn't considered this type of architecture where there is a
centralized looking glass that is fed from the border routers. From what I
had seen on some looking glasses like https://lg.he.net/ or
https://lg.twelve99.net/ they let you choose which PoP to perform the
lookup in. From that I had assumed that the LG URL provided in the
administrative message would be customized to be a looking glass for the
ASBR that the BGP session is with. Maybe one way to deal with this would be
to use the query parameter router field in RFC8522 section 2.2:
https://datatracker.ietf.org/doc/html/rfc8522#section-2.2, and pre-populate
that URL with the query parameter in the admin message.

When I do a BGP route lookup on for example the HE looking glass, I get
some output like

1 Prefix: 193.36.104.0/24, Rx path-id:0x00000000, Tx path-id:0x00000000,
rank:0x00000001, Status: BI, Age: 15d1h2m45s
NEXT_HOP: 91.206.52.201, Metric: 17, Learned from Peer: 216.218.252.82
(6939)
LOCAL_PREF: 100, MED: 0, ORIGIN: igp, Weight: 0, GROUP_BEST: 1
AS_PATH: 210036
COMMUNITIES: 6939:7215 6939:8756 6939:9002
2 Prefix: 193.36.104.0/24, Rx path-id:0x00000000, Tx path-id:0x000a0001,
rank:0x00000002, Status: I, Age: 15d1h2m45s
NEXT_HOP: 37.49.238.32, Metric: 127, Learned from Peer: 216.218.252.184
(6939)
LOCAL_PREF: 100, MED: 0, ORIGIN: igp, Weight: 0, GROUP_BEST: 0
AS_PATH: 210036
COMMUNITIES: 6939:7055 6939:8250 6939:9002
... truncated ... full version: https://pastebin.com/SxukdS4L

Which shows all the accepted routes, and then the announcing router can
look through that for it's own address as the nexthop? I agree though that
rfc8522 does not specify this and maybe a more structured output format
would be desirable to allow for parsing.


> The natural solution here is use of best external and add-paths to make
> sure LGs really get all received and accepted paths for a given net - but I
> am not sure how common that is deployed today on sessions between ASBRs and
> LGs. Last time I checked LGs get peering with RRs and get RR paths. Even
> with add-path there and no best external your original issue would not be
> solved.
>

I think using the router query parameter / nexthop lookup would solve this,
but I may have misunderstood the setup / problem, so please do correct me
if this would not solve the issue.


>
> So I would recommend that we review this point before focusing more on LG
> auto discovery mechanics. Btw this draft if progressing should be IMO
> discussed in IDR and changed to Standards Track. But GROW is an excellent
> forum to first make sure if the entire idea proposed here is sound enough.
>

Sounds good, I'm learning a lot through discussing the proposal here and
I'm thankful for the first rounds of feedback to get the document into a
better state before discussing it more broadly. I'll defer to the chairs to
determine if / when this should be changed to standards track, as I think
there are some prerequisites for that?

Thanks,
Rayhaan


>
> Best,
> R.
>
>
>
>
>
>
>
>
> On Sun, Jul 25, 2021 at 9:24 PM Rayhaan Jaufeerally (IETF) <
> [e-mail]> wrote:
>
>> Dear GROW WG,
>>
>> Following the feedback previously on my looking glass draft proposal,
>> I've updated the looking glass draft (
>> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/), to move
>> away from a capability mechanism to a new AFI which uses the MP_REACH and
>> MP_UNREACH messages in the BGP multiprotocol specification (
>> https://datatracker.ietf.org/doc/html/rfc4760) to carry an
>> administrative message. This administrative message is then defined to have
>> a payload type that carries a URL for the looking glass (LG), as well as
>> the ASN that is operating the LG.
>>
>> The advantage of this approach is that it allows for propagating the LGs
>> of upstream peers so leaf ASes can check prefix reachability in peers not
>> directly connected.
>>
>> Looking at the development of the idea, I think it could make sense to
>> split the document into one for the administrative message and AFI, and
>> another for the looking glass message type within that.
>>
>> I will present an overview of the draft and the expected use cases during
>> the upcoming GROW meeting at IETF111, so feel free to either comment here
>> or ask a question in the session if you have any feedback.
>>
>> Thanks,
>> Rayhaan
>>
>>
>>
>> On Tue, Apr 27, 2021 at 1:29 PM Job Snijders <[e-mail]> wrote:
>>
>>> On Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF)
>>> wrote:
>>> > > Consistent API that serves RIB data
>>> >
>>> > Initially I tried to avoid defining the exact API of the looking glass
>>> by
>>> > pointing to https://tools.ietf.org/html/rfc8522, but unfortunately it
>>> does
>>> > not strictly define the response format instead leaving it up to the
>>> > implementation what to return to queries, which IMO is not very useful
>>> for
>>> > automation.
>>> >
>>> > As y'all have pointed out there is a wealth of implementations out
>>> there
>>> > that have tried to address this (and adding some others I've found):
>>> >
>>> >    - Paolo's pmacct looking glass document:
>>> >
>>> https://github.com/pmacct/pmacct/blob/master/docs/LOOKING_GLASS_FORMAT,
>>> >    - Birdseye https://github.com/inex/birdseye
>>> >    - CAIDA looking glass API
>>> >    https://www.caida.org/tools/utilities/looking-glass-api/
>>> >    - DE-CIX: https://www.de-cix.net/en/resources/looking-glass (which
>>> is
>>> >    using https://github.com/alice-lg/alice-lg)
>>> >    - RIPEStat's API, e.g.
>>> >
>>> https://stat.ripe.net/data/looking-glass/data.json?preferred_version=2.1&resource=2a0d:d740::/48
>>>
>>> Just to add to the list: there is yet another API-based Looking Glass
>>> targetting OpenBGPD: https://github.com/cjeker/bgplgd
>>>
>>> A demo is here:
>>>     http://165.22.27.105/bgplgd/summary
>>>     http://165.22.27.105/bgplgd/rib?as=22512
>>>
>>> Kind regards,
>>>
>>> Job
>>>
>> _______________________________________________
>> GROW mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/grow
>>
>