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
>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 



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

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

Gyan Mishra

Network Solutions Architect

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

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

Hi Robert,

On Sun, Apr 25, 2021 at 3:46 PM Robert Raszuk  wrote:

> Hi Rayhaan,
>
> Two follow up comments:
>
> >  In the bgp.io case it would depend on .io being available
>
> Is this a concern ? My company's domain ntti3.io is using .io TLD :)
>

I don't think it's a concern for one entity, but when coming up with a
proposal to be used across the internet by many parties, I think it's a
concern since switching the domain at a later point in time would incur
some overhead for everyone involved and that's something I would be
interested in minimizing.


>
> >  - Seems to have never progressed past the initial -00 draft and it is a
> much larger effort to revive that
>
> What I meant is not to force implementation of the entire
> draft draft-ietf-idr-operational-message-00.
>
> Just take the draft and make all current messages optional and define
> yours. So willing implementation can add new AFI/SAFI and just your new LG
> Message. Done.
>

Ah right I see, seems like there might be an impedence mismatch to define a
new BGP message type in a document focusing on propagating looking glass
addresses, but I guess that would flip the document around to having the
main focus being the operational message that just happens to define the
looking glass element in it.


> Reason being that as this is really an operational message it fits there
> nicely. "Burden" to implement everything (all or nothing) does not really
> need to be the case. And while in waiting for implementations state this is
> already IDR WG document too :)
>

Makes sense, one thing which I'm still wondering is if it makes more sense
to use a new BGP message type or to go with the aforementioned new address
family which I presume would use the multiprotocol path attribute to carry
the operational payload. The multitude of uses the operational message type
would have though could make a case for introducing it at the top level
though.

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.

Cheers,
Rayhaan


> Cheers,
> Robert.
>
>
>
>
> On Sun, Apr 25, 2021 at 2:59 PM Rayhaan Jaufeerally (IETF) <
> i...@rayhaan.ch> wrote:
>
>> Thanks Jakob and Robert for the insights,
>>
>> > Not using BGP Capability to do it
>>
>> That's a great point and does raise some fundamental questions on how
>> this information will be propagated, I had limited my initial proposal to
>> only considering propagating this information to direct peers since that
>> was a good starting point, and would answer the question of "Has this
>> prefix been accepted by my peer" in the context of turning up a new link.
>> However, now that you mention it I can also see the benefits of checking
>> specific networks for reachability, e.g. if the prefix has been accepted by
>> Tier 1 networks for instance (although in that case it could be argued that
>> an in-band mechanism is not necessary).
>>
>> > Changes cannot be signaled without restarting the session
>>
>> Yup that totally makes sense for not using a capability, and especially
>> if this is going to be used to propagate looking glass information more
>> than one hop away, some other mechanisms should be used,
>>
>> There are a bunch of ideas to consider here so I thought it'd be easier
>> to make a list:
>>
>>- New address family
>>   - + Innovative solution to propagate this information,
>>   - + I can see the case for making something more generic if we go
>>   down this path, since there can be other useful information to 
>> propagate in
>>   addition to the LG URL, specifically things which the Operational 
>> message
>>   type wanted to achieve, but putting it into this AF instead of a new 
>> BGP
>>   message
>>   - Well known URL / .lookingglass / subdomain of bgp.io
>>   - + Easy to set up / could be something like peeringdb (which
>>   already does have looking glass URL, but that's not API standardized 
>> in any
>>   way and is for human debugging)
>>   - -  Hands control / failure domain of this mechanism to a third
>>   party.
>>  - In the bgp.io case it would depend on .io being available and
>>  AS operators registering with whatever mechanism for announcing the 
>> URL of
>>  the looking glass
>>  - In the .lookingglass TLD option, the TLD needs to be applied
>>  for and the ICANN TLD fees etc, then there needs to be a registrar 
>> 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
>>   

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]

Hi Rayhaan,

Two follow up comments:

>  In the bgp.io case it would depend on .io being available

Is this a concern ? My company's domain ntti3.io is using .io TLD :)

>  - Seems to have never progressed past the initial -00 draft and it is a
much larger effort to revive that

What I meant is not to force implementation of the entire
draft draft-ietf-idr-operational-message-00.

Just take the draft and make all current messages optional and define
yours. So willing implementation can add new AFI/SAFI and just your new LG
Message. Done.

Reason being that as this is really an operational message it fits there
nicely. "Burden" to implement everything (all or nothing) does not really
need to be the case. And while in waiting for implementations state this is
already IDR WG document too :)

Cheers,
Robert.




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

> Thanks Jakob and Robert for the insights,
>
> > Not using BGP Capability to do it
>
> That's a great point and does raise some fundamental questions on how this
> information will be propagated, I had limited my initial proposal to only
> considering propagating this information to direct peers since that was a
> good starting point, and would answer the question of "Has this prefix been
> accepted by my peer" in the context of turning up a new link. However, now
> that you mention it I can also see the benefits of checking specific
> networks for reachability, e.g. if the prefix has been accepted by Tier 1
> networks for instance (although in that case it could be argued that an
> in-band mechanism is not necessary).
>
> > Changes cannot be signaled without restarting the session
>
> Yup that totally makes sense for not using a capability, and especially if
> this is going to be used to propagate looking glass information more than
> one hop away, some other mechanisms should be used,
>
> There are a bunch of ideas to consider here so I thought it'd be easier to
> make a list:
>
>- New address family
>   - + Innovative solution to propagate this information,
>   - + I can see the case for making something more generic if we go
>   down this path, since there can be other useful information to 
> propagate in
>   addition to the LG URL, specifically things which the Operational 
> message
>   type wanted to achieve, but putting it into this AF instead of a new BGP
>   message
>   - Well known URL / .lookingglass / subdomain of bgp.io
>   - + Easy to set up / could be something like peeringdb (which
>   already does have looking glass URL, but that's not API standardized in 
> any
>   way and is for human debugging)
>   - -  Hands control / failure domain of this mechanism to a third
>   party.
>  - In the bgp.io case it would depend on .io being available and
>  AS operators registering with whatever mechanism for announcing the 
> URL of
>  the looking glass
>  - In the .lookingglass TLD option, the TLD needs to be applied
>  for and the ICANN TLD fees etc, then there needs to be a registrar 
> 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 

Re: [GROW] BGP Looking Glass Capability

[Rayhaan Jaufeerally (IETF)]

Thanks Jakob and Robert for the insights,

> Not using BGP Capability to do it

That's a great point and does raise some fundamental questions on how this
information will be propagated, I had limited my initial proposal to only
considering propagating this information to direct peers since that was a
good starting point, and would answer the question of "Has this prefix been
accepted by my peer" in the context of turning up a new link. However, now
that you mention it I can also see the benefits of checking specific
networks for reachability, e.g. if the prefix has been accepted by Tier 1
networks for instance (although in that case it could be argued that an
in-band mechanism is not necessary).

> Changes cannot be signaled without restarting the session

Yup that totally makes sense for not using a capability, and especially if
this is going to be used to propagate looking glass information more than
one hop away, some other mechanisms should be used,

There are a bunch of ideas to consider here so I thought it'd be easier to
make a list:

   - New address family
  - + Innovative solution to propagate this information,
  - + I can see the case for making something more generic if we go
  down this path, since there can be other useful information to
propagate in
  addition to the LG URL, specifically things which the Operational message
  type wanted to achieve, but putting it into this AF instead of a new BGP
  message
  - Well known URL / .lookingglass / subdomain of bgp.io
  - + Easy to set up / could be something like peeringdb (which already
  does have looking glass URL, but that's not API standardized in
any way and
  is for human debugging)
  - -  Hands control / failure domain of this mechanism to a third
  party.
 - In the bgp.io case it would depend on .io being available and AS
 operators registering with whatever mechanism for announcing
the URL of the
 looking glass
 - In the .lookingglass TLD option, the TLD needs to be applied for
 and the ICANN TLD fees etc, then there needs to be a
registrar 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:
> 

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