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

[Havard Eidnes <[e-mail]>]

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