Subject: RE: your mail

From: "Gray, Eric" <[email-masked]>
Date: Wed, 3 Jul 2002 12:51:56 -0400

Giles,

	I was responding to this statement:

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

How does my response to this relate to your comment?  :-)

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

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2002 1:01 PM
To: Gray, Eric
Cc: 'Kannan "S (Networking) - CTD, ""Chennai.'; Eric Osborne; 'MPLS Mailing
list'
Subject: RE: your mail

On Wed, 2002-07-03 at 13:55, Gray, Eric wrote:
[snip]
> 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.   

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

> 
> 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.
> 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

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

oops, yeah good point.

In this case clearly you *can* still look for an IPv4 header - it is
just rather uglier.  The trick is to look for the value 0100 in the
first 4 bits.  The risk is, of course, that there may be a client
protocol which also sends this :(

Giles