Subject: RE: your mail

From: "Gray, Eric" <[email-masked]>
Date: Wed, 3 Jul 2002 13:24:48 -0400

Giles,

	I should go into this a bit further.

	One of the reasons to worry about 'layer violations' 
(oooh, there's that awful word again :-O) is if there has 
been a conscious decision to punt specification of some 
uses of a 'layer' because of its assumed inviolability.  In 
MPLS, there has been at least one such punt - the header 
compression proposal that George Swallow brought forward some
time ago.  The working group decided that there was no reason 
to specify this scheme, since it would take place over MPLS
between presumably cooperating systems.

	This is just one example.  Another might be IPv6/MPLS.
Who knows how many other things people are looking at (or have 
looked at) as X/MPLS applications? With MPLS, the working group 
has repeatedly had to consider whether or not to just change
the name of the protocol to IP(v4)LS.  So far as I know, this 
has not yet happened.   :-)

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:57 PM
To: Gray, Eric
Cc: 'Kannan "S (Networking) ""- CTD, ""Chennai.'; Eric Osborne; 'MPLS
Mailing list'
Subject: RE: your mail

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

On Wed, 2002-07-03 at 16:51, Gray, Eric wrote:
> 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"
> =================================================================
> 
-- 
=================================================================
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:45:30 +0000

Hi Eric,

I'd hope that there is no intention to specify anything other than IPv4
or v6 running directly over MPLS.  MPLS is, after all, not a layer in
its own right (but let's not have that debate again!)

Giles

---

From: David Charlap <[email-masked]>
Date: Mon, 08 Jul 2002 10:50:07 -0400

Giles Heron wrote:
> or v6 running directly over MPLS.

You're confusing the specification with current implementations.  This 
is a very very dangerous assumption to make.

RSVP-TE explicitly defines the L3PID field of the LABEL_REQUEST object 
so that many layer-3 protocols may be run through LSPs.  The Martini 
draft defines a mechanism for running all kinds of different layers 
through LSPs.  There are also some proprietary mechanisms for running 
layer-2 traffic through LSPs.

> MPLS is, after all, not a layer in

Whether you want to call it a layer or not is irrelevant.

The fact is that MPLS is specified to support non-IP traffic on the data 
plane, and there are implementations that are supporting this.  If your 
implementation's design breaks non-IP traffic flows, then your 
implementation's design is broken.

-- David

---

From: Giles Heron <[email-masked]>
Date: 08 Jul 2002 16:27:26 +0000

> layer-2 traffic through LSPs.
[rest snipped]

LDP load balancing doesn't apply in the RSVP-TE case.

And as a co-author of draft-martini I think it is safe to say that I
understand how it works ;-)

draft-martini allows indeed allows different types of traffic to be run
over LSPs, however it does this by means of a label stack.

Except in the case of the final hop when running PHP there is always a 2
or more label stack for draft-martini.

The one proprietary mechanism I am aware of for L2 over MPLS relies on
RSVP-TE, so again LDP load balancing is moot.

Giles