Subject: [mpls] working group last call on draft-ietf-mpls-lsr-self-test-05.txt

From: Loa Andersson <[email-masked]>
Date: Tue, 23 Aug 2005 09:00:23 +0200

Working Group,

this mail initiates a two week working group last call on
Label Switching Router Self-Test <draft-ietf-mpls-lsr-self-test-05.txt>.

The last call ends Wednesday September 7 EOB PST. Please send your
comments to the working group mailing list.

Loa and George

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Aug 2005 12:25:13 +0100

Hi,

It might be nice to run idnits on this draft.

A few nits...

1. Introduction

   This document defines a means for a Label-Switching Router (LSR) to
   verify that its dataplane is functioning for certain key Multi-Proto-
   col Label Switching (MPLS) applications, including unicast forwarding
   based on LDP [LDP] and traffic engineering tunnels based on [RSVP-
   TE].  MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] mes-
   sages are extended to do the actual probing.

Too many "messages"!

=======

1. Introduction

   The pings are sent to
   an upstream neighbor, looped back through the LSR under test and
   intercepted, by means of TTL expiration by a downstream neighbor.
   Extensions to LSP-Ping [LSP-Ping] are defined to allow the down
   stream neighbor to report the test results.

"downsteam" one word or hyphenated.

=======

1. Introduction

   In order to minimize the load on upstream LSRs a new loopback FEC is
   defined. Receipt of a packet labeled with a loopback label will cause
   the advertising LSR to pop the label off the label stack and send the
   packet out the advertised interface.

What is a "loopback label"? Perhaps you ned to define the term and relate
it to the loopback FEC.

=======

Some examples of non-2119 language should be fixed.
For example, section 2.1. Explanation of Res field.

=======

Section 2.1

Spurious formatting instruction
       .in 9

Typos
      Note that this type alos indicates the encapsulation type for
payloads
      that have a label stack contain the one loopback label.
s/alos/also/
/contain/containing/

Clarity
      Note that this type alos indicates the encapsulation type for
payloads
      that have a label stack contain the one loopback label.
Could you clarify "containing the one loopback label."
Also, I believe that this note explains why it is necessary to have
different type values of IPv4 unnumbered and IPv6 unnumbered even though
they are otherwise identical. Perhaps you could add to the note.

=======

Section 2.2
   identifier to form the request.  In these cases, the downstream LSR
   will need to be configured to make unsolicited advertisements.
Can we replace "will need to be" with a 2119 term? I think this is "MAY
be" since the procedure is not mandatory.

=======

Section 3
   A self test operation involves three LSRs, the LSR doing the test, an
   upstream neighbor and a downstream neighbor.  We refer to these as
   LSRs T, U, and D respectively.

This seems to be in conflict with the Introduction that says...
   Note that use of a loopback allows an LSR to test label entries for
   which the LSR is not currently some neighbor's next hop.

If the LSRs are neighbors, aren't they also next hops? I think that you
mean to say that D is "a downstream LSR", but not say that it is a
neighbor.

In fact, you go on to say...
   Although the figure shows LSR-D adja-
   cent to LSR-T it may in some cases be an arbitrary number of hops
   away.

=======

Section 3.1
   The MPLS Data Plane Verification Reply message MAY contain the fol-
   lowing objects:

You need something a little stronger. A Data Plane Verification Reply
without either of
           7               IPv4 Interface and Label Stack Object
           8               IPv6 Interface and Label Stack Object
would presumably be invalid as well as useless.

=======

Section 3.4
   The LSR creates an MPLS Data Plane Verification Request message and
   includes a Data Plane Verification Object.

We don't appear to have a definition of a Data Plane Verification Object.
I suspect that this object is needed when the Echo Request is used so that
we can tell the difference between a normal Echo Request and one that is
being used for Data Plane Verification.

=======

Section 3.5
   If the echo request is good, X notes the interface I over which the
   echo was received, and the label stack with which it came. If the
   MPLS echo request contained a Downstream Verification object, then X
   must format this information as a Downstream Verification object and
   include it in its MPLS echo reply message.

The text has become confused between describing the processes for handling
a Verification Request message, and the processes for handling  echo
requests that contain the mythical Downstream Verification object.
Probably best to describe the main case (VR message) first and then have a
coda for the use of Echo Request messages.

========

That's all.
Adrian