The MPLS WG Archive

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

I finally got the chance to read the new version of the dataplane
liveliness draft after having last read v02 previously. I
had a few questions and suggestions:

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
nseddigh@tropicnetworks.com