The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <5.1.0.14.2.20021220093351.01fa5c28@mailhost.avici.com>, Alia Atlas 
writes:
> 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 b
> y
> > > 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


We then have to insist that in forwarding, an implementation look
beneath the VPN label if the S bit is not set and deliver locally if
the next label is an explicit null.

If the VPN label is not included many ECMP for LDP implementations at
midpoint will not use the same path for the test traffic (hash based
on lower labels only) and the test traffic will not take the same path
as the VPN traffic which is intended to be tested.

Curtis