Input for Draft Document on Terminology in BGP/Global Routing
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): https://datatracker.ietf.org/doc/draft-fiebig-grow-routing-ops-terms/02/ 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. ;-) -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
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.
On Thu, 3 Oct 2024 at 07:04, Jeff Behrns via NANOG <nanog@nanog.org> wrote
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. -- ++ytti
Moin, (Repost to list as my original reply had a wrong From:) On Thu, 2024-10-03 at 07:57 +0300, Saku Ytti wrote:
On Thu, 3 Oct 2024 at 07:04, Jeff Behrns via NANOG <nanog@nanog.org> wrote
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
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. -- Dan On Wed, 2 Oct 2024 at 14:26, Tobias Fiebig < tobias@reads-this-mailinglist.com> wrote:
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): https://datatracker.ietf.org/doc/draft-fiebig-grow-routing-ops-terms/02/
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. ;-)
-- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
participants (4)
-
behrnsjeff＠yahoo.com -
Daniel Ankers -
Saku Ytti -
Tobias Fiebig