Last Call Review of draft-ietf-mpls-proxy-lsp-ping-03
review-ietf-mpls-proxy-lsp-ping-03-opsdir-lc-kumari-2015-03-01-00

Be ye not alarmed.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the
operational area directors.   Document editors and WG chairs should
treat these comments just like any other last call comments.


Revision reviewed: draft-ietf-mpls-proxy-lsp-ping-03
Summary: Ready with nits and notes.
ID Nits: Clean (other than a nit checker error)
Note: There is IPR.

NOTE: There is also


https://tools.ietf.org/html/draft-ietf-mpls-remote-lsp-ping-03

, which
(AFAICT) was an earlier version of this document, and keeps coming up
in searches, etc. It was one of the first hits when I looked for
draft-ietf-mpls-remote-lsp-ping and I accidentally started revewing it
by mistake :-(

There was an implementation poll in July 2014
(

http://www.ietf.org/mail-archive/web/mpls/current/msg12473.html

), and
writeup says:
"We know of implementations of this specification. An implementation
poll has been sent to the working group mailing list and the write-up
will be updated as soon as we have further information.". I did not
see any replies to that mail, nor the writeup updated. Knowing what
implementations exist (and who uses this) would go a long way to
showing that this works will in an operational environment.


I initially started reviewing draft-ietf-mpls-remote-lsp-ping-03,
which is not nearly as clear. This document is much clearer, but there
are still a number of readability nits, many of which are below...


General notes:
I didn't see any mention (or I messed it) of rate limiting processing
of these messages. If I get many thousands per seconds (e.g because an
NSM went nuts), what do I do?

In the security considerations section:
"If a MPLS Proxy ping request IP destination address is a Martian
Address, it MUST NOT be acted upon."
I'm not sure that this is a good idea, Also, AFACIT Martians are not
well defined - RFC3871, RFC1208 seem closest, but what is actually a
martian changes over time - see e.g


http://www.team-cymru.org/bogon-reference.html

 . Some provides number
infrastructure out of what could be considered Martian (e.g:


http://datatracker.ietf.org/doc/rfc7404/

). I'd suggest just dropping
this.

How do I (as an operator) initiate this? Is it only expected to be
available from the CLI? From a management tool? SNMP?


Apparently the document has already been reviewed in the past, and so
I didn't do quite as thorough a review as I otherwise may have. There
is also, apparently, an implementation so the general theory should
work.


Readability / grammar nits:

Standardizing on one capitalization of 'MPLS proxy ping' would make
reading the document much easier.


More nits in [OPR] format:


   One alternative would be to begin sending pings from points at or
   near the affected egress(es) and working backwards toward the root.

[O] and working backwards toward the root.

[P] and then work backwards toward the root.

[R] readability/grammar

   The TTL could be held constant, say two, limiting the number of
   responses to the number of next-next-hops of the point where a ping
   is initiated.

   In the case of Resource Reservation Protocol-Traffic Engineering
   (RSVP-TE), all setup is initiated from the root of the tree. Thus,
   the root of the tree has knowledge of both all the leaf nodes and
   usually the topology of the entire tree. Thus the above alternative
   can easily be initiated by the root node.

   In [RFC6388] the situation is quite different. Leaf nodes initiate
   connectivity to the tree which is granted by the first node toward

[O] to the tree which is granted

[P] to the tree, which is granted

[R] grammar

 The leaf node also requests the identity of
   the upstream neighbor's upstream neighbor for that FEC. With this
   information the procedure can iteratively be applied until the fault

[O] With this information the

[P] With this information, the

[R] grammar


   is localized or the root node is reached. In all cases the TTL for

[O] In all cases the TTL

[P] In all cases, the TTL

[R] grammar

   the request need only be at most 2. Thus the processing load of each
   request is small as only a limited number of nodes will receive the

[O] small as only

[P] small, since only

[R] readability

   request.

   This document defines protocol extensions to MPLS ping [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request message to
   be sent down an LSP or part of an LSP. The procedure described in the
   paragraphs above does require that the initiator know the previous-
   hop node to the one which was pinged on the prior iteration. This
   information is readily available in [RFC4875]. This document also
   provides a means for obtaining this information for [RFC6388].

   While the motivation for this document came from multicast scaling
   concerns, it's applicability may be wider. The procedures presented
   in this document are applicable to all LSP ping FEC types where the
   MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply
   can sent out of band of the LSP over ip. Remote pinging of LSPs that

[O] LSP over ip
[P] LSP over IP

[R] grammar

   involve the use of in-band control channels is beyond the scope of
   this document.

   Other uses of this facility are beyond the scope of this document. In
   particular, the procedures defined in this document only allow
   testing of a FEC stack consisting of a single FEC. It also does not

[O] It also does not

[P] Either "This document" instead of "It" or "The procedures" instead of "It"

[R] readability

   allow the initiator to specify the label assigned to that FEC, nor
   does it allow the initiator to cause any additional labels to be
   added to the label stack of the actual MPLS Echo Request message.


2.  Proxy Ping Overview

   This document defines a protocol interaction between a first node and
   a node which is part of an LSP to allow the first node to request
   that second node initiate an LSP ping for the LSP on behalf of the
   first node. Since the second node sends the LSP Ping on behalf of the

[O] This document defines a protocol interaction between a first node and

   a node which is part of an LSP to allow the first node to request
   that second node initiate an LSP ping for the LSP on behalf of the
   first node.

[P] This document defines a protocol  interaction between a first node
a node which is part of an LSP, to allow the first node to request
that the second node initiate an LSP ping for the LPS on the first
node's behalf.

[R] readability.

   first node, it does not maintain state to be able to handle the
   corresponding LSP Ping response. Instead the responder to the LSP
   ping sends the LSP Ping response to either the first node or another
   node configured to handle it. Two new LSP Ping messages are defined
   for remote pinging: the MPLS proxy ping request and the MPLS proxy
   ping reply.

 [ SNIP ]

   The initiator formats an MPLS proxy ping request message and sends it
   to the proxy LSR, a node it believes to be on the path of the LSP.
   This message instructs the proxy LSR to either Reply with Proxy
   information or to send a MPLS Echo Request inband of the LSP. The
   initiator requests Proxy information so that it can learn additional
   information it needs to use to form a subsequent MPLS Proxy Ping
   request. For example during LSP traceroute an initiator needs the

[O] For example during

[P] For example, during

[R] readability

   downstream map information to form an MPLS Echo Request. An initiator
   may also want to learn a Proxy LSR's FEC neighbor information so that
   it can form proxy request to various nodes along the LSP.

[O] can form proxy request to

[P] can form proxy requests to

[R] grammar


3.2.  Procedures for the proxy LSR

 [SNIP]

   The header fields Sender's Handle and Sequence Number are not
   examined, but included in the MPLS proxy ping reply or MPLS Echo

[O] are not examined, but included
[P] are not examined, but they are included

[R] grammar

[SNIP]

   If the "Request for FEC Neighbor Address info" flag is set, a
   Upstream Neighbor Address TLV and/or Downstream Neighbor Address
   TLV(s) is/are formatted for inclusion in the MPLS proxy ping reply.
   If the Upstream or Downstream address is unknown they are not

[O] is unknown they are not

[P] is unknown, they are not

[R] grammar



3.2.1.  Proxy LSR Handling when it is Egress for FEC

   This sections describes the different behaviors for the Proxy LSR

[O] This sections describes

[P] This section describes

[R] grammar

   when it's the Egress for the FEC. In the P2MP budnode and MP2MP
   budnode and egress cases, different behavior is required.

   When the Proxy LSR is the egress of a P2P FEC, a MPLS proxy ping
   reply SHOULD be sent to the initiator with the return code set to 3
   (Reply router is Egress for FEC) with return Subcode set to 0.

   When the Proxy LSR is the egress of a P2MP FEC, it can be either a
   budnode or just an Egress. If the Proxy LSR is a budnode, a MPLS

[O] a MPLS

[P] an MPLS

[R] readability and consistency

   proxy ping reply SHOULD be sent to the initiator with the return code
   set to 3 (Reply router is Egress for FEC) with return Subcode set to
   0 and DS/DDMAPs only if the Proxy initiator requested information to
   be returned in a MPLS proxy ping reply. If the Proxy LSR is a budnode
   but not requested to return a MPLS proxy ping reply, the Proxy LSR
   SHOULD send MPLS Echo Request packet(s) to the downstream neighbors
   (no MPLS Echo Reply is sent to the Proxy Initiator to indicate that
   the Proxy LSR is an egress). If the Proxy LSR is just an egress, a
   MPLS proxy ping reply SHOULD be sent to the initiator with the return

[O] a MPLS

[P] an MPLS

[R] readability and consistency

   code set to 3 (Reply router is Egress for FEC) with return Subcode
   set to 0.

   When the Proxy LSR is the egress of a MP2MP FEC, it can be either a

[O] a MP2MP

[P] an MP2MP

[R] readability. Same corrections further down are not specifically noted.



   ping reply. If the Proxy LSR is not requested to return information
   in a MPLS proxy ping reply, the Proxy LSR SHOULD send MPLS Echo
   Request packets to all upstream/downstream neighbors as would be done

[O] neighbors as would be done

[P] neighbors, as would be done
[R] grammar

   when sourcing an LSP ping from a MP2MP leaf (no MPLS Echo Reply is
   sent to the Proxy initiator indicating that the Proxy LSR is an
   egress).

3.2.2.  Downstream Detailed/Downstream Maps in Proxy Reply

   When the Proxy LSR is a transit or bud node, downstream maps
   corresponding to how the packet is transited can not be supplied

[O] can not

[P] cannot

[R] grammar

   unless an ingress interface for the MPLS Echo Request is specified.
   Since this information is not available and all valid output paths
   are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe
   the entire set of paths that the packet can be replicated. This is
   similar to the case where an LSP ping is initiated at the Proxy LSR.

[O] case where an

[P] case in which an

[R] grammar



   For mLDP there is a DSMAP/DDMAP per upstream/downstream neighbor for
   MP2MP LSPs, or per downstream neighbor in the P2MP LSP case.

   When the Proxy LSR is a bud node or egress in a MP2MP LSP or a
   budnode in a P2MP LSP, an LSP ping initiated from the Proxy LSR would
   source packets only to the neighbors but not itself despite the fact

[O] but not itself despite the fact

[P] but not itself, despite the fact

[R] grammar


3.2.4.  Sending the MPLS Echo Requests

   A MPLS Echo Request is formed as described in the next section. The
   section below that describes how the MPLS Echo Request is sent on
   each interface.

3.2.4.1.  Forming the base MPLS Echo Request

   A Next_Hop_List is created as follows. If Next Hop sub-TLVs were
   included in the received Proxy Parameters TLV, the Next_Hop_List
   created from the address in those sub-TLVs as adjusted above.

[O] the Next_Hop_List created from
[P] the Next_Hop_List is created from

[R] readability.

   Otherwise, the list is set to all the next hops to which the FEC
   would be forwarded.

   The proxy LSR then formats an MPLS Echo Request message. The Global
   Flags and Reply Mode are copied from the Proxy Echo Parameters TLV.
   The Return Code and Return Subcode are set to zero.

   The Sender's Handle and Sequence Number are copied from the remote
   echo request message.

   The TimeStamp Sent is set to the time-of-day (in seconds and
   microseconds) that the MPLS Echo Request is sent. The TimeStamp
   Received is set to zero.

   If the reply-to address TLV is present, it is used to set the echo
   request source address, otherwise the echo request source address is

[O] address, otherwise

[P] address; otherwise

[R] grammar

   set to the proxy request source address.



3.2.4.2.  Per interface sending procedures

   The proxy LSR now iterates through the Next_Hop_List modifying the
   base MPLS Echo Request to form the MPLS Echo Request packet which is
   then sent on that particular interface.

   For each next hop address, the outgoing label stack is determined.

[O] For each next hop address, the outgoing label stack is determined.

[P] The outgoing label stack is determined for each next hop address.

[R] readability

   The TTL for the label corresponding to the FEC specified in the FEC
   stack is set such that the TTL on the wire will be other TTL
   specified in the Proxy Echo Parameters. If any additional labels are
   pushed onto the stack, their TTLs are set to 255. This will ensure
   that the requestor will not have control over tunnels not relevant to
   the FEC being tested.

   If the MPLS proxy ping request message contained Downstream Mapping/
   Downstream Detailed Mapping TLVs, they are examined. If the
   Downstream IP Address matches the next hop address that Downstream

[O] the next hop address that Downstream

[P] the next hop address, that Downstream

[R] grammar

   Mapping TLV is included in the MPLS Echo Request.

   The packet is then transmitted on this interface.



5.1.  Proxy Echo Parameters TLV

 [SNIP[

   Proxy Flags

      The Proxy Request Initiator sets zero, one or more of these flags
      to request actions at the Proxy LSR.

         0x01 Request for FEC Neighbor Address info

            When set this requests that the proxy LSR supply the

[O] When set this requests

[P] When set, this requests

[R] readability

            Upstream and Downstream neighbor address information in the
            MPLS proxy ping reply message. This flag is only applicable
            for the topmost FEC in the FEC stack if the FEC types
            corresponds with a P2MP or MP2MP LSPs. The Proxy LSR MUST
            respond as applicable with a Upstream Neighbor Address TLV
            and Downstream Neighbor Address TLV(s) in the MPLS proxy
            ping reply message. Upstream Neighbor Address TLV needs be
            included only if there is an upstream neighbor. Similarly,
            one Downstream Neighbor Address TLV needs to be included for
            each Downstream Neighbor for which the LSR learned bindings
            from.

[O] for which the LSR learned bindings from.
[P] from which the LSR learned bindings.

[R] readability; I *think* this is what is meant here.

            Setting this flag will cause the proxy LSR to cancel sending
            an Echo request. Information learned with such proxy reply
            may be used by the proxy initiator to generate subsequent
            proxy requests.

         0x02 Request for Downstream Mapping

            When set this requests that the proxy LSR supply a

[O] When set this requests

[P] When set, this requests

[R] readability

            Downstream Mapping TLV see [RFC4379] in the MPLS proxy ping
            reply message. It's not valid to have Request for Downstream
            Detailed Mapping flag set when this flag is set.

[O] It's not valid to have Request for Downstream Detailed Mapping
flag set when this flag is set.

[P] Either this flag may be set or the Request for Downstream Detailed
Mapping flag may be set, but not both.

            Setting this flag will cause the proxy LSR to cancel sending
            an Echo request. Information learned with such proxy reply
            may be used by the proxy initiator to generate subsequent
            proxy requests.

         0x04 Request for Downstream Detailed Mapping

            When set this requests that the proxy LSR supply a

[O] When set this requests

[P] When set, this requests

[R] readability


      Requested DSCP

         This field is valid only if the Explicit DSCP flag is set. If
         not set, the field MUST be zero on transmission and ignored on
         receipt. When the flag is set this field contains the DSCP

[O] When the flag is set this field

[P] When the flag is set, this field

         value to be used in the MPLS Echo Request packet IP header.



5.2.  Reply-to Address TLV

   Used to specify the MPLS Echo Request IP source address. This address
   MUST be IP reachable via the Proxy LSR otherwise it will be rejected.

[O] Proxy LSR otherwise

[P] Proxy LSR; otherwise

[R] grammar



6.  Security Considerations

   The mechanisms described in this document are intended to be used
   within a Service Provider network and to be initiated only under the
   authority of that administration.

   If such a network also carries Internet traffic, or permits IP access
   from other administrations, MPLS proxy ping message SHOULD be
   discarded at those points. This can be accomplished by filtering on
   source address or by filtering all MPLS ping messages on UDP port.

   Any node which acts as a proxy node SHOULD validate requests against
   a set of valid source addresses. An implementation MUST provide such
   filtering capabilities.

   MPLS proxy ping request messages are IP addressed directly to the
   Proxy node. If a node which receives an MPLS proxy ping message via

[O] If a node which receives an MPLS proxy ping message

[P] If a node receives an MPLS...

[R] -- I am not sure what "which" relates to here; either something is
missing in the sentence, or remove the word "which."

if a MPLS Proxy ping request IP source address is not IP reachable by
   the Proxy LSR, the Proxy request MUST NOT be acted upon.

[ 'i' in 'if' should be capitalized ]


W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf