The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3549C09B853DD5119B540002A52CDD3401267946@zcard0ka.ca.nortel.com>, "
David Allan" writes:
> 
> > LSP Ping is relatively new so I agree that there is no prior consensus
> > behind it.  I was not at the meeting so I do not know what measure of
> > support it has.  The use of the existing wire rate ICMP processing for
> > non-IP LSPs was a very good idea.  
> 
> Can you elaborate on the "very" part? I tend to see it as a useful
> expediency, and that's OK, but it has limitations and does not meet all my
> customers requirements, and IMHO may not be sufficiently extensible to do so
> without the "playing field levelling" upgrade everyone is trying to avoid.


MPLS is deployed.  Hardware supporting ICMP echo response at wire rate
(or at worst rate limiting it) is deployed.  Avoiding waiting for
another spin of ASICs (or less so recoding and replacement of
forwarding microcode) is more than just a useful expediency for those
who have deployed MPLS and need a continuity test to better operate
their existing network.

I have no idea what "playing field levelling upgrade" you are talking
about.  Did some MPLS equipment fail to implement IP or ICMP?

Can you please elaborate on what "customers requirements" are not met.

Can you also explain whether the lack of flexibility is in the ICMP
echo request and response, where the sender gets back the variable
length it sent, or in the UDP LSP Ping response which is being defined
and is still sufficiently in flux to have no limitations whatsoever.

Curtis