The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Curtis,

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


Seems you are assuming only trace-route


> 
> The problem does not occur for:
> 
>   1.  Uniform mode.  (Outer label TTL expires).

True for trace-route, not true for ping.

> 
>   2.  Pipe mode with PHP.  (Outer label removed, VPN TTL expires).

No it doesn't. The packet arrives with VPN label, which has TTL=1 to the egress
LSR. The egress LSR should accept this packet and forward it if possible. Remember
RFC1812 says:

"
   A router MUST NOT discard a datagram just because it was received
   with TTL equal to zero or one; if it is to the router and otherwise
   valid, the router MUST attempt to receive it. "

So the packet received would be accepted and a lookup of the VPN label
results forwarding the payload to the Customer.

> 
>   3.  Pipe mode without PHP for routers that support the ability to
>       look for a label below the VPN label (newly specified).

I think you mean for those that can check the S-bit and make decision based
on S-bit. But I think you are fundamentally changing the standard MPLS behavior.
Now the forwarding table is based on not only on MPLS label (VPN label) but also
on S-bit. While the standard MPLS forwarding does not S-bit for forwarding decision, rather only as a PID for encapsulated packet.

Yours,
-Shahram

> 
> 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
> 
> 
> > > -----Original Message-----
> > > From: Alia Atlas [mailto:aatlas@avici.com]
> > > Sent: Friday, December 20, 2002 9:36 AM
> > > To: curtis@fictitious.org
> > > Cc: Shahram Davari; 'curtis@fictitious.org'; 'Kireeti Kompella';
> > > 'mpls@UU.NET'
> > > Subject: Re: Last call on LSP Ping 
> > > 
> > > 
> > > At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote:
> > > > > 1) Use explicit null label even though the traffic is IP, 
> > > and detect 
> > > > LSP-ping
> > > > > packets from S=0 in the VPN label. This may require HW 
> > > change, because 
> > > > curren
> > > > > t implementations don't look at S-bit.
> > > > >
> > > > > 2) Only push the PSN label, and encode the VPN  label in 
> > > the echo-request.
> > > > >
> > > > > 3) In echo-request set the TTL=0 for VPN label, and 
> > > detect the LSP-ping by
> > > > > sending the TTL=0 packets to the OAM module. This may 
> > > also require HW 
> > > > change
> > > > > as I am not sure current implementations check the TTL of 
> > > the VPN label.
> > > > >
> > > > > My suggestion was the 2nd one. What method do you suggest?
> > > > >
> > > > > Thanks,
> > > > > -Shahram
> > > >
> > > >
> > > >I was suggesting you set TTL=1 on the VPN label and include an
> > > >explicit null label, also with TTL=1.  Others can speak up if the
> > > >change will be a problem.
> > > 
> > > Currently the incoming TTL, which I believe is that checked 
> > > for the TTL 
> > > expiring, is based upon the top incoming label.  I.e., if the 
> > > PSN label is 
> > > still on the packet when it reaches the egress, then its TTL 
> > > would be used, 
> > > rather than the TTL of the VPN label underneath.  Of course, 
> > > if the PSN 
> > > label is not there, because of PHP, then the incoming TTL 
> > > would be that of 
> > > the VPN label, and this could work - but that requires PHP :-(.
> > > 
> > > Alia
> > > 
> > > 
> > 
>