Subject: RE: your mail

From: [email-masked]
Date: Thu, 4 Jul 2002 16:19:40 +0100

Thanks Giles.....but I am still puzzled....please see below.  regards, Neil

Giles Heron explained 04 July 2002 13:45
> 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).
NH=> So an MPLS LSP is not allowed over a tunnel.....is that what you are
saying here?  But I can't figure your logic at all......'tunnels' can be
nested right, so by definition the client of one tunnel can be another
tunnel.  And the client of the bottom-of-stack LSP (which is the highest
tunnel in the LSP stack) can be (i) v4 (ii) v6 (iii) a PWE3 control-word or
(since this is optional) some other client layer technology trail, like an
ATM VPC, PPP, FR, etc.
> 
> 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.
NH=>  Can you explain the difference between an MPLS tunnel and an LSP
please?
BTW - How does VoverMPLS fit with all this?
> 
> Giles
> 
> On Wed, 2002-07-03 at 18:21, [email-masked] wrote:
> > 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"
> > > =================================================================
> > > 
> > 
> -- 
> =================================================================
> 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 17:34:05 +0000

> (since this is optional) some other client layer technology trail, like an

no.

What I'm saying is that if there is a stack depth of one (other than on
the last hop in the presence of PHP) then the client ought to be IP.

sorry if my wording was sloppy :(

Giles