Subject: RE: your mail

From: [email-masked]
Date: Wed, 3 Jul 2002 19:21:49 +0100

Giles......can you please just expand on what you mean here in the case of
XoverMPLS PWE3 work?  As a min one would see (in order lowest->highest, or
outer->inner, the following 'words'):
Outer Tunnel LSP header->Inner VC LSP header->Control-word (optional)->
various payload types.

regards, Neil

> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: 03 July 2002 18:01
> 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: 04 Jul 2002 12:44:35 +0000

agreed - this is what you'd expect to see.

IMO the only traffic that should ride directly over a tunnel LSP is IP
(v4 or v6).

however there is one implementation out there (that I know of - there
may be others) where layer 2 traffic is carried directly over a tunnel
LSP.

Giles