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

From: [email-masked]
Date: Thu, 17 Feb 2022 17:49:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

        Title           : AS Path Prepending
        Authors         : Mike McBride
                          Doug Madory
                          Jeff Tantsura
                          Robert Raszuk
                          Hongwei Li
                          Jakob Heitz
                          Gyan Mishra
	Filename        : draft-ietf-grow-as-path-prepending-06.txt
	Pages           : 12
	Date            : 2022-02-17

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 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-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-as-path-prepending-06

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

---

From: Michael McBride <[email-masked]>
Date: Fri, 18 Feb 2022 01:55:20 +0000

This update addresses some additional comments from Greg Skinner. Much thanks to Greg for taking the time to review the draft.

The authors believe it is ready for wglc.

mike

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, February 17, 2022 5:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-06.txt

Abstract:

The IETF datatracker status page for this draft is:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2F&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cbf249cfcb5bc44cde7fd08d9f2810036%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637807458170980219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=S9VR7udP5LUoGVUbUiTWihRNSzW1KTMtaeNsWfmlByk%3D&amp;reserved=0

There is also an htmlized version available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-06&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cbf249cfcb5bc44cde7fd08d9f2810036%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637807458170980219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YosL%2BRN6shd7ZAeRLNOyCQRgXepcLOTmIxC630MO5NQ%3D&amp;reserved=0

A diff from the previous version is available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-grow-as-path-prepending-06&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cbf249cfcb5bc44cde7fd08d9f2810036%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637807458170980219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=VkEUKErScr3UhnuRHamNJf0St2mUn2NEEyzoTI9lAE0%3D&amp;reserved=0

_______________________________________________
GROW mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cbf249cfcb5bc44cde7fd08d9f2810036%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637807458170980219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=pygDN7Oqmd1PQosFeknAafPTVuE0aP7fa8zgP41TKPM%3D&amp;reserved=0

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 18 Feb 2022 13:28:10 +0100 (CET)

Hi,

here are a few comments about section 3.1 in the draft:

Other than the missing comma in the list of routers/ASes, near
the end there is talk about a route leak.  However, I don't think
what's stated here as a route leak is what's commonly understood
to be a route leak.

I think a route leak is commonly understood to be when a route is
announced to a neighbor in violation of the (intended) routing
policy, i.e. a route leak can be the result of an erroneously
implemented intended routing policy.  I can't see how that's the
case here, because no routing policy has been expressed for "I".
This probably means that "I" re-advertises all routes it
receives, from any edge on any other edge, and therefore by
definition can't have a "route leak".

It's another matter that the traffic pattern from B to J in the
stated scenario involves a change to a path which traverses I.

If we instead of "thinking BGP" in the drawing in 3.1, suppose we
think "RIP with max metric 64" instead.  Of course when you
adjust metrics on any interface in the topology, traffic flows
will shift around.  I can't quite understand when we do the
similar thing in BGP it's such a big problem?

Admittedly, by prepending outgoing route announcements towards a
given peer, you only affect "one end of the link", and there's a
fair chance that asymmetric traffic patterns will result if
that's the only thing which is done.  But...  Is that a problem?

I think the problem desribed in section 3.1 could do with a bit
clearer description of why this is problematical.

Regards,

- Håvard

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Feb 2022 11:13:24 -0500

I support Hávard's observations. 

I'd also like to comment that the notation of "prepends 5" meaning "5 + 1" is a bit confusing for all of the examples.  Consider instead just saying what the announced as-path length is.  Operators prepend 5 because their intent is "announce 6". :-)

Rather than try to cast the (very contrived) scenario as a form of route leaking, I'd suggest the authors focus on the impact of downstream consumers of the prepending.  In particular, the example here simply notes that the receiving AS had a desire to use one path, but the upstream providers in executing their own motivations caused them to not have such a preferable path by default.

Sadly, too bad for this downstream operator.  The more hops away you are from a given bit of reachability, the less your opinion tends to matter over what the announcements look like.  It's likely time for them to form a business relationship with the announcing AS or one of their immediate service provider ASes.  (And thus, reinforcing business motivations that push the AS diameter of the Internet to remain small...)

-- Jeff

> On Feb 18, 2022, at 7:28 AM, Havard Eidnes <he=[email-masked]> wrote:
> 
> Hi,
> 
> https://www.ietf.org/mailman/listinfo/grow

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Feb 2022 17:24:42 -0500

Hi Jeffrey & Havard

Thank you for the comments.

The goal of 3.1 was to graphically depict the how excess as-path prepending
and how that could yield or exacerbate prefix hijacking impact downstream
consumers of pretending as you stated with ripple effect where a desirable
source origin AS becomes de-preferred or hijacked resulting in a route
leak.  We will also mention using BGP prefix origin validation RFC 6811 to
mitigate prefix hijacking resulting in a route leak.  The goal of 3.1 was
also to shed light on the ripple effects to downstream providers consuming
the prepends resulting in extremely long AS path exceeding the 255 max
as-path.  Also in 3.1 the goal was to depict the impact of “prepend to all”
resulting in prefix hijacking due to de-prefer of origin AS route resulting
in route leaks.

We will make  3.1 more clear in depicting a route leak from prefix
hijacking resulting from “prepend to all” excessive prepending.  Also
remove the 5+1 making it announce six.

Many Thanks

Gyan

On Fri, Feb 18, 2022 at 11:13 AM Jeffrey Haas <[email-masked]> wrote:

> I'd also like to comment that the notation of "prepends 5" meaning "5 + 1"
> is a bit confusing for all of the examples.  Consider instead just saying
> what the announced as-path length is.  Operators prepend 5 because their
> intent is "announce 6". :-)
>
> Rather than try to cast the (very contrived) scenario as a form of route
> leaking, I'd suggest the authors focus on the impact of downstream
> consumers of the prepending.  In particular, the example here simply notes
> that the receiving AS had a desire to use one path, but the upstream
> providers in executing their own motivations caused them to not have such a
> preferable path by default.
>
> Sadly, too bad for this downstream operator.  The more hops away you are
> from a given bit of reachability, the less your opinion tends to matter
> over what the announcements look like.  It's likely time for them to form a
> business relationship with the announcing AS or one of their immediate
> service provider ASes.  (And thus, reinforcing business motivations that
> push the AS diameter of the Internet to remain small...)
>
> -- Jeff
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*