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

[Mach Chen <[e-mail]>]

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.