The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Dec> msg00371



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

Last call on LSP Ping

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Fri, 20 Dec 2002 14:09:04 -0500
  • Cc: Alia Atlas <aatlas@avici.com>, curtis@fictitious.org, Shahram Davari <Shahram_Davari@pmc-sierra.com>, "'Kireeti Kompella'" <kireeti@juniper.net>, "'mpls@UU.NET'" <mpls@UU.NET>



Hi Curtis:

<snipped>

> Dave,
> 
> You seem to be assuming ommision of the VPN label.

????????
 
> The problem does not occur for:
> 
>   1.  Uniform mode.  (Outer label TTL expires).
> 
>   2.  Pipe mode with PHP.  (Outer label removed, VPN TTL expires).
> 
>   3.  Pipe mode without PHP for routers that support the ability to
>       look for a label below the VPN label (newly specified).
> 
> The problem does occur when
> 
>   Pipe mode is used AND PHP is not used AND the router does not
>   support the ability to look under the VPN label.
> 
> Since we are talking about a practical problem, specifying a change in
> forwarding, lets look at a significant chunk of the deplyed base of
> core routers:
> 
>   Cisco - does PHP as egress.
>   Juniper - does PHP as egress.
>   Avici - does not request PHP but can support the ability to look
>     under the VPN label without hardware change.  Even if not, PHP
>     can be enabled by configuration.
> 
> Someone from Cisco or Juniper can object if this won't work with their
> routers.
> 
> If there are any other deployed routers that can't request PHP via
> implicit null and process it as an egress, and cannot modify
> forwarding to look under the VPN label if another label exists, then
> someone needs to speak up.  Otherwise it is a hypothetical problem for
> which there is no known instance and we can move forward.
> 
> Curtis

If I understand the problem statement correctly, it was how do you test the
inner label in a PW or VPN application. Currently as written in the document
it is via testing the outer label with an FEC stack (proxy test) on the
assumption that a probe under the inner label MAY NOT be visible to the
egress PE. I can also try to force visibility by setting the inner label TTL
to 1 which assumes pipe mode at the PHP LSR. Uniform model at the egress and
all bets are off as the VPN label TTL will be overwritten by the PSN label
TTL value. 

TTL exhaustion for ping mode is potentially undesirable as theoretically
ICMP TTL exhaust messages are a byproduct. I got the impression that testing
the inner label was primarily via testing the outer label with a FEC stack.
Looks simpler than some of the other implications (what is the address of
the inner label ping origin..?)

Dave