Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

From: Ping Pan <[email-masked]>
Date: Tue, 17 Jul 2001 14:19:52 -0700

"Punj, Arun" wrote:
> 
> >
> > What prevents a packet with a router alert flag set from
> > being sent over an
> > LSP?  I don't recall anything in the specs that specifies
> > router alter packets
> > can't be LSP'd.
> 
> > Eric Rosen wrote:
> >
> > > George> The mechanism is  intentionally tied to the control
> >  plane to ensure
> > > George> that the source  is properly informed even if  the
> > reverse data path
> > > George> may be broken.
> > >
> > > If  the reply is  encapsulated in  a UDP  packet which  is
> > addressed  to the
> > > tunnel head and has router alert  set, isn't this just as
> > effective, without
> > > the dependence on the control plane?
> >
> 
> Interesting.. Should it not be in the spec? If not, than
> are you not changing the meaning of router alert. If yes,
> Eric's solution seems perfectly OK, although it would
> require some sort of additional support on the intermediate
> nodes.
> 

Arun,

In fact, this idea of using IP Router Alert option had been discussed
extensively before the submission of the LSP-ping draft. 

The problem with this approach is: there is no guarantee that the
returning path (with or without IP Router Alert) won't go over an LSP.
If that LSP is bad, we are in trouble.

> Presumably router alert is the reason why the RSVP messages
> are finding the way back in reverse direction!!
> 

No. RSVP messages find the way back in reverse based on PHOP installed
at each LSR by RSVP Path, and has nothing to do with IP Router Alert.

- Ping

---

From: David Charlap <[email-masked]>
Date: Tue, 17 Jul 2001 19:46:02 -0400

Punj, Arun wrote:
> Matt Squire wrote:
>>
>> What prevents a packet with a router alert flag set from being
>> sent over an LSP?  I don't recall anything in the specs that
>> specifies router alter packets can't be LSP'd.
> 
> Interesting.. Should it not be in the spec? If not, than are you
> not changing the meaning of router alert. If yes, Eric's solution
> seems perfectly OK, although it would require some sort of
> additional support on the intermediate nodes.

Logically, it would not make sense to forward a router-alerted packet
into an LSP.

The purpose of router alert is so that intermediate nodes will closely
examine the packet, and possibly intercept it for processing.  The
purpose of an LSP is to quickly forward a packet with a minimum of
processing by the transit routers.  These are two diametrically opposed
goals.

Nevertheless, I don't think there is anything forbidding a router from
sending a router-alert packet into an LSP.

> are finding the way back in reverse direction!!

RSVP Resv messages are targetted at the PHOP router, so even if they
would be sent into an LSP, they'd still arrive at the same place.

Forward-going messages (Path, PathTear, ResvErr and ResvConf) are sent
with router alert and have the egress router's address in the IP
header.  In theory, they could be forwarded into an LSP, but any router
doing this wouldn't be able to process the messages and would therefore
not be a useful participant in the signaling process.  (Unless that LSP
terminates at the next-hop router.)

-- David

---

From: Alia Atlas <[email-masked]>
Date: Tue, 17 Jul 2001 19:51:49 -0500

>terminates at the next-hop router.)

It can actually be useful if you want two LSRs connected by an LSP to be
logical neighbors.  
This comes up if one is using heirarchical tunnels.  For instance, consider
how you would signal a backup LSP through a bypass tunnel, if the merge
node's label weren't recorded...

Alia

---

From: Matt Squire <[email-masked]>
Date: Tue, 17 Jul 2001 19:58:11 -0400

> sending a router-alert packet into an LSP.

LSPs can be used to provide L2 VPN connectivity.  LSPs can be used to
provide virtual p2p connections between two virtual routers.  LSRs might
not even be L3 forwarders.  When used in such ways, it is conceivable
and probably desired that router alert messages be sent down LSP as the
LSP is not spanning multiple L3 routers from the perspective of the
ingress - the LSP is just a single hop.  

Strictly outlawing router alert messages from LSPs would not be a
desirable end goal.

- Matt

---

From: "Punj, Arun" <[email-masked]>
Date: Tue, 17 Jul 2001 17:07:35 -0400

Eric and Matt, 

> -----Original Message-----
> From: Matt Squire [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 11:28 AM
> To: [email-masked]
> Cc: George Swallow; Ron Bonica; mpls-list
> Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
> 
> 
> 

However, either way, this technique seems to be a hack. The 
right solution is to implement the complete OAM functionaliy
as Neil as pointed out.

Arun Punj
Office of CTO, Marconi Networks,
Ph  : 724-742-7583 - Web: www.marconi.com
1000 Fore Drive, Warrandale, PA - 15086

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Jul 2001 09:51:15 -0400

Ping> The problem with this approach is: there is no guarantee that the
Ping> returning path (with or without IP Router Alert) won't go over an LSP.
Ping> If that LSP is bad, we are in trouble.

Since tunnels can be nested, isn't is possible that in a traffic engineered
path <R1,  R2, R3,  ..., Rn>,  R2 and R3,  say, are  IGP adjacencies  over a
virtual interface that  is actually a pair  of LSPs (one from R2  to R3, one
from R3 to R2)?  In such a  case there is no guarantee that the control path
(forward and reverse) does not include an LSP.

---

From: Sanjay Wadhwa <[email-masked]>
Date: Wed, 18 Jul 2001 07:54:02 -0700 (PDT)

> (forward and reverse) does not include an LSP. 

Sure. But if the reverse LSP (virtual interface) is  broken (say due to
corrupted label maps along the way), then even the RESVs for the inner
LSPs don't make it through, and soon enough the inner LSP will be torn
down (So making echo-response live and die with rsvp resv actually will
work fine with nested tunnels irrespective of RESV using a reverse LSP
or native ip in the reverse direction).

-Sanjay

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---

From: Eric Gray <[email-masked]>
Date: Wed, 18 Jul 2001 10:53:40 -0400

Eric,

    Yes, but there are other means to determine if there is a
problem with the control path.

--
Eric Gray

---

From: Eric Rosen <[email-masked]>
Date: Thu, 19 Jul 2001 11:02:19 -0400

Sanjay> if  the  reverse LSP  (virtual  interface)  is  broken (say  due  to
Sanjay> corrupted label  maps along  the way), then  even the RESVs  for the
Sanjay> inner LSPs don't make it through, and soon enough the inner LSP will
Sanjay> be torn  down (So making echo-response  live and die  with rsvp resv
Sanjay> actually  will work fine  with nested  tunnels irrespective  of RESV
Sanjay> using a reverse LSP or native ip in the reverse direction).

Excellent point. 

So then  I think then the base  requirement for the routing  of the response
from the  egress is that it  be reverse-path-forwarded back  to the ingress,
i.e., that it follow the path of label distribution from egress to ingress.

---

From: Ravi Shekhar <[email-masked]>
Date: Thu, 19 Jul 2001 17:34:11 -0700 (PDT)

> i.e., that it follow the path of label distribution from egress to ingress. 

  That seems to be the right way to me. One possible way to achieve this is 
  as a 4 step process - first 2 to gather the hop-by-hop path from ingress to
  egress node and the next 2 to do the ping on LSP:

   1) Initiate a UDP packet at ingress and send it to the next hop for the LSP to
      be traced (i.e. destination IP address is the address of the next hop for 
      LSP and not the egress address itself).
      Have enough information (like ingress router/egress router address/label) 
      in the UDP packet to uniquely identify the LSP.
      Every hop(including ingress/egress) on the way appends its hop information 
      and sends this packet to the next hop of the LSP.
   2) When this UDP packet reaches egress, egress sends it back to the ingress 
      hop-by-hop in the reverse order of the way path was traced(and recorded in
      the packet) in step 1. Sending it this way ensures that it reaches the
      ingress.
   3) At this point ingress has the elaborated hop-by-hop path for the LSP from
      ingress to egress. It now generates a UDP packet at ingress with the
      destination address of the egress. Since the UDP packet's destination is
      egress node, it should traverse the LSP now. Inside the UDP packet fill in
      the path that was traced in step 1 (and received by ingress in step 2). 
   4) If egress receives the UDP packet sent in step 3 via LSP, it can use the
      hop-by-hop information contained in the packet and send a response back 
      hop-by-hop to the ingress (the same way it sent it back in step 2).

   This should work independent of the protocol that sets up the LSP (and across
   multiple protocols). Since a unique return path for response is already
   recorded while traversing in the forward direction of LSP (i.e. from ingress
   to egress) in step 1, it would work for LDP too where same label might have
   been handed over to multiple upstreams.

   Some other useful information can also be gathered. Like protocol that set up
   the LSP on each hop interface / timestamp and number-of-packets-forwarded-on
   -the-LSP in steps 2 and 4 to calculate the rate of forwarding on LSP etc. 
   
   Maximum number of hops to be traced can be specified by the ingress (and
   decremented at each hop) to prevent looping of message in step 1 forever.
   Indication of failure of LSP or reaching maximum number of hops at any hop 
   can be put in the UDP packet and sent back to ingress in step 2.
 
   - Ravi Shekhar.

---

From: Ping Pan <[email-masked]>
Date: Thu, 19 Jul 2001 18:15:14 -0700

Ravi,

This is one of the many solutions we had talked about before. See below.

>       the packet) in step 1. Sending it this way ensures that it reaches the

In RSVP-TE, this is the RRO object. For RSVP, you can even skip this two
steps.

>    been handed over to multiple upstreams.

Yep! This is all nice, but it is *not* backward compatible. In a network
that has many routers, if one of them does not support this, the test
will fail.

Also this is a self supply-demand condition: with one implementation bug
on one of the LSR's, a whole bunch of LSP's may get torn down. So your
approach is best to debug own bugs. :-)

See, the LSP-ping proposal works, because it is based on the assumption:
the only working path from egress to ingress is the control path itself.
It is simple (no extra signaling other than adding one object) and
backward compatible (no change to the network LSR's).

- Ping

---

From: Ravi Shekhar <[email-masked]>
Date: Fri, 20 Jul 2001 09:03:40 -0700 (PDT)

Ping,
> In RSVP-TE, this is the RRO object. For RSVP, you can even skip this two

  Thats true, but I am not assuming that an LSP is signalled just using RSVP.
  It will work for CR-LDP, LDP which might distribute same label to multiple
  upstreams or any LSP setup using mix of these protocols. (I think one of 
  your mail asked to suggest something which will work for LDP). Infact it 
  will work for multicast(point-to-multipoint) LSPs too.

> approach is best to debug own bugs. :-)

  Isnt that goodness..;-).. LSP and LSP ping assist each other in 
  finding bugs. 
  Anyhow, you could say the same thing for traceroute. If ICMP is
  not implemented correctly on one of the intermediate hops, it wont work.
  Infact, this argument will completely shoot down multicast traceroute
  where state is appended on each intermedidate router. And I bet 
  implementations of LSP ping as you suggest wont be bug immune either..;)..

> backward compatible (no change to the network LSR's).

  If by backward compatible you mean that intermediate LSRs do not have 
  to implement LSP-ping, then I agree. 
  But is that really such a big win in the long run? If we are tracing LSP to an
  LSR(which could be one of these inetwork LSRs) and if we dont recieve a
  response from it, it could either be because LSP is down or the LSR does not
  implement LSP-ping. How do you know to distinguish between these two?
  And if you cant, then indirectly it implies that LSP-ping be implemented
  on all such routers and I think practically thats what will end up happening.
  Whichever ping mechanism is used, we will end up having to support it on all 
  the routers.  

  - Ravi Shekhar.

---

From: Ping Pan <[email-masked]>
Date: Fri, 20 Jul 2001 09:39:45 -0700

Ravi,

>   to implement LSP-ping, then I agree.

Yes.

>   But is that really such a big win in the long run? 

Yes.

> If we are tracing LSP to an
>   implement LSP-ping.

In the draft, it said, "... Before initiating the liveliness test, the
user must make sure that both ingress and egress LSR can support the
LSR-ping."

>  How do you know to distinguish between these two?

Now you start to scare me. :-) This is up to the network operators. 

- Ping

---

From: Ravi Shekhar <[email-masked]>
Date: Fri, 20 Jul 2001 10:01:38 -0700 (PDT)

Ping,

> >   But is that really such a big win in the long run? 

  Why?

> user must make sure that both ingress and egress LSR can support the

  I read that and it doesnt seem to be a very valid assumption.

> Now you start to scare me. :-) 

  Mission accomplished..;)..

  - Ravi Shekhar.

---

From: Sanjay Wadhwa <[email-masked]>
Date: Fri, 20 Jul 2001 10:51:41 -0700 (PDT)

It is hard to disagress that a signalling independent solution in the
long run is a good thing. draft-pan-lsp-ping-00.txt is a simple,
backward compatible solution that will work currently for an RSVP-TE
core. I think as a solution for RSVP-TE it has merits by virtue of it's
simplicity and ease of deployment.

Thinking about the following "generic" solution (which looks to be
built upon various suggestions by various folks on the list) in context
of an LSP setup using LDP :

This four step process has a substantial window between the time the
forward path is discovered by the ingress and egress and it is actually

used for the echo-response in the reverse direction. During this time
routing could have changed and the forward LSP could be taking a
different path. So, the step 4 is not as simple as sending the response
hop-by-hop exactly according to the path information contained in the
echo-response. A next-hop indicated there could now no longer directly
attached to the intermediate node due to a routing change. What do you
do in this case ? Do a routing lookup towards that hop. But then you
are back to relying on unicast routing in the reverse direction as
opposed to exactly using the forward path used by the forward LSP, and
I think this is something we want to avoid in the first place. 
Also, with un-converged routing step 4 could result in a loop which
would cause the echo-response to be dropped. And the ingress could
mistakenly then take down a valid LSP.

With rsvp loose hops or non-rsvp cloud or nested tunnels a similar
situation can arise. But there tying it's fate to the RESV is the key.

Cheers..
-Sanjay

---

From: Ravi Shekhar <[email-masked]>
Date: Fri, 20 Jul 2001 11:34:58 -0700 (PDT)

> mistakenly then take down a valid LSP.

  If the succesive hops are not reachable to each other, the signalling 
  protocol running between them to set up that LSP will bring down the LSP 
  soon to.
 
  In any case, idea is to use it more as a debugging tool than a liveness testing
  tool to bring down an LSP. Even if one desires to bring down the LSP based on
  this, probably its a good idea to do multiple such pings to take care of 
  transient conditions before declaring that LSP is down. For instance, if the
  hop-by-hop path in first 2 steps turn out to be different for two such
  successive pings, its a clear indication that transient conditions exist. 
  Note that even traceroute could give wrong result if transient routing
  conditions exist.

  Regards.

  - Ravi Shekhar.

---

From: Sanjay Wadhwa <[email-masked]>
Date: Fri, 20 Jul 2001 11:48:15 -0700 (PDT)

>   protocol running between them to set up that LSP will bring down

Those successive hops are not in the current (latest) forward path
being used by the LSP in question. That was the crux of the point
above.

>   tool to bring down an LSP. 

Ok. That is worth clarifying then.

-Sanjay

---

From: Eric Rosen <[email-masked]>
Date: Mon, 23 Jul 2001 12:34:10 -0400

Having now been convinced of the  need to have the echo response travel back
along the path  of label distribution, piggybacking it  on the control plane
messages  does  seem  to  make  sense.   The alternative  is  to  devise  an
independent transport  method which follows the control  plane reverse path.
This  is probably  more complicated,  given that  we have  only  two control
planes.

So here's my  off-the-cuff suggestion for doing the same  kind of thing with
LDP.  

The LSP-ping message  should be able to carry an  echo object which contains
(a) an  identifier of  the ingress,  and (b) an  LDP FEC  TLV.  (And  also a
sequence number,  I think, to aid  in matching responses  to requests.)  The
LDP FEC  TLV is the one  corresponding to the  LSP on which the  LSP-ping is
being sent.

When the LSP-ping message reaches  the egress, the echo object is extracted,
and given to LDP to be treated as an attribute (TLV) of the FEC it contains.
The egress then  sends a label mapping message for  that FEC, containing the
echo object.  This should  be sent to each LDP peer to  which the egress has
previously distributed  a label  (most likely the  implicit NULL  label) for
that FEC.  The egress then forgets about the response TLV.

When a  label mapping  message for  a particular FEC  is received,  and that
message contains an echo response TLV, then:

- if the  mapping message is not  from the next  hop for that FEC,  the echo
  response TLV is ignored;

- if the mapping message IS from the next hop for that FEC, 

  * if the  LSR is not the ingress  node identified in the  echo object, the
    LSR  sends a label  mapping message  for that  FEC, containing  the echo
    object, to each LDP peer to  which it has previously distributed a label
    for that FEC  (except the one from which it  received this message); the
    LSR then forgets about the TLV. 

  * if the LSR is the ingress node identified in the echo object, it matches
    the echo object  up to a particular LSP-ping and  treats the LSP-ping as
    having been properly responded to.

This procedure  is little different than  the procedure used to  pass up the
MTU or path vector TLVs upstream.   As in the RSVP-TE scheme, if the control
plane is operating properly, the TLV will make it upstream properly. 

This works  fine in the  multipoint-to-point case, at  least as long  as one
isn't pinging an egress from several  ingresses at once.  To handle the case
where there  are multiple outstanding  pings (from different  ingresses), we
either need to allow multiple echo  TLVs in a mapping message, or perhaps we
only need to define which of several  echo TLVs is the one which gets passed
upstream.