The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

Shahram,

	I don't think the issue is whether or not people feel
that this work is applicable.  I believe it might be better
to characterize the issue as whether or not it is practical
(or even feasible) to do this given stated constraints.

	As with QoS and other types of value add functionality,
the 9 letter acronym TANSTAAFL applies.  There ain't no such
thing as a free lunch - in this case or in any other.  Given
the current situation with respect to existing and deployed
hardware, about the only short term approach to ensure that
probe packets follow the data path is likely to be disabling 
load sharing.

	In terms of specifying another approach, at least for
the alternatives discussed, these are potentially areas of
product differentiation and/or long term "fixes".  Hence it
is probably not something we necessarily want to undertake
at this point.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Tuesday, November 19, 2002 10:37 AM
> To: 'MPLS@UU.net'
> Subject: Load balancing draft
> 
> Hi,
> 
> One of the criticism for this draft was that it is designed to overcome
> Y.1711 limitation, in which a reserved label is used. As I mentioned
> in the meeting the MPLS-Ping also requires usage of an extra reserved
> label for non-IP carrying LSPs:
> 
>   "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."
> 
> So this draft is equally applicable to MPLS-ping.
> 
> Yours,
> Shahram