Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

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) 
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) 
>> 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

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

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) 
> 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

Re: [GROW] BGP Looking Glass Capability

[Thomas Mangin]

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) 
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

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Hi Nick,

The overall goal I'm trying to achieve is to know in an automated fashion
whether the routes being announced from a BGP speaker are being accepted by
peers (and their upstreams where applicable).

Thanks,
Rayhaan

On Tue, Jul 27, 2021, 13:03 Nick Hilliard  wrote:

> Rayhaan Jaufeerally (IETF) wrote on 26/07/2021 18:54:
> > Yes that is what I was trying to do with the router query parameter from
> > RFC8522, and once you know which "router" or PoP to query, my assumption
> > would be that if you peer with any ASBR in that PoP then the looking
> > glass should, if the route was accepted, display it when you look the
> > prefix up?
>
> Hi Rayhaan,
>
> Can you provide a clear explanation of what your overall end goal is here?
>
> Nick
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Nick Hilliard]

Rayhaan Jaufeerally (IETF) wrote on 26/07/2021 18:54:
Yes that is what I was trying to do with the router query parameter from 
RFC8522, and once you know which "router" or PoP to query, my assumption 
would be that if you peer with any ASBR in that PoP then the looking 
glass should, if the route was accepted, display it when you look the 
prefix up?


Hi Rayhaan,

Can you provide a clear explanation of what your overall end goal is here?

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Hi,


On Mon, Jul 26, 2021 at 2:49 PM Robert Raszuk  wrote:

> Hi,
>
> I think Nick meant API to query the local BGP RIB of the router itself not
> the LG.
>

I was under the impression that the LG would provide a view of the RIB of
the ASBR?


>
> For DNS domain there are couple of options. For example we could
> register new root domain .bgp which would be reserved to be allocated
> automatically with well known names like ASN.bgp by RIR which allocates
> ASN.
>
> Then lg.[ASN].bgp would be what you are looking for.
>

That would be a neat solution and I can imagine other uses for such a
domain name, e.g. RPKI certificate hosting, peering policy etc, so it might
be worth looking into as a broader effort. It still requires coordination
with some kind of authoritative DNS service though so it would not be
standalone from the point of the BGP speakers.


>
>
> > The in-band approach solves this by having the BGP speaker forward the
> LG address of peers that announcements have been forwarded to.
>
> Sorry but I assume you know your peers and their ASNs. So not sure I get
> the benefit of same session (not even guaranteed) autodiscovery. Besides in
> looking glass you normally do not have access to specific ASBR's RIB ...
> maybe POP. If so I assume you know which POP to check.
>

Yes you know the direct peers that you have established sessions with, but
whom they decide to forward announcements to may also be of interest.
Consider a leaf AS which buys IP transit from a local ISP, which then has a
mix of 3 tier-1 upstreams. I think it would be useful for the leaf AS to
automatically discover what tier-1 ASes the announcement gets forwarded to,
so that they can check for reachability in them to make sure they are not
filtered out due to having a misisng IRR or bad RPKI config, or whatever
other policy reason.


>
> Do you rather mean that you want to autodiscover your peer's POP and in
> the case of LG per POP you want to get specific Looking Glass server
> address serving that POP ?
>

Yes that is what I was trying to do with the router query parameter from
RFC8522, and once you know which "router" or PoP to query, my assumption
would be that if you peer with any ASBR in that PoP then the looking glass
should, if the route was accepted, display it when you look the prefix up?


>
> Keep in mind that accepting the announcement does not mean it is going to
> be used in forwarding or propagated by BGP upstream. If you are looking for
> the assurance of the latter I would rather use data plane tools with wisely
> chosen src address of say enhanced trace to make sure what you announced is
> installed and used by the peer.
>

Sure of course there's no guarantee that it will be used in the FIB, but my
rationale was, if it's not in the RIB then it's for sure not in the FIB, so
let's check that the desired routes are in the RIB by looking through the
LG.

Cheers,
Rayhaan


>
> Cheers,
> R,
>
>
> On Mon, Jul 26, 2021 at 2:03 PM Rayhaan Jaufeerally (IETF) <
> i...@rayhaan.ch> wrote:
>
>> I totally agree that an API for programmatically querying the LG would be
>> the next step on the road to implementing the overall goal, but I picked
>> this smaller task of discovering the looking glass first, before designing
>> the broader ecosystem.
>>
>> I thought of the following concerns when evaluating the DNS approach (I
>> think it's been discussed earlier too):
>>
>>- You need to have some DNS zone for the AS, and there's no guarantee
>>that AS 65534 can get a domain like as65534.net
>>- You could use something like reverse DNS zones in in-addr.arpa for
>>example to map the IP of the ASBR to an SRV record or something, but
>>   - That requires a coordination between the DNS zone management and
>>   looking glass / BGP operations, and in larger organizations it might be
>>   more work to set that up which I fear will impede adoption,
>>- In the DNS approach you don't know to which peers a route
>>announcement was forwarded to, so how would you then know which ASes to
>>look up the looking glass for? The in-band approach solves this by having
>>the BGP speaker forward the LG address of peers that announcements have
>>been forwarded to. That way the downstream AS can discover which upstream
>>peers exist and query the LG and probe reachability that way,
>>
>> I think the last point is the most concerning for me, the fact that it's
>> all self contained is more of a nice to have, but I think not knowing
>> programatically what peers announcements are being forwarded to would limit
>> the usefulness of the DNS approach, I'm happy to be convinced otherwise
>> though :).
>>
>> Cheers,
>> Rayhaan
>>
>> On Mon, Jul 26, 2021 at 11:31 AM Nick Hilliard  wrote:
>>
>>> Robert Raszuk wrote on 26/07/2021 00:04:
>>> > I am still not sure what is wrong using DNS for this type of
>>> discovery.
>>> > If I were to tackle this problem I would start with DNS.
>>>
>>> ^^^ this, but I'm not 

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Hi,

I think Nick meant API to query the local BGP RIB of the router itself not
the LG.

For DNS domain there are couple of options. For example we could
register new root domain .bgp which would be reserved to be allocated
automatically with well known names like ASN.bgp by RIR which allocates
ASN.

Then lg.[ASN].bgp would be what you are looking for.


> The in-band approach solves this by having the BGP speaker forward the LG
address of peers that announcements have been forwarded to.

Sorry but I assume you know your peers and their ASNs. So not sure I get
the benefit of same session (not even guaranteed) autodiscovery. Besides in
looking glass you normally do not have access to specific ASBR's RIB ...
maybe POP. If so I assume you know which POP to check.

Do you rather mean that you want to autodiscover your peer's POP and in the
case of LG per POP you want to get specific Looking Glass server address
serving that POP ?

Keep in mind that accepting the announcement does not mean it is going to
be used in forwarding or propagated by BGP upstream. If you are looking for
the assurance of the latter I would rather use data plane tools with wisely
chosen src address of say enhanced trace to make sure what you announced is
installed and used by the peer.

Cheers,
R,


On Mon, Jul 26, 2021 at 2:03 PM Rayhaan Jaufeerally (IETF) 
wrote:

> I totally agree that an API for programmatically querying the LG would be
> the next step on the road to implementing the overall goal, but I picked
> this smaller task of discovering the looking glass first, before designing
> the broader ecosystem.
>
> I thought of the following concerns when evaluating the DNS approach (I
> think it's been discussed earlier too):
>
>- You need to have some DNS zone for the AS, and there's no guarantee
>that AS 65534 can get a domain like as65534.net
>- You could use something like reverse DNS zones in in-addr.arpa for
>example to map the IP of the ASBR to an SRV record or something, but
>   - That requires a coordination between the DNS zone management and
>   looking glass / BGP operations, and in larger organizations it might be
>   more work to set that up which I fear will impede adoption,
>- In the DNS approach you don't know to which peers a route
>announcement was forwarded to, so how would you then know which ASes to
>look up the looking glass for? The in-band approach solves this by having
>the BGP speaker forward the LG address of peers that announcements have
>been forwarded to. That way the downstream AS can discover which upstream
>peers exist and query the LG and probe reachability that way,
>
> I think the last point is the most concerning for me, the fact that it's
> all self contained is more of a nice to have, but I think not knowing
> programatically what peers announcements are being forwarded to would limit
> the usefulness of the DNS approach, I'm happy to be convinced otherwise
> though :).
>
> Cheers,
> Rayhaan
>
> On Mon, Jul 26, 2021 at 11:31 AM Nick Hilliard  wrote:
>
>> Robert Raszuk wrote on 26/07/2021 00:04:
>> > I am still not sure what is wrong using DNS for this type of discovery.
>> > If I were to tackle this problem I would start with DNS.
>>
>> ^^^ this, but I'm not convinced that dynamic discovery of LG endpoints
>> is a pressing issue to start with.  What's more important is a
>> functional API which can retrieve the rib info dynamically (netconf or
>> otherwise).
>>
>> Nick
>>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

I totally agree that an API for programmatically querying the LG would be
the next step on the road to implementing the overall goal, but I picked
this smaller task of discovering the looking glass first, before designing
the broader ecosystem.

I thought of the following concerns when evaluating the DNS approach (I
think it's been discussed earlier too):

   - You need to have some DNS zone for the AS, and there's no guarantee
   that AS 65534 can get a domain like as65534.net
   - You could use something like reverse DNS zones in in-addr.arpa for
   example to map the IP of the ASBR to an SRV record or something, but
  - That requires a coordination between the DNS zone management and
  looking glass / BGP operations, and in larger organizations it might be
  more work to set that up which I fear will impede adoption,
   - In the DNS approach you don't know to which peers a route announcement
   was forwarded to, so how would you then know which ASes to look up the
   looking glass for? The in-band approach solves this by having the BGP
   speaker forward the LG address of peers that announcements have been
   forwarded to. That way the downstream AS can discover which upstream peers
   exist and query the LG and probe reachability that way,

I think the last point is the most concerning for me, the fact that it's
all self contained is more of a nice to have, but I think not knowing
programatically what peers announcements are being forwarded to would limit
the usefulness of the DNS approach, I'm happy to be convinced otherwise
though :).

Cheers,
Rayhaan

On Mon, Jul 26, 2021 at 11:31 AM Nick Hilliard  wrote:

> Robert Raszuk wrote on 26/07/2021 00:04:
> > I am still not sure what is wrong using DNS for this type of discovery.
> > If I were to tackle this problem I would start with DNS.
>
> ^^^ this, but I'm not convinced that dynamic discovery of LG endpoints
> is a pressing issue to start with.  What's more important is a
> functional API which can retrieve the rib info dynamically (netconf or
> otherwise).
>
> Nick
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Nick Hilliard]

Robert Raszuk wrote on 26/07/2021 00:04:
I am still not sure what is wrong using DNS for this type of discovery. 
If I were to tackle this problem I would start with DNS.


^^^ this, but I'm not convinced that dynamic discovery of LG endpoints 
is a pressing issue to start with.  What's more important is a 
functional API which can retrieve the rib info dynamically (netconf or 
otherwise).


Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Hi,

Just few comments:

Ah I just realized that you mention SAFI here, but when writing the draft I
> was thinking about an AFI.
>

To define a new MP_REACH you need both AFI (two octets) + SAFI (1 octet)
RFC 4760 section 2.

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.
>

You mean that address of the same LG would be send over AFI=1/SAFI=LG to
send IPv4 address and AFI=2/SAFI=LG to send given LG's IPv6 address ? Looks
ok if you want to really negotiate two capabilities for that.


>  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.
>

Typically in BGP we try to shield the world from say switch flap given
server is connected to.  Sending host routes all over the place - while
doable - I am not sure will be best for protocol stability.

I am still not sure what is wrong using DNS for this type of discovery. If
I were to tackle this problem I would start with DNS.

Say your draft will define a well known name  ASN-LG (example: 6939-lg) .
Then each AS willing to play the game will just push the current IP
address(es) into such well known DNS record so anyone can get seamlessly to
their looking glasses pool. Done.

And this does not require any extension to BGP :) Moreover such draft can
be worked on and published by GROW WG too.

Interesting, I hadn't considered this type of architecture where there is a
> centralized looking glass that is fed from the border routers.
>

Well I am sure there is a lot of such collectors in the wild. Maybe we also
have as you say just type of jump hosts where under the hood when you query
LG a box get's to production box to get the info live. And even so maybe it
would log into POP's RR not ASBR so the requirement of best external still
applies.

Thx,
R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Thanks for the reply and the great points Robert,

On Sun, Jul 25, 2021 at 10:58 PM Robert Raszuk  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:0x, Tx path-id:0x,
rank:0x0001, 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:0x, Tx path-id:0x000a0001,
rank:0x0002, 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 

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

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.

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.

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.

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.

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.

Best,
R.








On Sun, Jul 25, 2021 at 9:24 PM Rayhaan Jaufeerally (IETF) 
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  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=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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

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  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=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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Job Snijders]

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=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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Hi Jakob,

It's a good point that a looking glass is different from knowing if a
specific route was accepted or not, and for this particular use case of
knowing if a route was not accepted ORF could achieve that.

I'm not sure how exactly ORF is used by implementations, is it
automatically generated by the router based on what the filtering rules
are, or configured a different way? I think the real value would be in
having something which has little overhead for the person configuring it as
possible, because if an operator needs to generate the ORF to send to peers
there's the risk it could diverge from the policy which is used to filter
incoming routes, or some runtime check such as RPKI validity failed which
caused the route to be rejected.

Additionally, I've previously had an issue where the peer accepted a route,
but the upstream of a peer rejected it, so it would be useful to be able to
check the upstreams of peers acceptance of the routes as well.

I can imagine some more complex scenarios where this would be useful too:
for example in an anycast deployment where routes from particular PoPs are
tagged with a community value, it could be useful to check that a
particular route is visible at a particular upstream provider for instance.

Thanks,
Rayhaan

On Tue, Apr 27, 2021 at 2:00 AM Jakob Heitz (jheitz) 
wrote:

> Rayhaan wanted to know if the peer accepted his route.
> A looking glass is a different thing in many ways.
>
> Several years ago Ignas pointed out that you can use this
> information to know whether to install a backup on your
> side for the route. Backup routes in the forwarding hardware
> are expensive, so it would be good to know if your peer
> is using your route before installing a backup for it.
>
> BGP has a peer-to-peer only signaling mechanism: ORF.
> Can we invent an ORF for it?
>
> Rayhaan, please let me know if I'm on or off track
> for your use case.
>
> Regards,
> Jakob.
>
> -Original Message-
> From: GROW  On Behalf Of heasley
> Sent: Monday, April 26, 2021 4:23 PM
> To: Christopher Morrow 
> Cc: grow@ietf.org grow@ietf.org 
> Subject: Re: [GROW] BGP Looking Glass Capability
>
> Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> > (as normal netizen)
> >
> > On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> >
> > > > Place LG info in peeringdb.com & peeringdb's api.
> > >
> > > +1
> > >
> >
> > huh,I had thought this was already actually included in peeringdb?
> > 
> >Looking Glass URL http://route-server.ip.att.net
> > 
>
> afict, its just a string, which does not provide a standard way to
> represent location/geo.  i presume from earlier comments, that something
> more structured is desired.
>
> ___
> 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

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Jakob,

> Several years ago Ignas pointed out that you can use this
> information to know whether to install a backup on your
> side for the route. Backup routes in the forwarding hardware
> are expensive, so it would be good to know if your peer
> is using your route before installing a backup for it.

Let's see if I understand what you wrote 

ASN1 ASN2 or ASN3 etc ...

R1.1  -- R2.1
   |
R1.2  -- R2.2 or R3.1 etc ..

Assume your prefix is 1.1.1.0/24 You are advertising it from R1.x to R2.x
and R3.x

Q1 - This is your prefix (or transit one) so are you describing the case
where different IBGP next hop is programmed (or not) into local FIB of R1.1
as backup ?

Q2 - R2.1's policy can change N times a day (hint PFR) ... how often are
you going to probe R2.1 if your route is installed ?

Q3 - Exposing someone's RIB or even bRIB may be indirectly revealing their
policy. Last time I checked some operators were rather careful not to
publish their eBGP policies to their peers.

Thx,
R.























On Tue, Apr 27, 2021 at 2:01 AM Jakob Heitz (jheitz)  wrote:

> Rayhaan wanted to know if the peer accepted his route.
> A looking glass is a different thing in many ways.
>
> Several years ago Ignas pointed out that you can use this
> information to know whether to install a backup on your
> side for the route. Backup routes in the forwarding hardware
> are expensive, so it would be good to know if your peer
> is using your route before installing a backup for it.
>
> BGP has a peer-to-peer only signaling mechanism: ORF.
> Can we invent an ORF for it?
>
> Rayhaan, please let me know if I'm on or off track
> for your use case.
>
> Regards,
> Jakob.
>
> -Original Message-
> From: GROW  On Behalf Of heasley
> Sent: Monday, April 26, 2021 4:23 PM
> To: Christopher Morrow 
> Cc: grow@ietf.org grow@ietf.org 
> Subject: Re: [GROW] BGP Looking Glass Capability
>
> Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> > (as normal netizen)
> >
> > On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> >
> > > > Place LG info in peeringdb.com & peeringdb's api.
> > >
> > > +1
> > >
> >
> > huh,I had thought this was already actually included in peeringdb?
> > 
> >Looking Glass URL http://route-server.ip.att.net
> > 
>
> afict, its just a string, which does not provide a standard way to
> represent location/geo.  i presume from earlier comments, that something
> more structured is desired.
>
> ___
> 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

Re: [GROW] BGP Looking Glass Capability

[Jakob Heitz (jheitz)]

Rayhaan wanted to know if the peer accepted his route.
A looking glass is a different thing in many ways.

Several years ago Ignas pointed out that you can use this
information to know whether to install a backup on your
side for the route. Backup routes in the forwarding hardware
are expensive, so it would be good to know if your peer
is using your route before installing a backup for it.

BGP has a peer-to-peer only signaling mechanism: ORF.
Can we invent an ORF for it?

Rayhaan, please let me know if I'm on or off track
for your use case.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of heasley
Sent: Monday, April 26, 2021 4:23 PM
To: Christopher Morrow 
Cc: grow@ietf.org grow@ietf.org 
Subject: Re: [GROW] BGP Looking Glass Capability

Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> (as normal netizen)
> 
> On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> 
> > > Place LG info in peeringdb.com & peeringdb's api.
> >
> > +1
> >
> 
> huh,I had thought this was already actually included in peeringdb?
> 
>Looking Glass URL http://route-server.ip.att.net
> 

afict, its just a string, which does not provide a standard way to
represent location/geo.  i presume from earlier comments, that something
more structured is desired.

___
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

Re: [GROW] BGP Looking Glass Capability

[heasley]

Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> (as normal netizen)
> 
> On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> 
> > > Place LG info in peeringdb.com & peeringdb's api.
> >
> > +1
> >
> 
> huh,I had thought this was already actually included in peeringdb?
> 
>Looking Glass URL http://route-server.ip.att.net
> 

afict, its just a string, which does not provide a standard way to
represent location/geo.  i presume from earlier comments, that something
more structured is desired.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Christopher Morrow]

(as normal netizen)

On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:

> > Place LG info in peeringdb.com & peeringdb's api.
>
> +1
>

huh,I had thought this was already actually included in peeringdb?

   Looking Glass URL http://route-server.ip.att.net

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Randy Bush]

> I do not support adding such an interface to routers or dispersing LG
> locations in BGP.

maybe dns?  rpki?  x.400?  :)

> Place LG info in peeringdb.com & peeringdb's api.

+1

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[heasley]

Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF):
> > 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=2a0d:d740::/48
> 
> There's certainly value in going in and actually defining the data
> interchange format, but maybe that's worth doing in a different document to
> the propagation of the LG URL itself?

IMO, if you wish to formalize/define the "output" in rfc8522, do so.  let
the LG API (via http/whatever) retrieve information from the devices via
net/restconf.

I do not support adding such an interface to routers or dispersing LG
locations in BGP.  Place LG info in peeringdb.com & peeringdb's api.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Yes I mentioned this case in one of the subsequent emails - LG can be per
region etc ... You just register not one by many such looking glass server
addresses. Some may be independent .. some may be a pool of servers under
same IP.

Thx

On Mon, Apr 26, 2021 at 5:59 AM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

> Hello, I guess you have already mentioned this, however I have not found
> it yet. Please consider many AS have many different views. That's it.
>
> Alejandro,
>
> On Sun, Apr 25, 2021, 8:03 AM Robert Raszuk  wrote:
>
>>
>> > for example: 23456.lookingglass for AS 23456.
>>
>>
>> I was just about to propose to define a notion of well known URL for
>> looking glass.
>>
>>
>> Let's grab bgp.io domain (it seems available) and allow each domain to
>> submit their IP to well known name mapping. In fact looking glasses may be
>> just one of many such well known tools to help with operational aspects of
>> the Internet.
>>
>>
>> In such cases no signalling would be necessary at all and you can always
>> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io)
>> to see if your routes made it via peer's policy/best path etc ... In case
>> ASN has more then one LG in each region same thing ... you define a few
>> such addresses to indicate each server or LG server pool.
>>
>>
>> Thx,
>> R.
>>
>>
>> PS. However if we want to down the BGP inline signalling for this I
>> recommend we take a look at:
>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems
>> to me like defining new TLV there would be very good fit for what is being
>> proposed here.
>>
>>
>>
>> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> This is a great thing to do, but I would not use a BGP capability to do
>>> it.
>>>
>>> The capability is signaled only in the BGP OPEN message, at the start of
>>> the session.
>>>
>>> Changes cannot be signaled without bouncing the session.
>>>
>>> The BGP capability is only exchanged with neighbors.
>>>
>>> Perhaps we could do it with a new address family or
>>>
>>> standardize the form of the URL, say invent a new top level domain:
>>> .lookingglass
>>>
>>> and then the URL could be the ASN followed by the TLD, for example:
>>>
>>> 23456.lookingglass for AS 23456.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jakob.
>>>
>>>
>>>
>>> *From:* GROW  *On Behalf Of * Rayhaan
>>> Jaufeerally (IETF)
>>> *Sent:* Saturday, April 24, 2021 6:38 AM
>>> *To:* grow@ietf.org
>>> *Subject:* [GROW] BGP Looking Glass Capability
>>>
>>>
>>>
>>> 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

Re: [GROW] BGP Looking Glass Capability

[Alejandro Acosta]

Hello, I guess you have already mentioned this, however I have not found it
yet. Please consider many AS have many different views. That's it.

Alejandro,

On Sun, Apr 25, 2021, 8:03 AM Robert Raszuk  wrote:

>
> > for example: 23456.lookingglass for AS 23456.
>
>
> I was just about to propose to define a notion of well known URL for
> looking glass.
>
>
> Let's grab bgp.io domain (it seems available) and allow each domain to
> submit their IP to well known name mapping. In fact looking glasses may be
> just one of many such well known tools to help with operational aspects of
> the Internet.
>
>
> In such cases no signalling would be necessary at all and you can always
> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io)
> to see if your routes made it via peer's policy/best path etc ... In case
> ASN has more then one LG in each region same thing ... you define a few
> such addresses to indicate each server or LG server pool.
>
>
> Thx,
> R.
>
>
> PS. However if we want to down the BGP inline signalling for this I
> recommend we take a look at:
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems
> to me like defining new TLV there would be very good fit for what is being
> proposed here.
>
>
>
> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz)  40cisco@dmarc.ietf.org> wrote:
>
>> This is a great thing to do, but I would not use a BGP capability to do
>> it.
>>
>> The capability is signaled only in the BGP OPEN message, at the start of
>> the session.
>>
>> Changes cannot be signaled without bouncing the session.
>>
>> The BGP capability is only exchanged with neighbors.
>>
>> Perhaps we could do it with a new address family or
>>
>> standardize the form of the URL, say invent a new top level domain:
>> .lookingglass
>>
>> and then the URL could be the ASN followed by the TLD, for example:
>>
>> 23456.lookingglass for AS 23456.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* GROW  *On Behalf Of * Rayhaan Jaufeerally
>> (IETF)
>> *Sent:* Saturday, April 24, 2021 6:38 AM
>> *To:* grow@ietf.org
>> *Subject:* [GROW] BGP Looking Glass Capability
>>
>>
>>
>> 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

Re: [GROW] BGP Looking Glass Capability

[Gyan Mishra]

Agreed. Sounds good.

Gyan
On Sun, Apr 25, 2021 at 9:52 PM Jakob Heitz (jheitz) 
wrote:

> If we do that, we should secure it with the router certificate
>
> https://tools.ietf.org/html/rfc8209
>
> Then the URL should be secured with DNSSec, or why don't we just put the
>
> IP address in place of the hostname portion of the URL?
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* GROW  *On Behalf Of * Gyan Mishra
> *Sent:* Sunday, April 25, 2021 6:37 PM
> *To:* Rayhaan Jaufeerally (IETF) 
> *Cc:* idr@ietf. org ; grow@ietf.org
> *Subject:* Re: [GROW] BGP Looking Glass Capability
>
>
>
>
>
> +1 on the new AFI idea.  I would support developing the new draft.
>
>
>
> Out of al the ideas proposed I think the new AFI seems to be the best
> method of achieving the BGP looking glass capability and propagation of
> routes.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sun, Apr 25, 2021 at 7:25 PM Rayhaan Jaufeerally (IETF) <
> i...@rayhaan.ch> wrote:
>
> Thanks for the history Robert, I should have read the authors list more
> closely on that draft :)
>
>
>
> From that description it seems that it was more circumstances at the time
> rather than push back on the implementation itself which is good news for
> trying to revive it,
>
>
>
> I'll try and rework the draft to use the operational message and see which
> common parts are useful here, then reply to the list / IDR with the updated
> draft,
>
>
>
> Cheers,
>
> Rayhaan
>
>
>
> On Mon, Apr 26, 2021 at 12:48 AM Robert Raszuk  wrote:
>
> Hi Rayhaan,
>
>
>
> I guess a good starting point would be to reach out to IDR folks / authors
> of the operational message draft and get their input as to why it didn't
> progress further since that would be useful to guide any revival attempts.
>
>
>
> Good idea. As I am co-author of this draft taking the liberty to do it
> right here :)
>
>
>
> A bit of history  - in min 2010 I wrote
> https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.
>
>
>
> Then we spoke about it, trimmed a bit and formed what we considered most
> important operationally into
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>
>
>
> The draft was having good support during the IDR WG adoption and hence it
> became WG doc.
>
>
>
> Since then most of the authors left the vendor world and our influence to
> implement it in significant commercial BGP code bases was no longer
> sufficient. Yet vendors told we will implement it if customers ask for it.
> So we are 9+ years and still I am not sure if anyone cares much about
> switching phone and email channels between NOCs into more programmatic way.
>
>
>
> Yet we do see from time to time a pop request to some form to tell peer
> ascii strings like sms by BGP, pass some well known address, etc ...
>
>
>
> I think this is the fundamental challenge in how we operate peering
> relations. I have seen a lot of good automation happening in the IX world,
> but when trying to establish BGP sessions today it seems still emails, xls,
> word documents style ...
>
>
>
> While it does not need to be all TLVs as listed in the
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft
> but I think operational message is indeed needed.
>
>
>
> Cheers,
> R.
>
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Jakob Heitz (jheitz)]

If we do that, we should secure it with the router certificate
https://tools.ietf.org/html/rfc8209
Then the URL should be secured with DNSSec, or why don't we just put the
IP address in place of the hostname portion of the URL?

Regards,
Jakob.

From: GROW  On Behalf Of Gyan Mishra
Sent: Sunday, April 25, 2021 6:37 PM
To: Rayhaan Jaufeerally (IETF) 
Cc: idr@ietf. org ; grow@ietf.org
Subject: Re: [GROW] BGP Looking Glass Capability


+1 on the new AFI idea.  I would support developing the new draft.

Out of al the ideas proposed I think the new AFI seems to be the best method of 
achieving the BGP looking glass capability and propagation of routes.

Thanks

Gyan

On Sun, Apr 25, 2021 at 7:25 PM Rayhaan Jaufeerally (IETF) 
mailto:i...@rayhaan.ch>> wrote:
Thanks for the history Robert, I should have read the authors list more closely 
on that draft :)

From that description it seems that it was more circumstances at the time 
rather than push back on the implementation itself which is good news for 
trying to revive it,

I'll try and rework the draft to use the operational message and see which 
common parts are useful here, then reply to the list / IDR with the updated 
draft,

Cheers,
Rayhaan

On Mon, Apr 26, 2021 at 12:48 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Rayhaan,

I guess a good starting point would be to reach out to IDR folks / authors of 
the operational message draft and get their input as to why it didn't progress 
further since that would be useful to guide any revival attempts.

Good idea. As I am co-author of this draft taking the liberty to do it right 
here :)

A bit of history  - in min 2010 I wrote 
https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.

Then we spoke about it, trimmed a bit and formed what we considered most 
important operationally into 
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

The draft was having good support during the IDR WG adoption and hence it 
became WG doc.

Since then most of the authors left the vendor world and our influence to 
implement it in significant commercial BGP code bases was no longer sufficient. 
Yet vendors told we will implement it if customers ask for it. So we are 9+ 
years and still I am not sure if anyone cares much about switching phone and 
email channels between NOCs into more programmatic way.

Yet we do see from time to time a pop request to some form to tell peer ascii 
strings like sms by BGP, pass some well known address, etc ...

I think this is the fundamental challenge in how we operate peering relations. 
I have seen a lot of good automation happening in the IX world, but when trying 
to establish BGP sessions today it seems still emails, xls, word documents 
style ...

While it does not need to be all TLVs as listed in the 
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft but I 
think operational message is indeed needed.

Cheers,
R.

___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Gyan Mishra]

+1 on the new AFI idea.  I would support developing the new draft.

Out of al the ideas proposed I think the new AFI seems to be the best
method of achieving the BGP looking glass capability and propagation of
routes.

Thanks

Gyan

On Sun, Apr 25, 2021 at 7:25 PM Rayhaan Jaufeerally (IETF) 
wrote:

> Thanks for the history Robert, I should have read the authors list more
> closely on that draft :)
>
> From that description it seems that it was more circumstances at the time
> rather than push back on the implementation itself which is good news for
> trying to revive it,
>
> I'll try and rework the draft to use the operational message and see which
> common parts are useful here, then reply to the list / IDR with the updated
> draft,
>
> Cheers,
> Rayhaan
>
> On Mon, Apr 26, 2021 at 12:48 AM Robert Raszuk  wrote:
>
>> Hi Rayhaan,
>>
>>
>>> I guess a good starting point would be to reach out to IDR folks /
>>> authors of the operational message draft and get their input as to why it
>>> didn't progress further since that would be useful to guide any revival
>>> attempts.
>>>
>>
>> Good idea. As I am co-author of this draft taking the liberty to do it
>> right here :)
>>
>> A bit of history  - in min 2010 I wrote
>> https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.
>>
>> Then we spoke about it, trimmed a bit and formed what we considered most
>> important operationally into
>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>>
>> The draft was having good support during the IDR WG adoption and hence it
>> became WG doc.
>>
>> Since then most of the authors left the vendor world and our influence to
>> implement it in significant commercial BGP code bases was no longer
>> sufficient. Yet vendors told we will implement it if customers ask for it.
>> So we are 9+ years and still I am not sure if anyone cares much about
>> switching phone and email channels between NOCs into more programmatic way.
>>
>> Yet we do see from time to time a pop request to some form to tell peer
>> ascii strings like sms by BGP, pass some well known address, etc ...
>>
>> I think this is the fundamental challenge in how we operate peering
>> relations. I have seen a lot of good automation happening in the IX world,
>> but when trying to establish BGP sessions today it seems still emails, xls,
>> word documents style ...
>>
>> While it does not need to be all TLVs as listed in the
>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft
>> but I think operational message is indeed needed.
>>
>> Cheers,
>> R.
>>
>> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Thanks for the history Robert, I should have read the authors list more
closely on that draft :)

>From that description it seems that it was more circumstances at the time
rather than push back on the implementation itself which is good news for
trying to revive it,

I'll try and rework the draft to use the operational message and see which
common parts are useful here, then reply to the list / IDR with the updated
draft,

Cheers,
Rayhaan

On Mon, Apr 26, 2021 at 12:48 AM Robert Raszuk  wrote:

> Hi Rayhaan,
>
>
>> I guess a good starting point would be to reach out to IDR folks /
>> authors of the operational message draft and get their input as to why it
>> didn't progress further since that would be useful to guide any revival
>> attempts.
>>
>
> Good idea. As I am co-author of this draft taking the liberty to do it
> right here :)
>
> A bit of history  - in min 2010 I wrote
> https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.
>
> Then we spoke about it, trimmed a bit and formed what we considered most
> important operationally into
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>
> The draft was having good support during the IDR WG adoption and hence it
> became WG doc.
>
> Since then most of the authors left the vendor world and our influence to
> implement it in significant commercial BGP code bases was no longer
> sufficient. Yet vendors told we will implement it if customers ask for it.
> So we are 9+ years and still I am not sure if anyone cares much about
> switching phone and email channels between NOCs into more programmatic way.
>
> Yet we do see from time to time a pop request to some form to tell peer
> ascii strings like sms by BGP, pass some well known address, etc ...
>
> I think this is the fundamental challenge in how we operate peering
> relations. I have seen a lot of good automation happening in the IX world,
> but when trying to establish BGP sessions today it seems still emails, xls,
> word documents style ...
>
> While it does not need to be all TLVs as listed in the
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft
> but I think operational message is indeed needed.
>
> Cheers,
> R.
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Thanks Nick, Paolo and Heasley for your insights,

> 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=2a0d:d740::/48

There's certainly value in going in and actually defining the data
interchange format, but maybe that's worth doing in a different document to
the propagation of the LG URL itself?

> Implementation concerns re access, security, load etc

I think whatever we come up with should take these concerns into
consideration but not constrain the operator, as, if at the end of the day
they'd like to restrict who can query the API that's a totally fine use
case, I can imagine maybe at an internet exchange the API is only available
on the peering LAN to members for instance.

As Paolo mentioned there is a problem to solve between the router or data
source and the LG frontend, I'm not sure what form that would take but I
would propose having that separate from the document describing how to
propagate the LG URL in BGP and the interface of the LG to external users,
since these two things can be implemented independently of each other, is
that reasonable?

Cheers,
Rayhaan

On Sun, Apr 25, 2021 at 6:08 PM heasley  wrote:

> Sun, Apr 25, 2021 at 03:07:29PM +0100, Nick Hilliard:
> > what we need from routers is a consistent API endpoint which serves RIB
> > data, that can be consumed by client apps.
>
> isnt that called net/restconf?
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Hi Rayhaan,


> I guess a good starting point would be to reach out to IDR folks / authors
> of the operational message draft and get their input as to why it didn't
> progress further since that would be useful to guide any revival attempts.
>

Good idea. As I am co-author of this draft taking the liberty to do it
right here :)

A bit of history  - in min 2010 I wrote
https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.

Then we spoke about it, trimmed a bit and formed what we considered most
important operationally into
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

The draft was having good support during the IDR WG adoption and hence it
became WG doc.

Since then most of the authors left the vendor world and our influence to
implement it in significant commercial BGP code bases was no longer
sufficient. Yet vendors told we will implement it if customers ask for it.
So we are 9+ years and still I am not sure if anyone cares much about
switching phone and email channels between NOCs into more programmatic way.

Yet we do see from time to time a pop request to some form to tell peer
ascii strings like sms by BGP, pass some well known address, etc ...

I think this is the fundamental challenge in how we operate peering
relations. I have seen a lot of good automation happening in the IX world,
but when trying to establish BGP sessions today it seems still emails, xls,
word documents style ...

While it does not need to be all TLVs as listed in the
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft but
I think operational message is indeed needed.

Cheers,
R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

rar 
>> which
>>  will process registrations for this TLD
>>  - In both the above cases it seems like manual additional work
>>  is required, which does not yield direct benefit to the AS operator 
>> which
>>  makes me wonder how many operators would take the time to set it up
>>  - New optional path attribute
>>   - + In band, updatable anytime, propagates together with the
>>   prefixes, so upon receiving any prefix from a distant peer, the LG URL 
>> is
>>   also available, which the Operational message or Notification message
>>   extension aren't as amenable to
>>   - - There would need to be some mechanism to limit the propagation
>>   of this attribute to each peer per source AS, because otherwise it 
>> would
>>   waste a lot of space in update messages repeatedly sending the same 
>> URL on
>>   every Update message.
>>   - Operational message type
>>   - + Good design fit for the application here
>>   - - Seems to have never progressed past the initial -00 draft and
>>   it is a much larger effort to revive that
>>   - Adding a new Notification message type
>>   - This is kind of a middle ground between a new AF and a path
>>   attribute
>>   - + Not tied directly to Update messages so can be decoupled from
>>   that logic in implementations
>>
>> Given the above I am most intrigued by the opportunities that adding a
>> new AF would provide, particularly since it could cover some additional use
>> cases, for example I can imagine in the transition to dropping RPKI invalid
>> routes and future routing security mechanisms, could be useful to relay
>> back information that a particular prefix has been dropped for $reason.
>>
>> If the new AF is something that others see promise in I would be happy to
>> start drafting some thoughts on how it could work, and rework this
>> particular draft to use that mechanism.
>>
>> Have a great Sunday,
>> Rayhaan
>>
>> On Sun, Apr 25, 2021 at 2:03 PM Robert Raszuk  wrote:
>>
>>>
>>> > for example: 23456.lookingglass for AS 23456.
>>>
>>>
>>> I was just about to propose to define a notion of well known URL for
>>> looking glass.
>>>
>>>
>>> Let's grab bgp.io domain (it seems available) and allow each domain to
>>> submit their IP to well known name mapping. In fact looking glasses may be
>>> just one of many such well known tools to help with operational aspects of
>>> the Internet.
>>>
>>>
>>> In such cases no signalling would be necessary at all and you can always
>>> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io)
>>> to see if your routes made it via peer's policy/best path etc ... In case
>>> ASN has more then one LG in each region same thing ... you define a few
>>> such addresses to indicate each server or LG server pool.
>>>
>>>
>>> Thx,
>>> R.
>>>
>>>
>>> PS. However if we want to down the BGP inline signalling for this I
>>> recommend we take a look at:
>>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>>> Seems to me like defining new TLV there would be very good fit for what is
>>> being proposed here.
>>>
>>>
>>>
>>> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz) >> 40cisco@dmarc.ietf.org> wrote:
>>>
>>>> This is a great thing to do, but I would not use a BGP capability to do
>>>> it.
>>>>
>>>> The capability is signaled only in the BGP OPEN message, at the start
>>>> of the session.
>>>>
>>>> Changes cannot be signaled without bouncing the session.
>>>>
>>>> The BGP capability is only exchanged with neighbors.
>>>>
>>>> Perhaps we could do it with a new address family or
>>>>
>>>> standardize the form of the URL, say invent a new top level domain:
>>>> .lookingglass
>>>>
>>>> and then the URL could be the ASN followed by the TLD, for example:
>>>>
>>>> 23456.lookingglass for AS 23456.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Jakob.
>>>>
>>>>
>>>>
>>>> *From:* GROW  *On Behalf Of * Rayhaan
>>>> Jaufeerally (IETF)
>>>> *Sent:* Saturday, April 24, 2021 6:38 AM
>>>> *To:* grow@ietf.org
>>>> *Subject:* [GROW] BGP Looking Glass Capability
>>>>
>>>>
>>>>
>>>> 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

Re: [GROW] BGP Looking Glass Capability

[heasley]

Sun, Apr 25, 2021 at 03:07:29PM +0100, Nick Hilliard:
> what we need from routers is a consistent API endpoint which serves RIB 
> data, that can be consumed by client apps.

isnt that called net/restconf?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Nick Hilliard]

Robert Raszuk wrote on 25/04/2021 16:08:

Would you allow to query yr router via such API to anyone in the world ?


That's a policy decision for the operator.  In practice, we expose some 
bits of the API to the public, but other parts are kept private.  For 
example, here's a list of bgp peers from one device:


https://www.inex.ie/ixp/api/v4/lg/rc1-lan1-ipv6/bgp-summary

However, the API RIB export is disallowed except from internal hosts.

The API front-end handler caches all data, but by presenting credentials 
or specific privileges, you can do live queries.  The data freshness is 
noted in the data feed.


The point of this is not the specific data model that's used here 
(because we know it has limitations), but rather suggesting this as an 
generalised approach to how this could be done in a way which was 
flexible enough for general consumption.


Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Paolo Lucente]

Chiming in, surely i'd let a BMP collector be queried through such API; 
why then also not routers? Maybe not from everyone in the world but to 
feed the own LG software / frontend which pretty much every network runs 
in their own specific way. This is IMO the problem to tackle, comms 
between LG backend (router, BMP collector) and LG frontend.


Paolo

On 25/4/21 17:08, Robert Raszuk wrote:

Nick,

Would you allow to query yr router via such API to anyone in the world ? 
I believe this is the real use case Rayhaan is bringing up ...


Thx,
R.


On Sun, Apr 25, 2021 at 4:07 PM Nick Hilliard > wrote:


Rayhaan Jaufeerally (IETF) wrote on 24/04/2021 14:38:
 > 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.

Hi Rayhaan,

what we need from routers is a consistent API endpoint which serves RIB
data, that can be consumed by client apps.

I.e. this should be done using json/xml/etc; it should be available
over
over https; it should be accessible via a REST API; it should be aimed
at having a front-end HTTP cache server to implement rate limiting /
limited access control / etc (i.e. remove as much complication from the
router as possible), and the data model should be flexible enough to
handle a variety of different deployment configurations (e.g. ibgp /
ebgp / l3vpn / l2vpn / evpn / ixp route server / etc).

INEX has done this for BIRD (see github.com/inex/birdseye
, which
provides both the data model and the LG), but the data model is
designed
around constructs which are only available in BIRD, so this isn't
really
portable to other BGP stacks.  But the principle works, and works well.

Nick

___
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

Re: [GROW] BGP Looking Glass Capability

[Paolo Lucente]

+1 to Nick's words.

Basically i have gone through the same in pmacct, although disclaimer, 
a-la super basic: TCP transport, ZeroMQ on top (just for some resilient 
client / server and queueing operations), (hand-crafted) API with two 
operations available (get the list of LG peers, look up IP address / IP 
prefix per peer) and JSON encoding (*).


I pondered on a third operation, "get all the RIB(s)", but never 
executed for load concerns, a bit of security concerns too (although 
only relative to the simple implementation) and because maybe in that 
case one wants RIB dumps (at regular intervals?) so it seemed more a use 
case to get a BMP feed (again, something relative to pmacct architecture 
which features BGP and BMP daemons that do exactly that).


Paolo

(*) https://github.com/pmacct/pmacct/blob/master/docs/LOOKING_GLASS_FORMAT


On 25/4/21 16:07, Nick Hilliard wrote:

Rayhaan Jaufeerally (IETF) wrote on 24/04/2021 14:38:
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.


Hi Rayhaan,

what we need from routers is a consistent API endpoint which serves RIB 
data, that can be consumed by client apps.


I.e. this should be done using json/xml/etc; it should be available over 
over https; it should be accessible via a REST API; it should be aimed 
at having a front-end HTTP cache server to implement rate limiting / 
limited access control / etc (i.e. remove as much complication from the 
router as possible), and the data model should be flexible enough to 
handle a variety of different deployment configurations (e.g. ibgp / 
ebgp / l3vpn / l2vpn / evpn / ixp route server / etc).


INEX has done this for BIRD (see github.com/inex/birdseye, which 
provides both the data model and the LG), but the data model is designed 
around constructs which are only available in BIRD, so this isn't really 
portable to other BGP stacks.  But the principle works, and works well.


Nick

___
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

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Nick,

Would you allow to query yr router via such API to anyone in the world ? I
believe this is the real use case Rayhaan is bringing up ...

Thx,
R.


On Sun, Apr 25, 2021 at 4:07 PM Nick Hilliard  wrote:

> Rayhaan Jaufeerally (IETF) wrote on 24/04/2021 14:38:
> > 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.
>
> Hi Rayhaan,
>
> what we need from routers is a consistent API endpoint which serves RIB
> data, that can be consumed by client apps.
>
> I.e. this should be done using json/xml/etc; it should be available over
> over https; it should be accessible via a REST API; it should be aimed
> at having a front-end HTTP cache server to implement rate limiting /
> limited access control / etc (i.e. remove as much complication from the
> router as possible), and the data model should be flexible enough to
> handle a variety of different deployment configurations (e.g. ibgp /
> ebgp / l3vpn / l2vpn / evpn / ixp route server / etc).
>
> INEX has done this for BIRD (see github.com/inex/birdseye, which
> provides both the data model and the LG), but the data model is designed
> around constructs which are only available in BIRD, so this isn't really
> portable to other BGP stacks.  But the principle works, and works well.
>
> Nick
>
> ___
> 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

Re: [GROW] BGP Looking Glass Capability

[Nick Hilliard]

Rayhaan Jaufeerally (IETF) wrote on 24/04/2021 14:38:
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.


Hi Rayhaan,

what we need from routers is a consistent API endpoint which serves RIB 
data, that can be consumed by client apps.


I.e. this should be done using json/xml/etc; it should be available over 
over https; it should be accessible via a REST API; it should be aimed 
at having a front-end HTTP cache server to implement rate limiting / 
limited access control / etc (i.e. remove as much complication from the 
router as possible), and the data model should be flexible enough to 
handle a variety of different deployment configurations (e.g. ibgp / 
ebgp / l3vpn / l2vpn / evpn / ixp route server / etc).


INEX has done this for BIRD (see github.com/inex/birdseye, which 
provides both the data model and the LG), but the data model is designed 
around constructs which are only available in BIRD, so this isn't really 
portable to other BGP stacks.  But the principle works, and works well.


Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

, could be useful to relay
> back information that a particular prefix has been dropped for $reason.
>
> If the new AF is something that others see promise in I would be happy to
> start drafting some thoughts on how it could work, and rework this
> particular draft to use that mechanism.
>
> Have a great Sunday,
> Rayhaan
>
> On Sun, Apr 25, 2021 at 2:03 PM Robert Raszuk  wrote:
>
>>
>> > for example: 23456.lookingglass for AS 23456.
>>
>>
>> I was just about to propose to define a notion of well known URL for
>> looking glass.
>>
>>
>> Let's grab bgp.io domain (it seems available) and allow each domain to
>> submit their IP to well known name mapping. In fact looking glasses may be
>> just one of many such well known tools to help with operational aspects of
>> the Internet.
>>
>>
>> In such cases no signalling would be necessary at all and you can always
>> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io)
>> to see if your routes made it via peer's policy/best path etc ... In case
>> ASN has more then one LG in each region same thing ... you define a few
>> such addresses to indicate each server or LG server pool.
>>
>>
>> Thx,
>> R.
>>
>>
>> PS. However if we want to down the BGP inline signalling for this I
>> recommend we take a look at:
>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems
>> to me like defining new TLV there would be very good fit for what is being
>> proposed here.
>>
>>
>>
>> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> This is a great thing to do, but I would not use a BGP capability to do
>>> it.
>>>
>>> The capability is signaled only in the BGP OPEN message, at the start of
>>> the session.
>>>
>>> Changes cannot be signaled without bouncing the session.
>>>
>>> The BGP capability is only exchanged with neighbors.
>>>
>>> Perhaps we could do it with a new address family or
>>>
>>> standardize the form of the URL, say invent a new top level domain:
>>> .lookingglass
>>>
>>> and then the URL could be the ASN followed by the TLD, for example:
>>>
>>> 23456.lookingglass for AS 23456.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jakob.
>>>
>>>
>>>
>>> *From:* GROW  *On Behalf Of * Rayhaan
>>> Jaufeerally (IETF)
>>> *Sent:* Saturday, April 24, 2021 6:38 AM
>>> *To:* grow@ietf.org
>>> *Subject:* [GROW] BGP Looking Glass Capability
>>>
>>>
>>>
>>> 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

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

or this I
> recommend we take a look at:
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems
> to me like defining new TLV there would be very good fit for what is being
> proposed here.
>
>
>
> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz)  40cisco@dmarc.ietf.org> wrote:
>
>> This is a great thing to do, but I would not use a BGP capability to do
>> it.
>>
>> The capability is signaled only in the BGP OPEN message, at the start of
>> the session.
>>
>> Changes cannot be signaled without bouncing the session.
>>
>> The BGP capability is only exchanged with neighbors.
>>
>> Perhaps we could do it with a new address family or
>>
>> standardize the form of the URL, say invent a new top level domain:
>> .lookingglass
>>
>> and then the URL could be the ASN followed by the TLD, for example:
>>
>> 23456.lookingglass for AS 23456.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* GROW  *On Behalf Of * Rayhaan Jaufeerally
>> (IETF)
>> *Sent:* Saturday, April 24, 2021 6:38 AM
>> *To:* grow@ietf.org
>> *Subject:* [GROW] BGP Looking Glass Capability
>>
>>
>>
>> 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

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

> for example: 23456.lookingglass for AS 23456.


I was just about to propose to define a notion of well known URL for
looking glass.


Let's grab bgp.io domain (it seems available) and allow each domain to
submit their IP to well known name mapping. In fact looking glasses may be
just one of many such well known tools to help with operational aspects of
the Internet.


In such cases no signalling would be necessary at all and you can always go
to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io) to see
if your routes made it via peer's policy/best path etc ... In case ASN has
more then one LG in each region same thing ... you define a few such
addresses to indicate each server or LG server pool.


Thx,
R.


PS. However if we want to down the BGP inline signalling for this I
recommend we take a look at:
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems to
me like defining new TLV there would be very good fit for what is being
proposed here.



On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz)  wrote:

> This is a great thing to do, but I would not use a BGP capability to do it.
>
> The capability is signaled only in the BGP OPEN message, at the start of
> the session.
>
> Changes cannot be signaled without bouncing the session.
>
> The BGP capability is only exchanged with neighbors.
>
> Perhaps we could do it with a new address family or
>
> standardize the form of the URL, say invent a new top level domain:
> .lookingglass
>
> and then the URL could be the ASN followed by the TLD, for example:
>
> 23456.lookingglass for AS 23456.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* GROW  *On Behalf Of * Rayhaan Jaufeerally
> (IETF)
> *Sent:* Saturday, April 24, 2021 6:38 AM
> *To:* grow@ietf.org
> *Subject:* [GROW] BGP Looking Glass Capability
>
>
>
> 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

Re: [GROW] BGP Looking Glass Capability

[Jakob Heitz (jheitz)]

This is a great thing to do, but I would not use a BGP capability to do it.
The capability is signaled only in the BGP OPEN message, at the start of the 
session.
Changes cannot be signaled without bouncing the session.
The BGP capability is only exchanged with neighbors.
Perhaps we could do it with a new address family or
standardize the form of the URL, say invent a new top level domain: 
.lookingglass
and then the URL could be the ASN followed by the TLD, for example:
23456.lookingglass for AS 23456.

Regards,
Jakob.

From: GROW  On Behalf Of Rayhaan Jaufeerally (IETF)
Sent: Saturday, April 24, 2021 6:38 AM
To: grow@ietf.org
Subject: [GROW] BGP Looking Glass Capability

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] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

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