The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Jun> msg00070



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

Issues with draft-ietf-mpls-lsp-ping-00.txt

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Thu, 13 Jun 2002 11:24:32 -0400
  • Cc: mpls@UU.NET

At 06:08 PM 6/11/2002 -0400, Nabil Seddigh wrote:


>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?

         I personally like MPLS ping for the simple reason that intuitively
this is what it does and this is how people will use it. MPLS ping
just has the extra feature of traceroute.  I don't think that the ICMP
ping is an issue.

         --Tom

>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



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.