[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt
From:       Mach Chen <mach.chen () huawei ! com>
Date:       2014-03-31 2:22:29
Message-ID: F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D996541 () SZXEMA510-MBX ! china ! huawei ! com
[Download RAW message or body]

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, and sometimes on special request. 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-lsp-ping-ttl-tlv-07.txt 
Reviewer: Mach Chen 
Review Date: March 29, 2014
IETF LC End Date: 
Intended Status: Standards Track 

Summary: 

I have some minor concerns about this document that I think should be resolved before \
publication.

Comments: 
The draft is well written and easy to read. The solution is technical workable, but \
for some corner cases, more considerations are needed.

Major Issues: 

None.
 
Minor Issues: 

1. Since the TTL TLV is defined for both MS-PW and bidirectional co-routed LSP, it \
should be better to explicitly state this in the abstract section.

2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", "echo request" \
and "request" are interchangeably used in the draft, it's better to unify the usage \
of it to "MPLS echo request" (to align with the usage in RFC4379). For "echo reply", \
"bidirectional co-routed LSP", they have the similar issue.

3.Section 3.1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Value       |   Reserved    |   Flags                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For the TTL TLV, the value filed should include the "value", "Reserved" and "Flags", \
so it's better to change the "Value" field to "TTL" field hence to reduce the \
confusion. 

4. Section 3.2
"This TLV shall be included in the echo request by the originator of
   request. The use of this TLV is optional. If a receiver does not
   understand the TTL TLV, it will simply ignore the TLV (Type value of
   TLV is assumed to be in the range of optional TLV's which SHOULD be
   ignored if an implementation does not support or understand them). In
   the absence of TTL TLV or if TTL TLV is ignored by a receiver, the
   determination of the TTL value used in the MPLS label on the echo
   reply is beyond the scope of this document."

What's your mean of "beyond the scope of this document" here? Is it to apply the \
procedures defined in RFC4379 or just let it to the implementation? I guess you \
assume to apply the definition in RFC4379, if so, the TTL of the MPLS label will be \
more probably set to 255, means the echo reply will be sent to the ingress of the \
MS-PW or LSP. I am not sure whether this is the right procedure, it seems a security \
issue. IMHO, it does not make any sense to expect the receiver to send echo reply in \
this situation, and even sent, the initiator will not receive the reply. The safer \
way is to drop the whole echo request and record an error log.

5. Section 3.2

"In other words, if the value of the TTL provided by this TLV does not match the TTL
   determined by other means, such as Switching Point TLV in MS-PW, then
   TTL TLV must be used."
Here, it implies that the receiver has to perform TTL matching process, since how to \
set the TTL is independent of such matching, seems this sentence is redundant and \
confusion.  

6. Section 4.

"...The value field of the TTL TLV and the TTL field of the MPLS label are set to 2,"

I guess that the MPLS Label is the PW label, right? It's better to add more text to \
make this more explicit. In addition, how to set the TTL value of the tunnel Label? \
255 or any other value?

5. Section 4.1. Traceroute mode
   "In the traceroute mode TTL value in the TLV is successively set to 1,
   2, and so on. This is similar to the TTL values used for the label
   set on the packet."
IMHO, some text may be needed to clarify which "FEC" should be carried, especially \
for MS-PW trace. Since in Section 4.0, the example says the FEC of segment C-D should \
be carried, does it mean the FEC of last PW Segment of the segment under test should \
be carried or the FEC will vary when TTL changed. For example, when perform segment \
trace (e.g., to trace B-D segment), when TTL is 1, which FEC should be carried?

6. Section 4.2. Error scenario
For this scenario, do you need to define some error codes here? 

7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if so, it should \
be explicitly stated. If not, you should define how the MS-PW trace works (given that \
the tunnels in both directions may span different hops). 

Nits: 

1. Please check the text for acronyms that have not been expanded in their first use.

2. I run the idnits tool and found the following nits, please check and fix. 
    (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: 'RFC2119' on line 121

  -- Looks like a reference, but probably isn't: 'RFC4379' on line 258

  == Unused Reference: '1' is defined on line 284, but no explicit reference
     was found in the text

  == Unused Reference: '2' is defined on line 287, but no explicit reference
     was found in the text

  == Unused Reference: '3' is defined on line 291, but no explicit reference
     was found in the text

3. Section 3.2,
3.1 first para first sentence
s/shall/SHALL
3.2 last para, the last second sentence
s/must/MUST

4. The draft quotes the MS-PW and bidirectional co-routed LSP concept, it's better to \
add related references to this document.


Best regards,
Mach

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


[prev in list] [next in list] [prev in thread] [next in thread]