The MPLS WG Archive

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



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Last call on LSP Ping

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Wed, 18 Dec 2002 18:28:23 -0500
  • cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, Kireeti Kompella <kireeti@juniper.net>, "Gray, Eric" <egray@celoxnetworks.com>, mpls@UU.NET


In message <4B6D09F3B826D411A67300D0B706EFDEB03BBD@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> Curtis,
> 
> 
> 
> > > > My interpretation is push both labels.  Both start at TTL=1.
> > > > Increment top, then next label.  If they both terminate 
> > at the same
> > > > egress LSR (normal for BGP VPN) then bottom TTL never gets past 1.
> > > 
> > > What do you do for pinging the inner LSP?
> > 
> > For ping mode, set all the labels that you want tested to TTL=255 and
> > send.  If there are any hops after the top, the packet gets delivered
> > to the egress of the label you want tested.
> > 
> > Did you mean traceroute?
> 
> 
> No I meant ping. But I am not satisfied with your answer. Let's assume
> we have a PWE3 connection, and the user packets are sent with 2 labels (A & B
> ).
> Label A is the PW label and label B is the transport label. The egress LSR ch
> ecks the transport label and terminates it and forwards the packet based on t
> he
> PW label. It never checks the S-bit. If LSP-ping has the same label stack (A&
> B)
> then the LSP-ping will be delivered to the customer. Don't you think so?

That would happen and it would not be a good thing.  For a VPN the
customer would get a null label packet with MPLS ping payload.  For
PW, there would be junk and a framing error at some level.

>  If the LSR at TTL=4 swaps label X for Y it
> > puts Y in the Downstream Mapping TLV in the echo reply.  T
> 
> Here is my point. How do you put the Downstream mapping TLV in the
> RESV message if the return path is via control-plane?

Good point.  You can't.  For some reason I thought there was a place
for TLVs in this object.

Looks like you can just confirm that the packet reached a router at
TTL=x and how long it took.  My guess on why this is so is the RSVP
object size is too limited to carry a full set of MPLS-ping TLVs.

The more I look at "reply via the control plane", the less useful it
looks.

Perhaps one of the authors can tell us why we can't just drop it.

> -Shahram

Curtis