Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Fri, 16 May 2014 04:20:49 +0000

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

Sami: Sure will do.

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

Sami: Ok, will fix that.

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

Sami: Sure.

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

Sami: It is out of scope of this document, but for sure procedure in 4379 apply.
> 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.

Sami: 

We are not saying the receiver must send a reply, however if he does the reply
may be received by the ingress node which might be the wrong node, since 
the receiver may not set the TTL properly on the reply, keep in mind that this is 
a receiver with an old implementation and the TLV is optional.

Please refer to the security section for your security concern.

Sami:

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

Sami: Are you familiar with the switching point TLV? and what it includes?

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

Sami: The tunnel label TTL is irrelevant here, however we will make it explicit that this is a PW label.

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

Sami: 
We are not here redefining  a trace route for a MS-PW, we are describing how our extensions will apply.
Sami:

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

Sami: 
The section describe how to handle the error scenario, there is no need for an error code.
Sami:

> 
> 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). 

Sami: 
Not sure I get the concern? Again we are not re-defining how MS-PW trace work.

Thanks,

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