[GROW] Re: New Version Notification for draft-fiebig-grow-routing-ops-terms-02.txt

[Alejandro Acosta]

Hello,
  Nice document. Two short comments:
1. I wonder if it worth to mention the difference between advertise and 
announce (which at the end are synonyms, right?)
2. There is a small typo in 4.1: “Part of the Internet where routers do 
not cary default routes”


Alejandro,


On 2/10/24 7:10 AM, Tobias Fiebig wrote:

Moin,
as discussed at 119 and 120, the "terms & abbreviations" part of the
(now shorter) BGP security operations document got split into its own
draft.

I just pushed an update for it with the following changes:

- Some added terms
- Moved to a by-topic structure for terms
- Added a feedback form

To get some more feedback (and terms to add) I setup a small web-form
to submit additional abbreviations/terms you would like to see added
(or existing ones reworded):

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

If you have a couple of minutes and some ideas on what is missing, a
quick line would be appreciated (I will of course also integrate all
comments sent on the list; The form is mostly to enable wider
participation.)

With best regards,
Tobias

On Wed, 2024-10-02 at 03:57 -0700, internet-dra...@ietf.org wrote:

A new version of Internet-Draft draft-fiebig-grow-routing-ops-terms-
02.txt has
been successfully submitted by Tobias Fiebig and posted to the
IETF repository.

Name: draft-fiebig-grow-routing-ops-terms
Revision: 02
Title:    Currently Used Terminology in Global Routing Operations
Date: 2024-10-02
Group:    Individual Submission
Pages:    9
URL:
https://www.ietf.org/archive/id/draft-fiebig-grow-routing-ops-terms-02.txt
Status:
https://datatracker.ietf.org/doc/draft-fiebig-grow-routing-ops-terms/
HTML:
https://www.ietf.org/archive/id/draft-fiebig-grow-routing-ops-terms-02.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-fiebig-grow-routing-ops-terms
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-fiebig-grow-routing-ops-terms-02

Abstract:

    Operating the global routing ecosystem entails a divers set of
    interacting components, while operational practice evolved over
time.
    In that time, terms emerged, disappeared, and sometimes changed
their
    meaning.

    To aid operators and implementers in reading contemporary drafts,
    this document provides an overview of terms and abbreviations used
in
    the global routing operations community.  The document explicitly
    does not serve as an authoritative source of correct terminology,
but
    instead strives to provide an overview of practice.



The IETF Secretariat




___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

[Alejandro Acosta]

Hello All,

  One more comment on this draft.

  On section 5, in "Best Practices" I think one item could be added "Do 
not prepend if you are single home"



That's it.


Alejandro,


On 28/12/23 5:56 PM, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-grow-as-path-prepending-09.txt is now available. It
is a work item of the Global Routing Operations (GROW) WG of the IETF.

Title:   AS Path Prepending
Authors: Mike McBride
 Doug Madory
 Jeff Tantsura
 Robert Raszuk
 Hongwei Li
 Jakob Heitz
 Gyan Mishra
Name:draft-ietf-grow-as-path-prepending-09.txt
Pages:   12
Dates:   2023-12-28

Abstract:

AS Path Prepending provides a tool to manipulate the BGP AS_Path
attribute through prepending multiple entries of an AS.  AS Path
Prepending is used to deprioritize a route or alternate path.  By
prepending the local ASN multiple times, ASs can make advertised AS
paths appear artificially longer.  Excessive AS Path Prepending has
caused routing issues in the Internet.  This document provides
guidance with the use of AS Path Prepending, including alternative
solutions, in order to avoid negatively affecting the Internet.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-as-path-prepending-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

[Alejandro Acosta]

Hello,

  Sorry to participate in this draft so late, my apologies.

  I support the draft and looking forward to have a formal document 
addressing as-prepending.


  My small comment, maybe a litte bit crazy idea; after reading the 
document and going thru the discussion in the mailing list, I wonder if 
it good to mention when a transiting AS performs prepending of customer 
prefixes and the customer does not want it do be done :-)



Thanks,


Alejandro,



On 28/12/23 5:56 PM, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-grow-as-path-prepending-09.txt is now available. It
is a work item of the Global Routing Operations (GROW) WG of the IETF.

Title:   AS Path Prepending
Authors: Mike McBride
 Doug Madory
 Jeff Tantsura
 Robert Raszuk
 Hongwei Li
 Jakob Heitz
 Gyan Mishra
Name:draft-ietf-grow-as-path-prepending-09.txt
Pages:   12
Dates:   2023-12-28

Abstract:

AS Path Prepending provides a tool to manipulate the BGP AS_Path
attribute through prepending multiple entries of an AS.  AS Path
Prepending is used to deprioritize a route or alternate path.  By
prepending the local ASN multiple times, ASs can make advertised AS
paths appear artificially longer.  Excessive AS Path Prepending has
caused routing issues in the Internet.  This document provides
guidance with the use of AS Path Prepending, including alternative
solutions, in order to avoid negatively affecting the Internet.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-as-path-prepending-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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] Proposing a well-known BGP community for Anycast

[Alejandro Acosta]

Hello,

  After reading the draft and the comments on the list. I think this is 
going to be useful and will make BGP take better decisions. +1 to move 
this draft forward.


  I wonder about the misuse of the community ANYCAST when the prefix 
being announced is not actually an anycast prefix, can be there a kind 
of abuse from some operators?. Do we need -if not out there already- a 
list of public anycasted prefixes (and I believe I have seem this 
question somewhere).



Regards,


Alejandro,


On 5/7/22 5:40 AM, Maximilian Wilhelm wrote:

Hey folks,

after some discussion at RIPE84 we took the time to formalize a draft
to define a well-known BGP community to indicate a given prefix is
carrying Anycast traffic. The intent is to allow ISPs to do well
informed TE, especially in cases where they want to diverge from the
hot potato principle.

You can find the draft at

https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/

Happy to share this at the upcoming meeting and hear your thoughts!

Thanks and best,
Max

___
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 Auto Discovery and BGP Auto Session Setup

[Alejandro Acosta]

Hello Robert,

 I just read the first document, I guess for most people could be
"interesting" too see BGP Auto Discovery, I'm not sure yet if I'm in
favor or against.

 Hope this is not a crazy comment. Well, in the document you (and other
co-authors) do not mention much about -any possible- impact this
mechanism could have in bgp route selection algorithm (which anyhow is
by default managed by vendors and modified by administrators). As far as
I could understand from your doc, routers can identify which prefixes
were learnt by auto-discovered devices and which were learnt by the
"traditional" BGP operation. Am I right? which one would you trust
more?, new administrative distance or something like that?.


Thanks,


Alejandro,


On 12/11/19 3:24 PM, Robert Raszuk wrote:
> Dear WG,
>
> We have seen formation of BGP Autodiscovery WG followed by total
> silence. Well maybe group is 
> live just not everyone got onto its private list :) 
>
> Regardless of this I refreshed and resubmitted two proposals in this
> very space. 
>
>
>   1. BGP Auto Discovery
>
>
>   https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-06
>
>
>   and
>
>
>   2. BGP Automated Session Setup
>
>
>   https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01
>
> *_Ad 1:_*
> First document is focused on WAN and IX scenario where establishing
> full mesh of IBGP or
> selected eBGP peering can automate the operational management tasks or
> if run in informational
> mode could validate NMS session setup correctness.
> Original proposal was presented many years ago in Vienna and at that
> point suggested extension to
> IGPs to flood discovery information for IBGP auto mesh. Later based on
> the input and discussions with
> Pedro the proposal got simplified to use classic Route Reflector as
> bootstrap node (info broker).
> Last input from Jon and Warren added the ability to also automate
> setup of eBGP sessions in selected
> scenarios.
> Since then the document was shelved for some time waiting for IDR WG
> turn to deal with discovery topic.
> So here we are.
> *_Ad 2: _*
> The second document first published in July 2018 provides a very
> trivial to implement mechanism (without
> even changing BGP state machine) to automatically establish common LAN
> or p2p interfaces BGP sessions.
> Typical use case would be Clos DC fabrics, customer PE-CE LANs, TORs
> to Compute Nodes etc ...
> Comments, questions, feedback on both proposals all very welcome.
> Kind regards,
> Robert.
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow


pEpkey.asc
Description: application/pgp-keys
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP deaggregation

[Alejandro Acosta]

Hello Robert,

  I really like the way you describe the situation. And this one is a
very important phrase:

"What is bad for Internet is propagating those more specific routes
beyond the point that they make any difference any longer. "

  I recognize that your draft if more complicated than what I expected
(sorry, my fault), but anyhow at the beginning I though: "this is so
true: after the AS_PATH reaches length X or more, then it does not look
necessary to propagate more specific routes". I might be wrong but I can
not think in any single situation.

  Hope your draft move forward.


Alejandro,



On 11/3/19 2:28 PM, Robert Raszuk wrote:
> Folks,
>
> Allow me to express a bit of a different view - this time from
> enterprise perspective. 
>
> Actually announcing more specifics of the block one owns has real
> service advantages. So in itself it is actually a good thing ! 
>
> What is bad for Internet is propagating those more specific routes
> beyond the point that they make any difference any longer. 
>
> There was proposal to aggregate those at dynamic points where sending
> them no longer brings any service/routing advantages, but apparently
> at that time no one cared much: 
>
> https://www.ietf.org/archive/id/draft-marques-idr-aggregate-00.txt  
>
> - - - 
>
> See assume I own /19 for a global network. I can't possibly announce
> that block via all of my 20 ISP peerings globally as top requirement
> is not to keep the Internet BGP table tiny, but rather to offer best
> service to customers. 
>
> Further more imagine I offer various services based on geo location.
> For customers in Japan I want them to go to Japan DMZ and not float to
> any other location just because his ISP is one AS hop away from NY and
> two AS hops away from Osaka or Tokyo ISPs I peer with. So if I would
> attract such service to US I would need to carry it back to Tokyo over
> global WAN - disaster. 
>
> See even /24 is a very coarse limit one has to deal with. I may have
> few gateways for a given service per site not 255. And each service
> has completely different service requirements from the network
> characteristic. If I have 8 ISPs there 
>
> It is very clear (at least to some) that basic BGP best path routing
> is suboptimal.. For years folks have been using SLA based routing to
> steer packets over non necessarily BGP best path between Internet
> endpoints. The more fine are the announcements the better egress path
> selection can be achieved. So the Internet is no longer used to reach
> A & B. It is used to reach A & B in most optimal way for a given
> application. 
>
> Let's therefore keep those points in mind while blindly bashing
> "deaggregation" and calling names those who do it :). I bet no one is
> doing that just for fun. 
>
> Enterprises are doing it to provide the best level of service. ISPs do
> it to serve the needs of their customers. It is feasible to enhance
> BGP to aggregate when it no longer makes sense to carry more specific
> prefixes - let's rethink this. 
>
> Thx,
> R.
>
>
> On Sun, Nov 3, 2019 at 8:41 PM Nick Hilliard  > wrote:
>
> Gert Doering wrote on 03/11/2019 19:15:
> > On Sun, Nov 03, 2019 at 03:10:29PM +, Martijn Schmidt wrote:
> >>> Maybe "BGP Deaggregation Slopping" as a working title?
> >> Or "Scenic BGP Deaggregation", or "BGP Globetrotting", or "BGP
> >> Castaways". If anything a connotation with the sea and/or submarine
> >> cables would be appropriate, I think!
> >
> > "BGP vandalism"
>
> "Noxious Routing"?
>
> 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


pEpkey.asc
Description: application/pgp-keys
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Alejandro Acosta]

Hello Sriram,

On 9/27/19 8:51 AM, Sriram, Kotikalapudi (Fed) wrote:
> Alejandro,
>
>>> It would be great if this were to progress to standards track RFC.
>>> AS_SETs are a nuisance and cause real-world confusion with no
>>> appreciable gain.
>> +1, well said.
> Thanks. Perhaps you are aware, but just in case ...

I was not aware, excellent, will follow there.


> The WG adoption call took place in IDR and this is now a WG draft (standards 
> track):
> https://tools.ietf.org/html/draft-ietf-idr-deprecate-as-set-confed-set-00 
> There seems to be significant interest to progress it to standards track RFC.
> Authors plan to make some revisions that were suggested and then we'll 
> request WGLC.


Thanks.


>
> Sriram  
>


pEpkey.asc
Description: application/pgp-keys
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Alejandro Acosta]

On 8/7/19 11:58 AM, Nick Hilliard wrote:
> Sriram, Kotikalapudi (Fed) wrote on 07/08/2019 18:42:
>> The authors have revised and uploaded a new version (-14).
>> Your inputs/comments are welcome. In particular, please share any
>> specific
>> operational considerations/concerns you may have regarding this topic.
>
> It would be great if this were to progress to standards track RFC.
> AS_SETs are a nuisance and cause real-world confusion with no
> appreciable gain.


+1, well said.


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


pEpkey.asc
Description: application/pgp-keys
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Alejandro Acosta]

Excellent idea to write this down.  Congrats to the authors.

What do you think in including also some suggestions when bringing up
the BGP sessions?.  Sometimes it´s good idea to bring them up one by one
or something like that, the idea is to make the device to fill out the
forwarding table, create cache, perform ARP lookups, ND, and so on. To
bring up all the session at once many times is not that good.


Alejandro,


El 12/3/17 a las 11:16 p.m., Job Snijders escribió:
> Dear GROW,
>
> With this BCP Internet-Draft we hope to draw some attention to good
> practises which can be applied by IP networks or IXPs to mitigate
> negative impact caused by maintenance operations on lower layer
> networks. The idea is to promote the concept of breaking the
> control-plane in a controlled fashion, before actually breaking the
> data-plane.
>
> Regarding the "Voluntary BGP Session Teardown Recommendations" - we all
> too often see operators do the equivalent of 'yanking the cable out of
> its socket' while not allowing any time for reconvergence. As far as I
> am aware, there is no documentation which recommends to shutdown BGP
> sessions and allow for some time for the traffic to subside due to
> rerouting, and then commence with the maintenance.
>
> Some background on the "Involuntary BGP Session Teardown
> Recommendations": a number of years ago an (at the time novel) approach
> was presented on how to reduce the negative impact of IXP maintenance.
> Since then the idea gained popularity and is applied at more and more
> IXPs. The video + pdf are available here:
> https://ripe67.ripe.net/archives/video/116/
>
> The approaches outlined in this document may not be required in every
> network topology, for instance some IXPs have fantastic 'make before
> break' methodologies accomplished through a layer of photonic switches.
>
> I'd like to ask the chairs for a 10 minute slot in GROW's session at
> IETF 98 to present on this draft.
>
> Kind regards,
>
> Job
>
> ps. Some may point out that this is a rampant layering violation, to which I
> will say: "yes". ;-)
>
> - Forwarded message from internet-dra...@ietf.org -
>
> Date: Sun, 12 Mar 2017 14:00:18 -0700
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-iops-grow-bgp-session-culling-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> Title   : Mitigating Negative Impact of Maintenance through 
> BGP Session Culling
> Authors : Will Hargrave
>   Matt Griswold
>   Job Snijders
>   Nick Hilliard
>   Filename: draft-iops-grow-bgp-session-culling-00.txt
>   Pages   : 9
>   Date: 2017-03-12
>
> Abstract:
>This document outlines an approach to mitigate negative impact on
>networks resulting from maintenance activities.  It includes guidance
>for both IP networks and Internet Exchange Points (IXPs).  The
>approach is to ensure BGP-4 sessions affected by the maintenance are
>forcefully torn down before the actual maintenance activities
>commence.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iops-grow-bgp-session-culling/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> - End forwarded message -
>
> ___
> 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