Subject: RE: your mail

From: "Gray, Eric" <[email-masked]>
Date: Tue, 2 Jul 2002 12:35:37 -0400

Eric,

	I'm guessing that some hardware implementations might be 
optimized around the need to process at most K labels.  For any
such implementation, being required to possibly look at the Nth
label - where N is the number of labels in the stack and N may 
be greater than K - may be virtually indistinguishable from 
being required to parse the entire packet.

	In such cases, the engineers have to take a hard look at
what they might use as a fall back for the N > K case and then
do some hard analysis about whether or not such a fall back is
guaranteed to work in all cases.  Because the consequences of
not getting the right answer after all this hard looking and
analysis are systemic at the network level, it might be useful
if this was hashed out publicly in a little more detail - don't 
you think?  :-)

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2002 11:02 AM
To: Shahram Davari
Cc: 'Eric Osborne '; 'George Sheng '; [email-masked] '; [email-masked] '
Subject: Re: your mail 

SD=> So you do more than one lookup- so what? so you need to parse the whole
SD=> packet in the core-so what? so you need to keep state in the core,

Please pay attention. 

There is not  more than one lookup; doing the hash  does not require looking
anything up. 

Finding the bottom label does not involve parsing the whole packet. 

There is no state kept in the core. 

SD=> so you have no longer a simple label swap

It is true that the essence of  load balancing over equal cost paths is that
the outgoing interface  is not chosen solely on the basis  of the top label.
So? 

SD=> MPLS was  designed to have simple  forwarding. Hashing takes  it to new
SD=> levels of simplification never seen before.  

You might take a peek at section 3.12 of RFC 3031.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 02 Jul 2002 13:02:59 -0400

EricG.> 	I'm guessing that some hardware implementations might be 
EricG.> optimized around the need to process at most K labels.  For any
EricG.> such implementation, being required to possibly look at the Nth
EricG.> label - where N is the number of labels in the stack and N may 
EricG.> be greater than K - may be virtually indistinguishable from 
EricG.> being required to parse the entire packet. 

For load balancing, it should be  sufficient to look at the bottommost label
which  appears in  the high  speed  memory whose  intention is  to hold  the
header.  That is,  if you can only  see top K labels, use  the bottommost of
those.