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

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=40uninett.no@dmarc.ietf.org> wrote:
> 
> 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
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow