The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Last call on LSP Ping
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 > >
|
|