Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

["Joel M. Halpern" <joel at stevecrocker.com>]

Both of the examples you provided highlight the fact that if one 
allows BGP to send multiple advertisements for the same NLRI and same 
next-hop then the receiver must treat them as an atomic collection 
(i.e. the receivers considers that all the advertised paths are being used.)

This means that the case where the paths differ only on local-pref 
is, as you suggest, useless.

With regard to the case where the paths differ on AS PAth, as copied 
below from your note, this requires that the receiver consider all 
the AS Paths.  For example, if the receiver appears in any of the AS 
Paths, then none of the advertisements can be used.  And when passing 
the advertisements on further, either all the advertisements must be 
sent, or the collection of advertisements must be compressed in a way 
that preserves the presence of all distinct AS values and has the 
correct AS Path length.  How to perform such aggregation of AS Paths 
if the paths might be of different lengths is not something I 
currently know how to do.  (Merging AS Paths in ways that change 
properties relevant to the mandatory BGP decision algorithm 
introduces a whole new set of oscillation risks, which is why the 
merging has to preserve the properties mandated by the decision algorithm.)

When one uses the next-hop has the differentiator, the first case 
never comes up.  And the receiver can select from among the multiple 
paths, since they each have a different next-hop.  This is what led 
to the text in the ECMP draft that restricts the set of paths a 
receiver may choose.  And the definition of how to merge those 
eligable advertisements if the receiver chooses to use them.

There is an argument that we may, for theoretical reasons still 
subject to analysis or hypothesis, want to advertise secondary paths 
that are not used.  That would require a flag to indicate which paths 
are used vs unused.

Yours,
Joel M. Halpern

At 10:20 AM 8/31/2006, Glen Kent wrote:
> This router recieves two paths for 192/8 from the same BGP speaker.
>
> Path 1 - NLRI 192/8 AS_PATH {10 20} NEXT_HOP 1.1.1.1
>
> Path 2 - NLRI 192/8 AS_PATH {30 20} NEXT_HOP 1.1.1.1
>
> How does this router determine which route is being used by the
> upstream? I dont think we should progress any proposal without
> incorporating ways to indicate which path is being actually used in
> the forwarding.
>
> I know one of the authors of multiple_hop indicated that this could be
> easily done by introducing a field in the path attribute. Its not
> difficult but they need to show this to us. The same goes for
> add-paths.


_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr