Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-p2mp-lsp-ping-16.txt

From: Jia He <[email-masked]>
Date: Mon, 30 May 2011 21:30:42 +0800

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-mpls-p2mp-lsp-ping-16
Reviewer: Jia He
Review Date: May 30, 2011
IETF LC End Date: May 30, 2011
Intended Status: Standards Track

Summary:

The document is well written, and I only have several minor issues.

Major Issues:

No major issues found.

Minor issues:

1: echo response message or echo reply message

[RFC4379] uses "echo reply" in most places. It is recommended to check through the whole draft and keep the terminologies aligned between this draft and [RFC4379].

2: Section 2.2 (Page 5, 3rd paragraph), it says

   MPLS packets inserted at the ingress of a P2MP LSP are delivered
   equally (barring faults) to all egresses.  In consequence, the basic
   idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an
                        ^^^^^^^^^^^^^^^^^
   intention to test that packets that enter (at the ingress) a
   particular P2MP LSP actually end their MPLS path on the LSRs that are
   the (intended) egresses for that LSP.  The idea may be extended to
   check selectively that such packets reach specific egresses.

It seems to me that this paragraph applies to both P2MP LDP LSPs and P2MP MPLS TE LSPs rather than "P2MP MPLS TE LSPs" only. 
Am I missing something, or should the text be changed to "P2MP MPLS LSPs" so that it covers both types of P2MP LSP?

3: Section 3.2 (Page 10, under the format of P2MP Responder Identifier TLV)

      Sub-TLVs:

        Zero, one or more sub-TLVs as defined below.

        If no sub-TLVs are present, the TLV MUST be processed as if it
        were absent.  If more than one sub-TLV is present the first MUST
        be processed as described in this document, and subsequent
        sub-TLVs SHOULD be ignored.

Does it mean only zero or one sub-TLV applies in this document? Why do we add more than one sub-TLV if subsequent sub-TLVs SHOULD be ignored? Or Am I missing something? 
More clafications would be much appreciated.

4: Section 4.2.1 (Page 16, 2nd paragraph)

   When the responding node reports that it is an egress, it is clear
   that the echo response applies only to the reporting node.
   Similarly, when a node reports that it does not form part of the LSP
   described by the FEC (i.e. there is a misconnection) then the echo
   response applies to the reporting node.

This intention of this paragraph is not clear to me. Could the authors provide more explanations? E.g., How is "similarly" deduced? What is the difference or similarity between those two cases?

Nits:

1: Section 2.2 (Page 6, 1st paragraph)

    The second procedures allows the initiator to ...
               ^^^^^^^^^^
should be "procedure"

2: Section 3.1.2 (Page 8)

    The new sub-TLVs are assigned a sub-type identifiers as follows
                                  ^^^^^^^^^^^^^^^^^^^^^^
should be "sub-type identifiers"

3: Section 4.1.2 (Page 15, 1st paragraph)

   The initiating LSR can supply the desired value of the jitter in the
   Echo Jitter TLV as defined section 3.3. 
                            ^^^
"in section 3.3"

4: Secion 4.2.1.3 (Page 18~19)

      Node behavior guidelines:

      - If the Responder Identifier TLV is not present, then the node
        will behave as a combination egress and branch node.
                                   ^^^

      - If the Responder Identifier TLV containing a Node Address
        sub-TLV is present, and:

         - If the address specified in the sub-TLV matches to an address
           in the node, then the node will behave like an combination egress and branch node.
                                                                    ^^^
      ....
 
     - If the node is behaving as a combination egress and branch node, and:
                                              ^^^
"a combination of", "of" is missing...

5: Section 4.3.1 (Page 19, last paragraph)

   For P2MP TE LSP, the initiating LSR has a priori knowledge about
   number of egress nodes and their addresses.  Hence it possible to
                                                       ^^^
   continue processing till a valid response has been received from each
   end-point, provided the responses can be matched correctly to the
   egress nodes.

"it is possible"

That's what I have...

Jia

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Tue, 31 May 2011 07:34:38 -0500

Hi Jia,

Thank you very much for the thorough reading and comments. I will update
the draft as necessary.

Regards,

Shaleen

From: Jia He [mailto:[email-masked]] 
Sent: Monday, May 30, 2011 9:31 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RtgDir review: draft-ietf-mpls-p2mp-lsp-ping-16.txt

Hello,

 

Summary:

Major Issues:

No major issues found.

Minor issues:

[RFC4379] uses "echo reply" in most places. It is recommended to check
through the whole draft and keep the terminologies aligned between this
draft and [RFC4379].

It seems to me that this paragraph applies to both P2MP LDP LSPs and
P2MP MPLS TE LSPs rather than "P2MP MPLS TE LSPs" only. 
Am I missing something, or should the text be changed to "P2MP MPLS
LSPs" so that it covers both types of P2MP LSP?

3: Section 3.2 (Page 10, under the format of P2MP Responder Identifier
TLV)

      Sub-TLVs:

Does it mean only zero or one sub-TLV applies in this document? Why do
we add more than one sub-TLV if subsequent sub-TLVs SHOULD be ignored?
Or Am I missing something? 
More clafications would be much appreciated.

This intention of this paragraph is not clear to me. Could the authors
provide more explanations? E.g., How is "similarly" deduced? What is the
difference or similarity between those two cases?

Nits:

         - If the address specified in the sub-TLV matches to an address
           in the node, then the node will behave like an combination
egress and branch node.
                                                                    ^^^
      ....
 
     - If the node is behaving as a combination egress and branch node,
and:
                                              ^^^
"a combination of", "of" is missing...

"it is possible"

That's what I have...

Jia