Subject: RE: your mail

From: "Gibson, Mark" <[email-masked]>
Date: Tue, 2 Jul 2002 18:02:22 +0100

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.  

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.  

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

If your arguing the top paragraph then I'm fine and I'll go back to lurking.

Mark

-----Original Message-----
From: Gray, Eric [mailto:[email-masked]]
Sent: 02 July 2002 17:32
To: 'Hummel Heinrich'
Cc: [email-masked] '; 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.
[email-masked]
508 305 7214

-----Original Message-----
From: Hummel Heinrich [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2002 11:59 AM
To: 'Gray, Eric'; Hummel Heinrich; [email-masked]'; Shahram Davari
Cc: 'Eric Osborne '; 'George Sheng '; [email-masked] '; [email-masked] '
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:[email-masked]]
Gesendet: Dienstag, 2. Juli 2002 17:47
An: 'Hummel Heinrich'; [email-masked]'; Shahram Davari
Cc: 'Eric Osborne '; 'George Sheng '; [email-masked] ';
[email-masked] '
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.
[email-masked]
508 305 7214

-----Original Message-----
From: Hummel Heinrich [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2002 11:36 AM
To: [email-masked]'; Shahram Davari
Cc: 'Eric Osborne '; 'George Sheng '; [email-masked] '; [email-masked] '
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:[email-masked]]
Gesendet: Dienstag, 2. Juli 2002 17:02
An: Shahram Davari
Cc: 'Eric Osborne '; 'George Sheng '; [email-masked] ';
[email-masked] '
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.

---

From: Eric Osborne <[email-masked]>
Date: Tue, 2 Jul 2002 13:29:53 -0400

> 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.  

> 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.

> 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

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 2 Jul 2002 11:04:17 -0700

For ECMP, you have to look at least one label lower (or more precisely, one
layer higher).  Essentially, you are trying to identify flows and make sure a
particular flow goes over the same path, to avoid out-of-sequence issues.  The
identifiers for a flow lie at least one layer higher than the label stack at
which you operate.

So, an L2 flow is identified by the VC label, a TCP flow is identified by the
port numbers, etc.

-Vach

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Gibson,
> Mark
> Sent: Tuesday, July 02, 2002 10:02 AM
> To: [email-masked] '; Gray, Eric
> Subject: RE: your mail
>
>