Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thank you very much for these updates, Mach!

Note that the update #3 also implies a simplification of the IANA instructions, because now you do not have any sub-TLVs that are defined for TLV21 and not for TLV1.

This resolves all my comments, thanks again!

-- Carlos.

On Sep 17, 2013, at 2:44 AM, Mach Chen <[e-mail]>
 wrote:

> Hi Carlos and all,
> 
> We just uploaded a revision that mainly based on your comments.
> 
> Here are the related links of the new draft:
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-ping 
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-13 
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-return-path-specified-lsp-ping-13 
> 
> 
> The summary of the updates:
> 1. BFD and inter-AS related text removed; 
> 2. refine the definition of the "A" bit, decouple the relationship between the "A" bit and whether test the return path;
> 3. apply the tunnel sub-TLVs to TLV type 1; 
> 4. and other editorial changes to solve the minor comments;
> 
> 
> Hope this resolve your comments.
> 
> Many thanks
> Mach
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Carlos Pignataro (cpignata)
>> Sent: Tuesday, September 03, 2013 7:53 AM
>> To: <[e-mail]>
>> Cc: <[e-mail]>;
>> [e-mail]; [e-mail]
>> Subject: [mpls] RtgDir review:
>> draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
>> 
>> 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-return-path-specified-lsp-ping-12.txt
>> Reviewer: Carlos Pignataro
>> Review Date: 02 September 2013
>> IETF LC End Date: 04 September 2013
>> Intended Status: Proposed Standard
>> 
>> Summary:
>> 
>> I have significant concerns about this document and recommend that the Routing
>> ADs discuss these issues further with the authors.
>> 
>> Comments:
>> 
>> This document defines useful functionality. It is also generally well written and is
>> fairly detailed and comprehensive.
>> 
>> At the same time, for a set of extensions that attempts to provide more
>> determinism in a failure detection protocol, I believe there is still significant
>> ambiguity in a few underspecified elements and behaviors.
>> 
>> Although I have marked a number of "major" issues, some of them should be
>> relatively easy to fix. Others, however, pose somewhat fundamental questions.
>> 
>> I hope these review comments are clear and useful!
>> 
>> 
>> Major Issues:
>> 
>> The first major issue that I would like to have discussed is the usage of these
>> extensions for BFD for MPLS bootstrapping. The Abstract in this document sets to
>> prove that the extensions thereby defined can be used for BFD for MPLS
>> bootstrapping. However, I believe that the document is underdefined to make
>> that claim in the Abstract.
>> 
>> There is somewhat of a contradiction in that, to make BFD for MPLS
>> bootstrapping using these extensions work, specific protocol definitions (i.e.,
>> 2119 language in the BFD for MPLS bootstrapping state machine) need to take
>> place in BFD, as per draft-chen-mpls-bfd-enhancement. However, that
>> document is only an Informative reference in this document. It appears to me
>> that, without draft-chen-mpls-bfd-enhancement, the claim of the Abstract
>> cannot be fulfilled. By way of process, I also believe this might have not been
>> tested with the BFD working group.
>> 
>> In any case, the only mention of BFD for MPLS bootstrapping in this document is
>> by passing as an example in Section 3.3.1. Due to all of these reasons, I believe
>> this doc should remove the goal of BFD improvements al together or majorly
>> qualify and downgrade the usage with BFD.
>> 
>> A second major issue is a question: Given how RFC 4379 defines the reply mode 4
>> ("Reply via application level control channel"). Given a bidirectional LSP. Doesn't
>> using GAL+GACh and Reply Mode #4 solve this whole problem? Why is that one
>> not discussed? Basically, RFC 4379 uses RFC 5085 as the reference example of
>> reply mode #4. Since RFC 5586 generalizes the VCCV associated channel to LSPs,
>> then we have a generic control channel to be used with reply mode #4.
>> 
>> Also, what's the relationship to RFC 6426 and TLV 16? Another return path?
>> 
>> A third major issue has to do with the treatment of Inter-AS scenarios in this draft.
>> In Sections 2.1 and 2.2, this draft is implicitly presented as a solution for MPLS
>> Echo in "inter-domain LSPs" and "inter-domain/inter-AS LSP". The problems in
>> these cases are more convoluted than what this draft describes, and includes lack
>> of addressing context and initiator address unknown (not only that the IP Router
>> Alert label might not work in the boundary). I believe that this draft should not
>> call those cases since are not solved by the addition of a new reply mode.
>> 
>> A fourth major issue has to do with the use of IP Path versus LSP Path, as per a
>> number of Minor issues described below that, together, amount to a major. See
>> minor issues section.
>> 
>> A fifth major issue concerns itself with ECMP upon return. Saying that the
>> response should be sent over the LSP with target FEC Stack of LDP IPv4 prefix of
>> 192.0.2.27/32 is not enough, as there are potentially multiple paths throughout. I
>> believe this topic should be discussed. In the Echo direction, this is solved with
>> the Downstream Mapping mechanics. That is overkill for the response, but again,
>> multi path can give false negatives the same deeming the whole solution
>> unusable (since at the end it cannot provide the prescriptiveness).
>> 
>> A last major issue concerns itself with Security considerations. Using these
>> extensions, a node can instruct another node to send replies out of any LSP,
>> including LSPs that do not go back to the source. Further, an attacker can send
>> MPLS Echo nodes to many nodes vectoring responses to a node target of a DDoS
>> attack. The security considerations briefly touches this point and says that "the
>> return path LSP MUST have destination to the same node where the forward
>> path is from". However, it is not clear how a node can actually evaluate and
>> actually verify and enforce this MUST. It is quite possible that this check is not
>> possible to make.
>> 
>> 
>> Minor Issues:
>> 
>> Does this document update RFC 4379?
>> 
>> 1. Introduction
>> 
>>   The procedures defined in this document
>>   currently only apply to "ping" mode.  The "traceroute" mode is out of
>>   scope for this document.
>> 
>> I am note sure if this is major or minor -- but separating traceroute mode as out
>> of scope seems like a huge gap. Are there specific issues with using these
>> extensions in traceroute mode? The last hop of a traceroute is equivalent to a
>> ping -- can these extensions be used there?
>> 
>> 
>>   The defined extensions can also be
>>   utilized for creating a single Bidirectional Forwarding Detection
>>   (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or for a
>>   pair of unidirectional LSPs (one for each direction).
>> 
>> For BFD for bidirectional LSPs, there is no need to use LSP Ping bootstrapping,
>> since the context of the session can be directly gleaned as defined in RFC 5885. In
>> other words, single-hop BFD initialization is enough -- why would someone want
>> to use bootstrapping with LSP Ping, and then specific extensions, when the
>> context of the BFD discriminators is understood from the label (again, as per RFC
>> 5885)?
>> 
>>   In this document, the term bidirectional LSP includes the co-routed
>>   bidirectional LSP defined in [RFC3945] and the associated
>>   bidirectional LSP that is constructed from a pair of unidirectional
>>   LSPs (one for each direction), and which are associated with one
>>   another at the LSP's ingress/egress points [RFC5654].  The mechanisms
>>   defined in this document can apply to both IP/MPLS and MPLS Transport
>>   Profile (MPLS-TP) scenarios.
>> 
>> Two key questions:
>> 1. What about Pseudowires?
>> 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP control
>> plane (to run LSP Ping)?
>> 
>> 
>> 2. Problem Statements and Solution Overview
>> 
>>   MPLS LSP Ping is defined in [RFC4379].  It can be used to detect data
>>   path failures in all MPLS LSPs, and was originally designed for
>>   unidirectional LSPs.
>> 
>> Where does RFC4379 limits its scope to unidirectional LSPs?
>> 
>>   And in any case, the use modes 2 or 3 cannot guarantee the delivery
>>   of echo responses through an IP network that is fundamentally
>>   unreliable.  The failure to deliver echo response messages can lead
>>   to false negatives making it appear that the LSP has failed.
>> 
>>   Allowing the ingress LSR to control the path used for echo reply
>>   messages, and in particular forcing those messages to use an LSP
>>   rather than being sent through the IP network, enables an operator to
>>   apply an extra level of deterministic process to the LSP Ping test.
>> 
>> These two paragraphs seems to show a gross misconception on how reply works.
>> From 4379, the reply with mode #1 does not need to be sent over IP without
>> MPLS. It can very well be sent over an LSP. In fact, given the right source IP
>> address in the LSP Ping Echo, the right return LSP can be chosen. This needs to be
>> better explained so as not to "hype" the solution presented in the document.
>> 
>> 3. Extensions
>> 
>>   In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class
>>   (TC) [RFC5462] TLV, are defined in this document.
>> 
>> Given that the "Reply Path TLV" specifies an LSP and not a Path, I strongly suggest
>> the TLV be renamed to more specifically describe its functionality.
>> 
>> 
>>   0x0004        The specified Reply Path was not found, the echo
>>                 reply was sent via other LSP
>>   0x0005        The specified Reply Path was not found, the echo
>>                 reply was sent via IP path
>> 
>> It is not clear what an IP path is, when sending an LSP Echo response as an IP
>> datagram can be sent labeled as an LSP. Also, I assume these are without Router
>> Alert, right?
>> 
>>   A (Alternative path): the egress LSR MUST select a non-default path
>>   as the return path.  This is very useful when reverse default path
>>   problems are suspected which can be confirmed when the echo reply is
>>   forced to follow a non-default return path.  Here, the default path
>>   refers to the path that the egress LSR will use to send the echo
>>   reply when the return path is not explicitly specified as defined in
>>   this document.  If A bit is set, there is no need to carry any
>>   specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD
>>   be ignored.
>> 
>> Do all implementations understand the same thing as "Default"? This seems
>> underspecified.
>> 
>> Also, say that an LSP Ping is sent with source IP address as 192.0.2.1 over an LSP. A
>> "default" return LSP is perhaps an LSP where 192.0.2.1/32 points to. How would a
>> non-default be in this case? Send it to a wrong LSR? What should responding
>> router choose in this case? How can it choose a non-default without the
>> specification of an actual LSP?
>> 
>>   B (Bidirectional): the return path is required to follow the reverse
>>   direction of the tested bidirectional LSP.  If B bit is set, there is
>>   no need to carry any specific reply path sub-TLVs, and when received,
>>   the sub-TLVs SHOULD be ignored.
>> 
>> Is this default or non-default when this TLV is not used (pre-this spec)?
>> 
>> 3.2. Reply Path (RP) TLV
>> 
>> When reply mode (!= 5) and Reply Path TLV is received, which takes precedence
>> and what is the procedure?
>> 
>> 
>> 3.3. Reply Path sub-TLVs
>> 
>>   In addition, this document defines three new sub-TLVs: IPv4 RSVP
>>   Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV.
>> 
>> It is not clear why these are specified. The text does not seem to explain the
>> need, nor why these do not need to be specified for the TLV 1.
>> 
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |         MUST be zero      |S|P|
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> Further, "primary" and "secondary" are not defined. Which specifications
>> explains what is a primary and a secondary?
>> 
>> 3.3.3. Static Tunnel sub-TLV
>> 
>> Again, why is this not specified for the Echo as well?
>> 
>> 4. Theory of Operation
>> 
>>   When the echo reply message is intended to test the return MPLS LSP
>>   path(when the A bit is not set in the previous received echo request
>>   message), the destination IP address of the echo reply message MUST
>>   never be used in a forwarding decision.
>> 
>> Is this really the meaning of the "A-bit"?
>> 
>>   To avoid this possibility
>>   the destination IP address of the echo reply message that is
>>   transmitted along the specified return path MUST be set to numbers
>>   from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and
>>   the IP TTL MUST be set 1, and the TTL in the outermost label MUST be
>>   set to 255.
>> 
>> 0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be 0:0:0:0:0:FFFF:7F00/104 or
>> 0:0:0:0:0:FFFF:127.0.0.0/104
>> 
>>   Of course when the echo reply message is not intended
>>   for testing the specified return path (when the A bit is set in the
>>   previous received echo request message) , the procedures defined in
>>   [RFC4379] (the destination IP address is copied from the source IP
>>   address) apply unchanged.
>> 
>> Does this mean that "Alternate" and "Non Default" are actually to follow the
>> *Default* procedures from RFC 4379?
>> 
>> 4.3. Sending an Echo Reply
>> 
>>   and the IP TTL MUST be set to 1, the
>>   TTL in the outermost label MUST be set to 255.
>> 
>> Should this follow draft-ietf-mpls-lsp-ping-ttl-tlv?
>> 
>> 6.4. Reply Path Return Code
>> 
>> There seems to be a contradiction in this:
>> 
>>   0x0006-0xfffb Not allocated, allocated via Standard Action
>>   0xfffc-0xffff Experimental Use
>> 
>>   The range of 0x0008-0xfffb is not allocated and reserved for future
>>   extensions and is allocated via Standard Action, the range of 0xfffc-
>>   0xffff is for Experimental Use.
>> 
>> Overall -- what is the interaction with draft-ietf-mpls-remote-lsp-ping? Note also
>> that document specifies a reply mode with the same value of "5".
>> 
>> Also, this document does not seem to define backward compatibility
>> considerations. What happens if a pre-specification router receives a Reply Mode
>> #5? The generic behavior of RFC 4379 is to respond with a generic "malformed
>> echo" error -- should there be a sub-code for Unknown reply mode -- in which
>> case it's a bit ironic to reply by some other mode -- to signal the specific issue for
>> future reply codes?
>> 
>> A final minor issue: this specification defines a new behavior for an echo reply in
>> which the Echo Reply message is destined to a loopback IP Address. If the return
>> path is broken, a middle router will think the packet is destined to itself (because
>> of the loopback) -- the behavior in this case is undefined and can result in funny
>> behaviors, for example an ICMP port unreachable sent to the source or weirder.
>> 
>> A last minor issue relates the IANA requests -- section 6.2 is already fairly
>> complex, yet it does not speak to the following: What happens when sub-TLVs
>> for TLV1 are defined? What is checked to make sure that this new sub-TLV applies
>> to TLV21, and how? Does this update IANA allocations for RFC 4379? Also, a
>> sub-TLV with sub-Type 16384 can be assigned to TLV1 with specification required,
>> but needs Standards action for TLV 21? And from which of these eight ranges are
>> sub-Types of Section 6.2.1 assigned, and why are not applicable to TLV Type 1 and
>> Type 16?
>> 
>> I would include in the IANA instructions details within TLV 1 about the changes
>> and "directly copied" to TLV21.
>> 
>> 
>> Nits:
>> 
>> Abstract
>> 
>>   This document defines extensions to the failure-detection protocol
>>   for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
>>   known as "LSP Ping" that allow selection of the LSP to use for the
>>   echo reply return path.
>> 
>> The abstract is key in that its legibility sets for the whole document. These same
>> comments apply to the Introduction.
>> 
>> First, to be consistent with RFC4379, I'd qualify adding "...extensions to the
>> *data-plane* failure-detection protocol...".
>> 
>> Second, this is a very long sentence that reads better split in two: "known as "LSP
>> Ping". These extensions allow selection of the"
>> 
>> 
>>   The Reply via Specified Path mode is used to request that the remote
>>   LSR receiving the LSP Ping echo request message sends back the echo
>>   reply message along the specified paths carried in the Reply Path
>>   TLV.
>> 
>> There is no such a thing as "LSP Ping echo request message" in RFC 4379. The
>> same happens throughout the document, and should be fixed.
>> 
>> 
>>        0                   1                   2                   3
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |     Reply Path TLV Type       |          Length               |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |    Reply Path return code     |              Flag             |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> These are "Flags" (plural).
>> 
>>   0x0002        One or more of the sub-TLVs in Reply Path TLV
>>                 was not understood
>> 
>> s/was/were/
>> 
>> 
>> Additionally, idnits 2.12.17 finds the following:
>> 
>>  ** There is 1 instance of too long lines in the document, the longest one
>>     being 1 character in excess of 72.
>> 
>>  == Unused Reference: 'RFC6426' is defined on line 873, but no explicit
>>     reference was found in the text
>> 
>> 
>> I hope these are clear and useful!
>> 
>> Thank you,
>> 
>> Carlos Pignataro.
>