Input for Draft Document on Terminology in BGP/Global Routing

Mailman List Mirror (Read Only)
1

Moin,

I have been working on a document listing terms & abbreviations used in
the context of BGP/Global Routing Operations (leftovers from the cut-
down of the attempts to update documents in BCP194):

I just setup a web-form to collect further terms & abbreviations people
would like to also see in the document; If you have a minute, it would
be appreciated if you could scroll the document and drop a few lines on
what you would like to see added

https://files.measurement.network/apps/forms/s/CMXjrtCPD8QyG6CAWmSLmg4y

(In case anyone is concerned: Responses will only be used to update the
I-D, and not for any form of research. ;-))

With best regards,
Tobias

P.S.: No, I will not open the box of defining what a Tier-1 is; That
definition can stay in RFC7454, and I believe it is better not to touch
that topic. :wink:

2

This seems like a total misuse of the RFC framework / process and more a grab at publicity, but I'll play along...bogon. You should include the term "bogon". Someday when I'm done keeping actual production networks alive, I may wade into the morass of IETF & IEEE and work on trimming the fat...or maybe just retire. It's a tough call.

3

Not saying I agree or disagree, what is the definition of appropriate
use and how does this particular draft violate in comparison to the
existing corpus?

Someone might want to argue RFCs are for technical implementations,
but there are increasingly many RFCs with no relevance to technical
implementations at all, which are significantly more soft ball than
the work proposed here.

4

Moin,

(Repost to list as my original reply had a wrong From:)

> This seems like a total misuse of the RFC framework / process and
> more a grab at publicity, but I'll play along...bogon. You should
> include the term "bogon". Someday when I'm done keeping actual
> production networks alive, I may wade into the morass of IETF &
> IEEE and work on trimming the fat...or maybe just retire. It's a
> tough call.

Not saying I agree or disagree, what is the definition of appropriate
use and how does this particular draft violate in comparison to the
existing corpus?

Someone might want to argue RFCs are for technical implementations,
but there are increasingly many RFCs with no relevance to technical
implementations at all, which are significantly more soft ball than
the work proposed here.

There are a couple of operations focused WGs (DNSOP, GROW) that indeed
produce mostly operational documents; And, i mean, operational guidance
is at least as old as RFC1032 (being the first one springing to my
mind; Likely older ones exist, but I don't have them at the top of my
head.).

The purpose of this document is mostly just summarizing the terms
currently used, as the ambiguity of terms makes documents sometimes a
bit difficult:

The peer [BGP neighbor] to which our router peers [has established a
session] so we can peer [process of having a peering relationship] with
our peer [AS relationship] has been depeered [removal of BGP sessions].

It is not meant to be authoritative, i.e., unlike RFC8499 for DNS, to
ensure that it has some chance of actually making progress without
having to order dedicated truckloads of planks for the new bikeshed to
build (yes, i know, the shed should be made of concrete instead of
wood; But that is how i'd build it).

With best regards,
Tobias

5

Reading through that, there are some definitions I think could be done better.

In section 4.2 you have:
Downstream:
In a direct relationship between two ASes the one receiving upstream from the other. (See: [RFC9234], also known as the customer in a customer-provider relationship.)
Upstream:
In a direct relationship between two ASes the one providing upstream to the other. (See: [RFC9234], also known as the provider in a customer-provider relationship.)
Providing Transit:
Forwarding packets destined for addresses in an advertised prefix, while advertising a full BGP table or default route to the neighbor.
Providing Upstream:
See: Providing Transit

Especially with the definition for “Upstream”, it took me reading the whole of the section to understand that you don’t actually have a circular definition there. If you change the definitions in the “Downstream” and “Upstream” sections to refer to providing or receiving “transit” instead of “upstream” I feel that it would read more clearly as well as pointing to a term has its own definition without pointing to another term.