Subject: RE: your mail

From: "Gray, Eric" <[email-masked]>
Date: Wed, 3 Jul 2002 09:55:27 -0400

Kans,

There are a few things that are non-obvious that have some
relevance to your comments.  

One is that MPLS as a whole relies on a trust model that 
is dependent on correct behavior of LSP participants.  In
electing to differentiate the labels used for packets that 
are likely to be part of a common flow in forwarding them
to a downstream peer, an LSR assumes some risk that they 
will not follow the same physical path (they'd be different
label switched paths, after all).  This would be wrong.

Another is that - if an upstream LSR uses an approach such
as you suggest (perhaps to do its own brand of ECMP) - then
it will not be at risk of putting packets that are likely
to be part of the same flow on different paths.  This is OK
and - if an LSR receiving these packets decides to use the
bottom label (which we have found is 'bottom' by almost any
reasonable definition) - then the worst it will do is lump
'similar' (defined for any particular hashing scheme) flows
together.  It will not result in splitting a flow unless an
upstream LSR is guilty of 'BAD behavior' described above.

Thirdly, it is definitely inappropriate to assume that the
stuff after the last label is an IP header except in the
case where the last label is an explicit IPv4 NULL label.  
It could be any of a lot of things otherwise and - given 
PHP and a number of defined MPLS applications - the last 
label is very unlikely to be an IPv4 explicit NULL label.   

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

-----Original Message-----
From: Kannan S (Networking) - CTD, Chennai. [mailto:[email-masked]]

Sent: Wednesday, July 03, 2002 3:25 AM
To: Eric Osborne
Cc: 'MPLS Mailing list'
Subject: RE: your mail

Eric,

About the idea of using the bottom most label for doing ECMP -

Wouldnt that restrict the ECMP hashing function, because my hashing function
is now totally dependent on how some router in the edge chose to identify a
flow?

For example, suppose an ingress edge LSR marked the bottom most label using
say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant
have an hashing algorithm which uses last 10 bits of IP - SA, and first 10
bits of IP - DA, right ?  The efficiency of the algorithm (the choice
itself) is now very dependent on how the edge LSR identifies flows. 

My point is, if it is decided that an LSR is going to look beyond whatever
depth it is supposed to, the LSR's ECMP hashing function might as well look
at the IP header instead of looking at the bottom most label. 

Am I missing something here?

Thanks,
Kans.

-----Original Message-----
From: Eric Osborne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2002 4:01 AM
To: Gray, Eric
Cc: 'Eric Osborne'; 'MPLS Mailing list'
Subject: Re: your mail

On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote:
> Eric,
> 
> 	It is in the fact that we have to be sure -
> just as you suggest.  The cost of being sure, however, 
> is that you have to be prepared to deal with occasions 
> when the check fails.  What do you do when the higher
> layer is not UDP or TCP - throw these packets in to a 
> common bucket?  What is the expected impact if this 
> traffic might occasionally be significant?

Then you need a better load-balancing algorithm.  Either IP SA/DA and
some randomness, or random sampling from the packet, or (heaven
forbid) some sort of flow-based scheme.  I'm even dubious about the
efficacy of using TCP/UDP ports to hash, given that most traffic is
either src or dst TCP port 80, which really only gives you the port in
the other direction to play with.  But that's not really my problem,
as the implementation I'm familiar with doesn't do anything with
TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a
device that does; I just don't deal with it/them).

also, don't forget that this hypothetical algorithm takes into acount
IP SA/DA and TCP/UDP SP/DP.  So if you have too many collisions, you
probably have very few flows/conversations/whatnot anyways, and either
need to move to something like per-packet (ick) or just larger pipes.

eric

>  
> 
> Eric W. Gray
> 
> 
> -----Original Message-----
> From: Eric Osborne [mailto:[email-masked]] 
> Sent: Tuesday, July 02, 2002 4:24 PM
> To: Gray, Eric
> Cc: 'Eric Osborne'; 'MPLS Mailing list'
> Subject: Re: your mail
> 
> On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote:
> > Eric,
> > 
> > 	To answer your final two questions, yes it probably
> > is stealing.  The fact that you can get away with a crime
> > does not make it any less a crime.  Who knows, some vendors 
> > may not check that the protocol over the top of IP is either 
> > UDP or TCP before using the port numbers.  
> 
> If a vendor checks the offset where the port numbers should be without
> checking for the correct protocol type, this is a cruddy
> implementation and shouldn't exist.  My question was really along the
> lines of "what if we use the values that we *know* are UDP/TCP port
> numbers"?  From what you say above, it seems like that might be OK, as
> long as we only do this when we're sure?  Or is there some inherent
> architectual layer violation thing that you're objecting to?
> 
> 
> 
> eric
> 
> > I think you can 
> > easily imagine what that might lead to if a set of packets 
> > carry a higher level protocol where the corresponding fields 
> > may vary from packet to packet in a single micro-flow.  The
> > real question is how common is this?
> > 
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > [email-masked]
> > 508 305 7214
> > 
> > 
> > -----Original Message-----
> > From: Eric Osborne [mailto:[email-masked]] 
> > Sent: Tuesday, July 02, 2002 1:32 PM
> > To: Hummel Heinrich
> > Cc: [email-masked]'; Shahram Davari; 'Eric Osborne'; George Sheng;
> > [email-masked]; [email-masked]
> > Subject: Re: your mail
> > 
> > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote:
> > > It  gets weirder  and weirder: The MPLS WG invents a label stack, but
> does
> > not care at all that any of the
> > > deeper nested labels may ever be signalled/carried by means of a
> > Label-TLV/object (no public comments to my
> > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt).
> > > 
> > > However it is ok, to "steal" the deepest nested label and call it
> > "VC-label" for indexing
> > > some VRF at some remote PE. 
> > 
> > This is not theft; it's using the labels as they were designed.  How
> > is using the bottommost label as a VC-labe/VPN label/whatever
> > "stealing"?  You seem to be attacking the very idea of label stacking,
> > which is a pretty useful concept.
> > 
> > > Furthermore it is ok, to "steal" the very same label for hashing.
> > > 
> > 
> > What about IP router vendors that do load-balancing based on L4/L5
> > information like protocol type and port numbers?  Is that stealing?
> > 
> > 
> > 
> > 
> > eric
> > 
> > > Independent from what is clean and what is quick&dirty, I cannot
detect
> > any sense in giving a hash-meaning to the bottom label at all.
> > > 
> > > 
> > > 
> > > Heinrich Hummel
> > > Siemens
> > > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Eric Rosen [mailto:[email-masked]]
> > > Gesendet: Dienstag, 2. Juli 2002 16:06
> > > An: Shahram Davari
> > > Cc: 'Eric Osborne'; George Sheng; [email-masked]; [email-masked]
> > > Betreff: Re: your mail 
> > > 
> > > 
> > > Shahram> To do ECMP, you need to  assign hashed values to egress
ports.
> > This
> > > Shahram> assignment is the hash state that I said you need.  
> > > 
> > > A hash is  a function that maps  some sequence of octets into  a
> sequence
> > of
> > > integers.  If you want to split  traffic over six paths, while
ensuring
> > that
> > > all packets  with the  same bottom label  travel the  same path, you
> need
> > a
> > > function that maps  a 20 bit quantity  into a number from 1-6.   There
> is
> > no
> > > need to maintain state of any kind.

---

From: Giles Heron <[email-masked]>
Date: 03 Jul 2002 17:01:02 +0000

On Wed, 2002-07-03 at 13:55, Gray, Eric wrote:
[snip]
> label is very unlikely to be an IPv4 explicit NULL label.   

Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware
of any application putting non-IP traffic directly over an LSP (i.e.
without using a label stack).

Therefore when there is only one label (other than when an egress LSR
using PHP receives a packet - in which case load balancing is somewhat
moot) I think we can assume that the payload is IP?

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================