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

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

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.