The MPLS WG Archive

[mark seery <mark@interflect.com>]

Kireeti,

---- Kireeti Kompella <kireeti@juniper.net> wrote:
> Hi Mark,
> 
> (Please note change of subject.)

Noted - good idea, should have been done earlier, agreed.
> 
> On Mon, 17 Nov 2003, mark seery wrote:
> 
> > One of the fundamental precepts of routing, is that each node
> > understands the routing decisions each other node makes,
> 
> I don't agree.  For a simple example: in RIP, a router has no idea
> what the next hop will do.  Another (before y'all jump on me for
> saying that RIP is a routing protocol) is BGP.  Link state protocols
> are different -- in a sense, they give you too much information.

Oh yeah, thanks for reminding me of the conistency of topology knowledge in those other protocols ;-) (clearly a case of sarcasm).

Seriously, if I am wrong that OSPF and IS-IS assume every router in an area are using the same algorithm, then would appreciate being corrected. That path and distance vector algorithms advertise routes and select best routes based on policy etc. is different than the case when a common algorithm is being used. In those cases (well certainly in BGPs) there are mechanisms to prevent looping that are added to the protocol - it just doesn't happen, you have to do something to prevent it. If your point is that you could build a non algorithmic network then I concede your point. If your point is that you can have a non-algorithmic solution in a network that is already heavily algorithmically based, then I guess I would probably need some further discussion with you.

> 
> > this is to
> > prevent black holing among other things.
> 
> This is the job of routing protocols, not individual routers.

I think we would have a semantic debate if I responded to this, so let's not.

> 
> > So for example, the SPF
> > algorithm is not a secret,
> 
> Actually, the SPF *algorithm* can be a secret.  The result (a shortest
> path dag) is not a secret.  It can be (and has been) proven that if
> each router computes a spdag based on the same topology info, then no
> black holes arise.

Don't understand how the same topology would lead to the same result if there was not some common assumptions about how to get there. I understand at the implementation level you might want to do incremental stuff or do something innovative at the coding level, but not sure if that means that Dijkstra's isn't still the fundamental essence of what you are doing (in the case of OSPF or IS-IS). If you can point me to some reading on the use of different algorithms to achieve the same result I would appreciate it.

> 
> > As ECMP algorithms impact the forwarding
> > direction of packets, then I would suggest while not on the same level
> > of criticality as SPF, there is a similar logic that could be applied to
> > this case.
> 
> Different ECMP algorithms have happily co-existed in networks for a
> long time now.  The algorithms can be different, but there must be a
> consisten result; in this case, packets in a 'flow', whatever that is,
> must not be reordered.
> 
> There are both IP and MPLS networks with multi-vendor equipment with
> ECMP and they work just fine.

That is a good data point, thanks. Was there any interaction between the respective engineering teams to get it working?

> > In addition, having worked at a vendor trying to work out the best way
> > to do ECMP
> 
> Whole 'nuther ball game.  Very very hard question.  If I had an
> answer, I sure wouldn't share it :-)

Answer assumed ;-) You've worked with some of them so be careful now ;-)

Additionally, if it is true that at some time in history Juniper and Cisco chose a different hash, then it might not be as obvious as your playful comment suggests. Also at the time there was no existence of a PID. Since the existence of a PID has since been argued to be useful......

> > So bottom line is I would have to agree that two routers from different
> > vendors can not communicate in the same network using ECMP unless the
> > algorithm is known by both.
> 
> See above.
> 
> This is easy to see if you consider that an ECMP path is a set of
> choices in the data plane that *could* correctly have been made
> instead in the control plane; and that the set of choices is stable
> for a given packet flow.

You know there is nothing in this paragraph that I disagree which makes me wonder what the discussion is about. I obviously was missing an understanding on how to achieve "..the set of choices is stable for a given packet flow". I am not sure if it is a standard yet, but at least I understand the fundamentals better.