Subject: RE: Load balancing draft

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Nov 2002 17:45:30 -0500

At 04:29 PM 11/19/2002 -0500, David Allan wrote:

>Tom:
>
> > >The concept of avoiding the reserved labels in an MPLS hash
> > as a "best
> > >way" makes some sense,
> >
> >
> >          Does this mean that we then have to mandate how IP
> > (L2TPV3) does traffic distribution too?  What is next?
>
>L2TPv3 from what I can tell does not have a mechanism by which I could
>distinguish any type of PE-PE probe of a PW so the example is moot. I can
>only use payload probes (I.610, ICMP, whatever).
>I think that this
> > solution looks
> > good in theory, but in practice there are huge problems with it.
>
>Only problem I can think of is that one cannot simply hash an arbitrary
>length of the MPLS frame. The implementation is a bit more complex, that's
>the price of testabilty.

         Not necessarily. I think you can test/trace the paths using LSP ping,
but of course, there is a price to pay for that too; there is no free lunch.
The advantage of the latter is that it works with all of the hardware
deployed today.

> > >though it would probably only be gradually available as
> > hardware changes.
> >
> >          Kireeti or you made a good point that
> > this solution is not evolutionary; it is revolutionary as it
> > will require
> > hardware changes.
>
>Many things eventually migrate to hardware. Some formerly hardware functions
>migrate to microcode. This years core LSR is next years edge box. Are we
>saying that MPLS is frozen in time based upon last year or the year before's
>implementation? If so, lets skip draft and simply promote everything to STD
>and go home.

         No, I am saying that there are always going to be low-end platforms
that have hardware limitations and thus might not be able to use the load
share algorithm you specify in this document.  What do we do for those?
I think we are just back in the situation that we are in today: proprietary
load balancing.  It works for IP and other technologies, why do we need
to mandate an algorithm here?

>On the surface it might sound reasonable to
> > say that well, hardware will evolve and as it does it must support
> > this sort of load-balancing. However, the fact of the matter is that
> > one size does not fit all in this case, and thus this will be a burden
> > on both existing and future implementations.
>
>At the moment you're stipulating that one size fits all. That's what the
>draft was trying to avoid.

         No, I am saying that what we have today is many sizes
fit all (in the case of load balancing) because that is a reality
of routers/switches.

         --Tom

>rgds
>Dave
><snipped to the end>

Success is relative; the more success, the more relatives. -Anonymous

---

From: Alia Atlas <[email-masked]>
Date: Tue, 19 Nov 2002 22:40:48 -0500

>The advantage of the latter is that it works with all of the hardware

How does it work today with the pseudo-wire case?  From the draft, it seems 
that the same PW label is used, but it is not the bottom of stack, b/c 
there is an explicit NULL underneath.

So, suddenly one must forward based not only on the MPLS label but also 
the  bottom-of-stack bit...

Tell me I'm missing something here, but if the above is really what is 
intended in the draft, I don't understand how you can claim that it is 
compatible with current MPLS hardware.

Alia

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 20 Nov 2002 09:14:55 -0500

At 10:40 PM 11/19/2002 -0500, Alia Atlas wrote:
>How does it work today with the pseudo-wire case?  From the draft, it 
>seems that the same PW label is used, but it is not the bottom of stack, 
>b/c there is an explicit NULL underneath.
>

         It is my understanding that tracing the PW "tunnel" LSP is the 
same as any
other MPLS LSP.

         --Tom

---

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Nov 2002 09:24:42 -0500

>         It is my understanding that tracing the PW "tunnel" LSP is the 

To quote from the current draft:

  "To test an LSP that carries non-IP traffic, before injecting ICMP and
    MPLS ping messages into the LSP, the IPv4 Explicit NULL label should
    be prepended to such messages. The ingress and egress LSR's must
    follow the procedures defined in [LABEL-STACKING]."

Thus, as I understand it, one would have the tunnel label followed by the 
VC label followed by the IPv4 Explicit NULL label.  Unfortunately, at the 
Pseudowire egress, the ingress interface would look at the VC label and 
forward it to the egress interface to be transmitted as a layer 2 
frame.  To avoid this, one would have to look at the bottom-of-stack bit...

So, this sounds to me as if part of the forwarding decision is being made 
based upon the BOS bit.

Alia

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 20 Nov 2002 06:32:57 -0800

Yes, the "tunnel" labels don't change.  However, if an implementation
"indiscriminately" uses all labels to hash on, then it would use the VC label
for data packets, and VC + OAM label for OAM packets, yielding a not so nice
result.

In that sense, it "would be nice" to suggest that a BCP should be to ignore
reserved labels.  While various implementations may not be able to follow this
guideline, it is still a reasonable suggestion, somewhat along the lines of
saying don't use certain fields in the IP header for hashing.

-Vach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Thomas D.
> Nadeau
> Sent: Wednesday, November 20, 2002 6:15 AM
> To: Alia Atlas
> Cc: David Allan; [email-masked]'
> Subject: RE: Load balancing draft
>
>

---

From: George Swallow <[email-masked]>
Date: Wed, 20 Nov 2002 09:48:48 -0500

> saying don't use certain fields in the IP header for hashing.

This is a poor analogy.  It is easy to avoid sepecific fields.
Avoiding specific values means testing whether the label is one of
those values.  Burns cycles! (or gates, take your pick)

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824