The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

On Tue, Jul 02, 2002 at 06:02:22PM +0100, Gibson, Mark wrote:
> So pardon me for butting in but isn't this really the nub of the argument
> here.  That an LSR can examine and interpret the labels that it has
> allocated out of its own label space in any manner it chooses - since it
> knows what they relate to - but that it should not look any deeper into the
> label stack than its own allocated labels.  

I believe the discussion started out as "LDP can't do traffic
engineering" and has mutated from there.  

> If its sent n labels it can look up to n labels into the stack.  How it can
> place any interpretation on the n+1 th label I don't know.  
> 

Because we're not talking about *switching* based on the underlying
labels, but about some sort of tie-breaker.  It's not like if you send
me labels underneath what I gave you that I'll switch the label
towards a *different* network exit point; my job, if I'm an LSR, is to
switch based on the top label.  But if there's more than one way to go
to get to the point to which the top label resolves, I need a
tie-breaker.  This is what hashing (or however you implement it) is
for.

> And if it can, it kind of destroys all the MPLS-label-based VPN privacy
> arguments in one fell swoop.  

No, it doesn't.  The privacy stuff applies not to using data to do
some sort of lookup for traffic forwarding, but for things like
network seperation and overlapping address space.  The data underneath
an MPLS stack is just as private whether it's used to hash or not.



eric

> 
> If your arguing the top paragraph then I'm fine and I'll go back to lurking.
> 
> 
> Mark
> 
> -----Original Message-----
> From: Gray, Eric [mailto:egray@celoxnetworks.com]
> Sent: 02 July 2002 17:32
> To: 'Hummel Heinrich'
> Cc: 'mpls@UU.NET '; Gray, Eric
> Subject: RE: your mail 
> 
> 
> Heinrich,
> 
> 	So, this particular branch has been hashed
> out several times in the past.  Interpretation of
> labels is an implementation issue.  It should be
> possible for an implementation to interpret its own
> labels in whatever way it wishes, consistent with
> the notion of fulfilling its role in forwarding
> packets.
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> egray@celoxnetworks.com
> 508 305 7214
> 
> 
> -----Original Message-----
> From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] 
> Sent: Tuesday, July 02, 2002 11:59 AM
> To: 'Gray, Eric'; Hummel Heinrich; 'erosen@cisco.com'; Shahram Davari
> Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET '
> Subject: AW: your mail 
> 
> If there were several NHLFEs there is only one proper interpretation and
> that
> is point-to-multipoint i.e. multicast. Either several branches out from the
> source node, or several branches
> in the middle of the multicast delivery tree.
> 
> To interprete whatever pleases you, kills the entire state of the art.
> Heinrich
> 
> -----Ursprüngliche Nachricht-----
> Von: Gray, Eric [mailto:egray@celoxnetworks.com]
> Gesendet: Dienstag, 2. Juli 2002 17:47
> An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari
> Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com ';
> 'mpls@UU.NET '
> Betreff: RE: your mail 
> 
> 
> Heinrich,
> 
> 	What a standard should not do is unnecessarily 
> constrain implementations.  If an implementation has 
> more than one NHLFE for the same label, which one it 
> (the implementation) chooses to use _really_ is an 
> implementation local issue.  The standard need not 
> (and should not) say anything about it...
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> egray@celoxnetworks.com
> 508 305 7214
> 
> 
> -----Original Message-----
> From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] 
> Sent: Tuesday, July 02, 2002 11:36 AM
> To: 'erosen@cisco.com'; Shahram Davari
> Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET '
> Subject: AW: your mail 
> 
> 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.