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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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:
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 n
: 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 R
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
(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
> 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
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
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 <
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
; 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
> *S
, 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
+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)
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
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
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
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
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
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
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
+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
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
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
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
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
> 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
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
40 matches
Mail list logo
