The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <FFFC48AEAA5F7447929F4F0D93FCC12DAD074C@zcard031.ca.nortel.com>, "Da
vid Allan" writes:
> 
> 
> Folks:
> 
> A couple of thoughts....
> 
> 1) Seems on a pop and swap or pop and pop the TTL of both labels would be
> decremented (pipe mode) or both effectively would be decremented (uniform
> mode) as the outer would be decremented prior to copying to the inner. Only
> on PHP (pipe) would the inner label TTL not be decremented.
> 
> 2) For pop and pop (no PHP case) finding an explicit NULL should mean
> forward as an IP packet which means 127./8 address.
> 
> 3) For pop & go (PHP of inner label), the CE gets any inner label OAM
> traffic :-(
> 
> I have to admit I am not clear on what circumstances an Explicit NULL can be
> a top label and if we re breaking somthing if we insist that PEs terminate
> anything with an Explicit NULL....
> 
> cheers
> Dave


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


> > -----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
> > 
> > 
>