The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Nov> msg00139



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Load balancing draft

  • From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
  • Date: Wed, 20 Nov 2002 06:44:14 -0800
  • Cc: David Allan <dallan@nortelnetworks.com>, "'MPLS@UU.net'" <MPLS@UU.NET>

This equally applies to MPLS-ping for non-IP carrying LSPs. Because 
for non-IP carrying LSPs there is no IP address to be cycled through (as is the case for IP-carrying LSPs) to exercise all the ICMP paths. And the
inclusion of Explicit Null label in the hashing could cause MPLS-ping to take a different path from data.

May be this could be captured in an Information draft.

-Shahram

> -----Original Message-----
> From: Vach Kompella [mailto:vkompella@timetranetworks.com]
> Sent: Wednesday, November 20, 2002 9:33 AM
> To: Thomas D. Nadeau; Alia Atlas
> Cc: David Allan; 'MPLS@UU.net'
> Subject: RE: Load balancing draft
> 
> 
> 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: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf 
> Of Thomas D.
> > Nadeau
> > Sent: Wednesday, November 20, 2002 6:15 AM
> > To: Alia Atlas
> > Cc: David Allan; 'MPLS@UU.net'
> > Subject: RE: Load balancing draft
> >
> >
> > At 10:40 PM 11/19/2002 -0500, Alia Atlas wrote:
> > >At 05:45 PM 11/19/2002 -0500, Thomas D. Nadeau wrote:
> > >>         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.
> > >
> > >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.
> >
> >          It is my understanding that tracing the PW 
> "tunnel" LSP is the
> > same as any
> > other MPLS LSP.
> >
> >          --Tom
> >
> >
> >
>