Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt

From: Shahram Davari <[email-masked]>
Date: Fri, 13 Jul 2001 07:54:20 -0700

HI Eric,

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 10:40 AM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> 
> 
> Shahram,
> 
>     A non-IP LSP would presumably use a non-IP/ICMP based
> path integrity check, wouldn't it?

But there is no method for non-IP LSPs. So isn't it better
to have a more general Ping which also applies to those LSPs?

>  Also, such an LSP would be
> established (most likely) using an explicit route mechanism -
> which would tend to ensure that the end-points would know of
> the path integrity (or lack thereof) via signaling behavior.
> 

As I presented in the Last IETF, the RSVP-TE/CR-LDP may take a different
path than the actual user-plane data, because they are hop-by-hop routed.

-Shahram

> --
> Eric Gray
> 
> You wrote:
> 
> > Hi All,
> >
> > How can the LSP-Ping work if the LSP is setup to carry 
> non-IP traffic?
> >
> > In an egress LSR there is a binding between an LSP and the 
> L3 protocol that it is supposed to carry. If anything other 
> than IP is carried in an LSP, and we inject ping packets in 
> to that LSP, the egress LSR has no means of parsing that 
> packet. How is this addressed in this draft?
> >
> > Yours,
> > -Shahram
>

---

From: [email-masked]
Date: Sat, 14 Jul 2001 06:43:59 +0100

Ping Pan wrote 14 July 2001 01:05
> L3 protocol that it is supposed to carry.
> > If anything other than IP is carried in an LSP, and we 
> inject ping packets in to that LSP, the egress 
> > LSR has no means of parsing that packet. How is this 
> addressed in this draft?
> > 
> 
> Shahram,
> 
> If the LSP (IP or non-IP) is initiated via RSVP-TE, then
> draft-pan-lsp-ping-00.txt can be used to check the LSP. In this case,
> the egress can parse the echo-requests. You are right, it 
> won't work in
> a non-IP network.
> 
> - Ping
NH=> Ping......You do realise that what you are saying here is effectively
the same as 'Layer X is only allowed to carry layer Y clients and nothing
else'.  If our industry had allowed this expedient way of doing things from
the outset please consider just what a mess we would be in now.  It would
lead to multiple overlay server layer networks for each client layer
network, with serious inflexibility/inefficiency of usage, and major
interworking and evolution problems (since layer networks and protocols
could not be added/developed/removed largely independently).

It is my opinion that the expedient advantage you are seeking to achieve
with this solution will be at a higher downstream cost to our industry, and
I don't see it as healthy for the development of MPLS per se.

I really think we ought to get some basic architectural ground rules in
place....and the obvious ones here are:
-	the data-plane of a given layer network in technology X SHOULD not
be expected to rely on the OAM of the data-plane of any client or server
networks for its defect handling;
-	the OAM of the data-plane of a given layer network which carries
(external) customer traffic SHOULD be decoupled from the (internal)
data-plane of the network control-plane (and the protocols used thereon);

I would not want to stop you doing what you are proposing, but I think that
any proposals which break such basic architectural rules should be clearly
marked as proprietary and not put on any standards track.

regards, Neil

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 06:45:45 -0700

Hi Eric,

> Sent: Monday, July 16, 2001 4:20 PM
> To: Shahram Davari
> Cc: 'Ping Pan'; 'Yakov Rekhter'; [email-masked]'
>     It's one thing to use ping to check the integrity of a link,
> and quite another to use it as an 'alive' protocol.  Isn't there
> a better approach than this?
> 

It seems that this draft is suggesting the same thing; to use ICMP-ping as "alive" protocol!

-Shahram

> > Hi Eric,
> > > Sent: Monday, July 16, 2001 3:55 PM
> > > To: Shahram Davari
> > > Cc: 'Ping Pan'; 'Yakov Rekhter'; [email-masked]'
> > >     I was just talking to someone (off-line) about something
> > > that is obliquely related to this.
> > >
> > >     Your suggestion will not work because the ping in the reverse
> > > direction traverses an equally long LSP with (presumably) an
> > > equal probability of a return path failure.
> >
> > But I don't care about return path failure of the reverse 
> LSP, because
> > in the method that I suggested, the ingress LSR checks to 
> see whether
> > it is receiving the ICMP (not ECHO) messages over the 
> reverse LSP periodically,
> > and if it is, it means that the reverse LSP is fine.
> >
> > Example:
> >
> >  /---E----\
> > A----B----C
> >  \---D----/
> >
> > Ingress LSR: A
> > Egress LSR: C
> > Forward LSP: ABC
> > Reverse LSP: CDA
> > Return of the reverse LSP: AEC
> >
> > 1)LSR A sends ICMP over ABC, and the ICMP Echo comes back 
> through CDA
> > 2)LSR B sends ICMP over CDA, and the ICMP Echo comes back 
> through AEC
> > 3)LSR A checks to see whether it is receiving any ICMP from 
> C, regardless
> > of the status of the return LSP of the reverse LSP (i.e. AEC)
> > 4)If so Any failure to receive ICMP Echo from C for LSP=ABC 
> is due to
> > reverse path (CDA) failure.
> >
> > Yours,
> > -Shahram
> >
> >   Therefore, there is an
> > > issue with non-terminating recursion in LSP integrity checking.
> > >
> > >     If you could reduce the length of the LSP by at least one hop
> > > in each successive recursion, the recursion would terminate.  I
> > > think this is may be the under-lying advantage to the approach
> > > suggested earlier by Eric Rosen: if you send a ping response
> > > using UDP, the integrity 'recursion' is terminating as long as
> > > the UDP packet does not immediately (as in at the output port
> > > of the responder) get injected into an LSP.  Even if the UDP
> > > packet is subsequently injected inbto an LSP that terminates
> > > at the original ping sender, this LSP is going to contain 
> (at least
> > > one) fewer hops than the LSP being verified by the original ping
> > > - and this LSP's integrity is presumably testable by a similar
> > > means.
> > >
> > >     Admittedly, there is the pathological case in which 
> each return
> > > LSP is at least as long as the LSP being verified - but this seems
> > > like an extreme exception and brings the alleged integrity of the
> > > control plane into serious doubt as well. So, if you assume that
> > > each LSP integrity checking 'ping' response starts out as a plane
> > > old UDP message that might be injected subsequently into a
> > > 'shorter' LSP, the integrity checking recursion will terminate and
> > > the ultimate integrity of the original LSP can be verified.
> > >
> > > --
> > > Eric Gray
> > >
> > > You wrote:
> > >
> > > > Ping,
> > > >
> > > > Thanks for your reply. I have a fundamental question:
> > > >
> > > > If all you are looking for is whether the reverse path is
> > > functional or not why not do the following:
> > > >
> > > > By running periodic ICMP pings over the reverse path, the
> > > ingress LSR could find whether the reverse path is functional
> > > or not. This can be done by the ingress LSR checking whether
> > > it is receiving reverse' path ICMP pings regularly that have
> > > source addresses equal to the destination address of the
> > > forwarding path ICMP Ping. And therefore can find whether a
> > > failed ICMP ping over the forwarding path is due to
> > > forwarding path failure or reverse path failure.
> > > >
> > > > What is wrong with this approach as compared to LSP-ping.
> > > >
> > > > -Shahram
> > > >
> > > > > From: Ping Pan [mailto:[email-masked]]
> > > > > Sent: Monday, July 16, 2001 12:23 PM
> > > > > To: Shahram Davari
> > > > > Cc: 'Yakov Rekhter'; [email-masked]'
> > > > > Shahram Davari wrote:
> > > > > > Hi Yakov,
> > > > > > Good suggestion. However, I think due to periodic
> > > > > transmission of ping packets, and due
> > > > > > to possibility of many LSPs being pinged at the same time,
> > > > > the processing overhead of UDP/IP
> > > > > > is large and may limit the scalability.
> > > > >
> > > > > Shahram,
> > > > >
> > > > > That's why we choose a two-step ping: ICMP ping's 
> followed by LSP
> > > > > ping's. Normally, the ingress sends the regular ICMP
> > > ping's to check
> > > > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping
> > > > > messages are
> > > > > sent to detect if the failure is on the forwarding or the
> > > reverse LSP.
> > > > > The reason for using UDP is to allow the egress LSR's to
> > > regulate the
> > > > > LSP-ping traffic.... Don't think there is a scalability
> > > problem here.
> > > > >
> > > > > > Using another reserved label for Ping
> > > > > > (or OAM packets in general) could eliminate the use of
> > > > > UDP/IP and could reduce the processing burden at
> > > > > > the egress LSR.
> > > > > >
> > > > >
> > > > > How? At egress, ping packets need to be processed anyway. You
> > > > > still have
> > > > > to somehow limit the amount of probing traffic.
> > > > >
> > > > > BTW, I will add the idea of using Explicit IPv4 NULL for
> > > > > non-IP traffic
> > > > > in the next version.
> > > > >
> > > > > - Ping
> > > > >
> > >
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 10:10:11 -0700

Hi,

> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 11:51 AM
> To: Shahram Davari
> Cc: 'Yakov Rekhter'; Dave Cooper; [email-masked]'
> As Thomas just said for failure of control plane we will use RSVP Tear
> msgs (case of unprotected lsp by frr) so the head will know 
> immediately
> of the failure.

How? if the RESV path has failed how do you detect that and how do you send the
Tear message?

> 
> > the RESV messages with refresh interval "T". Then we run 
> ICMP-ping messages 
> > until we don't receive ICMP-Echo back.
> 
> In your description I don't see why waiting for reception of next rsvp
> resv msg is required for triggering the ICMP test in the first place.
> 
> R.
> 
> > Shahram Davari wrote:
> > 
> > Hi,
> > 
> > > From: Robert Raszuk [mailto:[email-masked]]
> > > Sent: Tuesday, July 17, 2001 11:04 AM
> > > To: Shahram Davari
> > > Cc: 'Yakov Rekhter'; Dave Cooper; [email-masked]'
> > > > > If you don't receive any LSP-ECHO then you may conclude
> > > that either
> > > > > the forward LSP is down, or the control channel used by RSVP
> > > > > (or to be more precise by RESV) to set up the LSP is down.
> > > > >
> > > >
> > > > Which is a useless information, because the whole point of
> > > the LSP-ping was to
> > > > find whether the fault is in forward LSP or not !
> > >
> > > Notice what the draft says:
> > >
> > >    In the case where an LSP has failed to deliver user
> > > traffic, and the
> > >    failure cannot be easily detected by the MPLS control 
> plane (and
> > >    specifically, RSVP-TE component),
> > >
> > > So we do assume that the RSVP-TE control plane is up and 
> running fine
> > > otherwise there would be no point of even sending icmp 
> msg over failed
> > > LSP.
> > 
> > So let me see if I understand this correctly. What you are 
> trying to say is that
> > first we select an LSP for connectivity test. Then we check 
> to see that we are receiving
> > the RESV messages with refresh interval "T". Then we run 
> ICMP-ping messages until we don't receive ICMP-Echo back. At 
> this time we wait for a period of "T" to see whether we 
> receive another RESV message or not. If we don't, this means 
> that the RESV path is down, otherwise the RESV path is fine 
> and we can now run LSP-ping. And if we don't receive LSP-Echo 
> back, this means that the forward LSP is down. Right?
> > 
> > If this is correct then you probably have noticed the delay 
> time "T" between detecting a failure and isolating it to the 
> forward LSP. My point was that this time interval may
> > be large specially when refresh reduction is used.
> > 
> > -Shahram
> > 
> > Having this in mind not receiving of LSP_ECHO in RSVP
> > > RESV msg IMHO
> > > clearly identifies the failure of forward LSP under test.
> > >
> > > R.
> > >
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 10:16:18 -0700

Hi Ping,

> Sent: Tuesday, July 17, 2001 12:30 PM
> To: Shahram Davari
> Cc: [email-masked]'; 'Yakov Rekhter'; Dave Cooper; [email-masked]'
> Why are you talking about the refresh interval here? Did we write a
> single word that defines the timing intervals in the draft? No!

No you haven't, but your method implicitly requires a waiting time
of "T" equal to the period of refresh RESV message, in order to work
correctly.

> to see that we are 
> > receiving the RESV messages with refresh interval "T". Then 
> we run ICMP-ping messages
> > until we don't receive ICMP-Echo back. At this time we wait 
> for a period of "T" to see 
> > whether we receive another RESV message or not. 
> 
> Maybe, maybe not. Another situation is to send the LSP-ping packets
> immediately while monitoring the LSP states.

If you do that, then what I explained in my previous emails will happen.
In which a failure to receive LSP-Echo can't be translated to a failure in
forward LSP, because it might be related to a failure in RESV path.

> 
> > If we don't, this means that the RESV path 
> > is down, otherwise the RESV path is fine and we can now run 
> LSP-ping. And if we don't 
> > receive LSP-Echo back, this means that the forward LSP is 
> down. Right?
> > 
> time "T" between detecting 
> > a failure and isolating it to the forward LSP. My point was 
> that this time interval may
> T is an independent parameter.

I know, but in order for you method to work you need to have a 
short refresh interval "T", which creates scalability issues.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 11:15:37 -0700

George,

> From: George Swallow [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 2:02 PM
> To: Shahram Davari
> Cc: 'George Swallow'; [email-masked]'; 'Yakov Rekhter'; 
> Dave Cooper;
> [email-masked]'; [email-masked]
> Shahram -
> > Sure. But I am talking about the time period before we start sending
> > LSP-ping and receiving LSP-Echo. I am talking about the time period
> > during which we are sending ICMP-ping and receiving ICMP-Echo. Since
> > ICMP-ping/Echo is not a trigger for refresh RESV, then during this
> > time interval you rely on the usual 30 sec/hop refresh. 
> Therefore if 
> > during this interval both the RESV path and reverse LSP fail, we
> > will notice a missing ICMP-Echo but we have no knowledge 
> that the RESV
> >  path has failed unless we wait for another refresh RESV 
> message or may
> >  be trigger an early RESV message (using methods other than 
> LSP-ping!!). Because
> > if we use LSP-ping to cause an early RESV message, and we 
> don't receive that
> > RESV message, then we won't know whether the failure was in 
> forward LSP
> > or in RESV path.
> 
> So your scenario is that the RSVP control plane and the reverse data
> plane fail at the same time?  And the control plane fails in a way
> that the headend is not notified quickly?  Is this a case worth
> worrying about?

Yes. Because it can happen easily when a line card that is shared by both
RESV path and reverse LSP fails at the egress LSR.

>  Yes the LSP-tunnel ping will fail.  The operator will
> get notified that there is a problem.  And he does indeed have a
> problem...having an alarm go off for the wrong reason is much better
> than no alarm.

I didn't suggest having no alarm, I suggested using another method that
does not have this problem.

> 
> And unless you're trying to do some form of non-stop forwarding over
> the failure of an intermediate node, then one can argue that you do
> have a problem with the LSP under test as well.

A failure of the control-plane is not equal to a failure of
data-plane and should not cause interruption of data-plane.

> 
> And if are doing some form of non-stop forwarding then the operations
> staff should be aware of it and know to look for problems in the
> control plane as well.

That is the job of control plane. Control plane should have its own
OAM.

-Shahram

> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>