The MPLS WG Archive

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



[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 11:50:07 -0500
  • Cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>, "'curtis@fictitious.org'" <curtis@fictitious.org>, "'Kireeti Kompella'" <kireeti@juniper.net>, "'mpls@UU.NET'" <mpls@UU.NET>



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

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