The MPLS WG Archive

[Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>]

Eric, 
Let me cite section 3.12 of RFC 3031:
The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs.  It is
used when forwarding packets that arrive unlabeled, but which are to
be labeled before being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains
more than one element,...

What kind of logic is applied in saying :
"the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla"

All I can conclude is, that a label is equal to a FEC.
I am sure, I am not the only one who is lost.

And if such kind of logic were written into this RFC intentionally, then I think things are
getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one
as a hint for load balancing, and a third one as a message from the Captain of the Night.
BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? 
 
Heinrich


-----Ursprüngliche Nachricht-----
Von: Eric Rosen [mailto:erosen@cisco.com]
Gesendet: Dienstag, 2. Juli 2002 17:02
An: Shahram Davari
Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com ';
'mpls@UU.NET '
Betreff: 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.