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

[Paul Jakma <paul at clubi.ie>]

Hi Enke,

On Wed, 23 Aug 2006, Enke Chen wrote:

> I am not sure what you meant by "same implementation view, and 
> dependent upon a particular implementation". In the add-path 
> proposal, the advertiser is responsible for allocating the 
> identifier suitable for a particular application, and the receiver 
> needs to use the (prefix, path-identifier) to identify a path to be 
> replaced.  I believe that part is clear in the proposal, but if it 
> is not, we'll need to make it clear.

That the sender must pick the identifier is quite clear. It's also 
clear the draft leaves that as an implementation matter.

The problem, and Joel's point (I think), is that in not giving any 
guidance on how this identifier is to be picked, implementations will 
settle on picking this identifier in a deficient way. E.g. 
particularly as the draft suggests that router-ID is one possible 
choice of such identifier (and indeed you suggest same the below).

Such a choice would not work for re-advertising multiple paths, e.g. 
a cluster of route-reflectors:

	RR1-RR2
       / |   |
      A  B   C

Say A, B and C all advertise a certain NLRI, P.

RR1 and RR2 use add-path with their clients and between themselves so 
as to allow all paths to be distributed to all RR-clients. Both the 
RR implementations go for the simple approach (as suggested in the 
draft and your email) of using the router-ID of the speaker a path 
was received from as the Add-Path-ID. So RR1 sends to RR2:

	UPDATE: feasible P:A, <attributes>
	UPDATE: feasible P:B, <attributes>

Where X:Y is: add-path NLRI for Prefix X and add-path-id of Y.

Now, how should RR2 advertise these to its clients?

It clearly can not blindly just use the Router-ID of the speaker it 
received the paths from (RR1 in both cases).

It could however just reuse the path-ids. So the RR's add-path 
implementation now becomes (wrt choosing Add-Path-ID):

	"If the received path already has a path-ID, and no other
         received paths have the same, just re-use that path-id.

         Otherwise, use the Router-ID of speaker the path was
         received from"

So now RR2 /can/ easily advertise the two paths received from RR1 to 
C and D.

However, our friendly BGP network administrator now figures out he 
really ought to have clients peer with both RRs, he does so for B 
(e.g. A and C's sessions to other RR may be broken for some reason):

	RR1-RR2
       /  |/ |
      A   B  C


RR2 now has recieved:

> From RR1:

	P:A
	P:B

> From B:

	P

What should it advertise to C?

The choices seem to be:

- Figure out that P and P:B are the exact same path (e.g. they'll
  have the exact same next-hop..), and advertise just P:B to C.

  - remember, that RR1 used 'B' as the path-ID is wholly at the
    discretion of RR1

  - the nexthop however...

or

- Advertise both P:B and P:B' to C

  - where B' is some constructed identifier for the path
    for P received from B

It seems to us that behaviour of the add-path draft with RR clusters 
may be quite indeterminable, given that the issue of the additional 
path-identifier is left completely at the discretion of speakers.

One could say "Ah, but ORIGINATOR_ID can be used!", but that's a 
route-reflection specific attribute. It won't work for other cases 
that could make use of add-path, e.g. ECMP..

Also, for ECMP, a lot of the details of whether not multiple-paths 
should be advertised or else whether or not the AS_PATH must be 'ECMP 
aggregated' revolve around next-hop.

> the routes (simulating full-mesh).  It is actually the (prefix, 
> router-id) that would identify a path instead of the prefix itself.

And see above :)

> As the issue of how to identify a path is so fundamental to a solution,  I 
> hope that it can be clarified before we dive into other details.

Yep, fully agreed.

And for any two paths to the same destination a speaker may have, the 
next-hop(s) serve(s) as an identity, regardless of other attributes 
of the paths.

- if they are not to the same remote speaker, the paths obviously are
  different (at least in that "plane" of routing)

- if they are the same, the two paths are effectively the same,
  regardless of the other attributes.

We maintain so anyway and think it to be fundamental to routing.

In which case, we might as well make use of this property, rather 
than having speakers left to reinvent identifiers, which we think is 
not quite as easy and problem-free in the general case as it is for 
simple RR cases.

So the question is how to settle the matter of the additional 
identifier..

regards,
--
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Populus vult decipi.
	[The people like to be deceived.]

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