Subject: LSP Liveliness

From: Nabil Seddigh <[email-masked]>
Date: Mon, 08 Jul 2002 12:12:15 -0400

I noticed that MPLS OAM is again on the agenda for the Yokohama 
meeting. I'm reposting certain issues and questions relating
to the LSP liveliness draft and hoping to hear from the authors
and others on the list.

1. Suggest finding a better name for this application than 
   "MPLS Ping". This is for two reasons. First, the app can 
   actually operate in both Ping and TraceRoute modes and
   2nd, vendors have icmp echo req and reply running over lsps
   and sometimes call that lsp ping which is easily confusable 
   with mpls ping. Maybe something like MPLS liveliness or
   another new term would solve this problem? 

2. Why not consider adding a reply mode of ICMP. 

3. Why not consider adding a reply mode of bi-directional lsp?
   i.e for the case of bi-dir lsps, why not try to return 
   the pkt on the bi-dir lsp. 

4. If implementing #3 above, suggest returning the labels
   in the reverse path of the bi-directional LSP.

5. Suggest changing section 3's packet format for the 
   echo request as follows:

   a) Include an additional 32 bit field called the "identifier 
      field" - this is the same as in ICMP ECHO REQUEST.
      This allows differentiation for the case of multiple
      processes. The source port is often used for this but
      this is only 16 bits while process ids in many OSs are 
      32bits. Having a separate clear identifier field 
      removes the ambiguity associated with this.
  
6. Section 5 is essentially the content of v02 of the draft.
   In that version there was a paragraph or two that 
   explained that there have been previously identified cases
   where the control plane of an LSP was up (ie PATH and RESV
   messages were continually refreshed) while packets on the 
   dataplane for that lsp went into a black-hole. It is for
   precisely this kind of scenario that section 5 is able
   to provide a solution. I think that such kind of content
   would be useful to include in this section again.

Best,
Nabil Seddigh
[email-masked]

---

From: Ping Pan <[email-masked]>
Date: Mon, 08 Jul 2002 10:21:43 -0700

Hi,

>    another new term would solve this problem? 

The draft defines the concept and the protocol that are used for LSP 
monitoring, probing... etc. Depending on the implementation, we could 
have some commands such as lsping() and tracelsp(), etc. I don't think 
we should hang up on the naming here. :-)

> 2. Why not consider adding a reply mode of ICMP. 

Indeed, there is more than one way to transport requests and replies. We 
chosen UDP long time back based on our unfortunate experience in 'ICMP 
extension on MPLS'. As a result, IANA had assigned port number 3503 to 
us (http://www.iana.org/assignments/port-numbers).

Actually, using UDP may be easier to implement.

>    the pkt on the bi-dir lsp. 

There are multiple ways to reply the messages as being defined in the 
draft. One simple way is to reply via the regular IP; another is to use 
RSVP. If the providers want to set up bi-directional LSP's, we can 
certainly consider of using the bi-directional LSP for replies. Thanks!

>    in the reverse path of the bi-directional LSP.

Sure.

>       removes the ambiguity associated with this.

In case of ICMP, yes, you need to put the pid in that field (or getpid() 
& 0xff :-)). For UDP, the source port number is sufficient here. As you 
may see here, with ICMP, the change in ICMP processing is not as 
straight-forward as UDP. :-)

>    would be useful to include in this section again.

OK.

Thanks!

- Ping

---

From: Nabil Seddigh <[email-masked]>
Date: Wed, 10 Jul 2002 17:59:29 -0400

Ping,

I agree that naming is a secondary issue but the standards set the 
tone for the terminology. Whatever is used in the draft will likely 
be adopted as the appropriate terminology. There are already deployed 
boxes out there with Traceroute and Ping over LSPs - using the 
existing ICMP definitions. It would be nice if this new draft:

1. Could co-exist with the existing LSP Traceroute and Ping.
   This is from a technology as well as terminology perspective.

2. Could have a technical solution that is a super-set of existing
   LSP TR and Ping functionality (hence the suggestion of ICMP 
   as a possible return mechanism).

---
Best,
Nabil Seddigh

---

From: Ping Pan <[email-masked]>
Date: Wed, 10 Jul 2002 15:20:03 -0700

>    This is from a technology as well as terminology perspective.

MPLS Ping (for ping and tracing at LSP level) is built on top of UDP. It 
requires the users to inject probe packets into the testing LSP's. I am 
certain that they will work indepdently from ping() and traceroute().

>    as a possible return mechanism).

After what had happened in the last several years, I'm afraid that we 
are getting over the ICMP solution by now. There are two equally good 
solutions (ICMP and UDP), and one of them (ICMP) had caused trouble 
before, let's just develope the darn thing with the other solution. 
IMHO, the primary task is to solve the actual problem with actual 
running code as soon as possible. No? :-)

Regards,

- Ping

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 11 Jul 2002 14:35:42 -0400

Ping,

I can see the desire to move on because for some not-too-clear 
reason the IESG did not approve the ICMP-based approach to 
MPLS Traceroute. IMHO, the ICMP-based approach to mpls traceroute
is cleaner than the UDP method proposed in the draft. It is 
unfortunate that the IESG cannot revisit the issue in question -
especially since there is running deployed code for the icmp-based
solution. What was the IETF's motto again: something to do with 
running code, and no kings :)

In any case, the document could benefit from some cleanup wrt
terminology. Here is an example paragraph:

  "In this document, we describe a mechanism, termed "MPLS ping", 
   that accomplishes these goals.  This mechanism is modeled 
   after the ICMP echo request/reply, used by ping and traceroute 
   to detect and localize faults in IP networks.  "

traceroute didn't use icmp echo req/reply and the name MPLS
ping is misleading. 

Suggest the name LSP debug or something like that be used 
as a term that encompasses ping and traceroute.

Best,
Nabil

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 11 Jul 2002 11:46:24 -0700

Nabil,

> solution. 

Given that there is running deployed code (with multiple interoperable
implementations), why does it really matter from the *practical*
point of view whether the IESG did, or did not approve it ?

> What was the IETF's motto again: something to do with 

That is the theory of the IETF. But as you know while in theory there
is no difference between the theory and the practice, in practice
there is :-)

Yakov.