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

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

Hi, Mach,

Many thanks for the prompt response! Glad these are useful -- please find some follow-ups inline.

On Sep 3, 2013, at 11:52 PM, Mach Chen <[e-mail]> wrote:

> Hi Carlos,
> 
> Many thanks for your detailed review and comments!
> 
> Please my reply inline...
> 
>> -----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.
> 
> We are fine to remove the goal of BFD from the Abstract and Introduction section. 

OK.

What about the mention in Section 3.3.1? It says "One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD session..." but this cannot be achieved without I-D.chen-mpls-bfd-enhancement. I think this is not harmful but not too useful either.

> 
>> 
>> 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.
> 
> To solve which problem you refer to here? ( By using the Reply Mode 4 and GAL+GACh)

I meant in a use similar to RFC 6426 actually. See below also.

> 
>> 
>> Also, what's the relationship to RFC 6426 and TLV 16? Another return path?
> 
> TLV 16 is designed to verify the return path, but the return path selection is still a local decision of the egress (in RFC6426, it states the return path MUST be the reverse LSP of a bidirectional LSP) as defined in RFC4379. The Reply Path TLV is designed to specify the return path, they are different and there is no relationship to TLV 16.
> 

I understand. My question is more related to the following scenarios:
If an Echo request with the R global flag is set, and with TLV21 is received, should the response include duplicate redundant information in TLV16 and TLV21?
If an Echo request with the R global flag is set, and with TLV21 specifying a non-reverse LSP of a bidirectional LSP, should the responder honor the MUST of RFC 6426 or the MUST of this document (since they appear to be mutually contradicting)?
Or more generically, should this document build from TLV16 or define its own TLV?

>> 
>> 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.
> 
> Section 2.1, bullet 2 talks about inter-AS; for inter-as LSP, with RFC4379, in order to check the reverse LSP, the LSP Ping has to be initiated from the other end reside in other AS, this may not possible since the other AS may belong to different administrative domain. With this new reply mode, an LSP Ping could detect both the forward and reverse LSP of the bidirectional LSP, or an LSP Ping detects the forward direction of an LSP and the reverse direction of another LSP ( for example, using a deemed workable LSP to send echo request, and specifying a suspect LSP as the return path hence to test it) , the operator does not need to initiate two LSP Pings from both ends separately. The new reply mode is mainly designed to achieve this. 
> 

I am not totally clear on this scenario -- in an inter-as LSP, are you saying that a return LSP is always known from the other AS?
And is this somewhat of a proxy ping functionality?

> Section 2.2 mainly talks about the "Limitations of Existing Mechanisms for Handling Unreliable Return Paths", mention inter-domain is to explain one of the cases where the echo reply cannot be delivered back even with router alert mode. 
> As the draft states, it provides an extra level of deterministic process to deliver the echo reply back by specifying a more deterministic path (e.g., TE LSP).
> 
> "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."
> 
>> 
>> 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.
> 
> Please see my relies in Minor issues part.
> 
>> 
>> 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).
> 
> Indeed, Downstream Mapping mechanics is overkill here for response. 
> 
> Section 4.3 Sending an Echo Reply
> 
> Second Para talks about how to set the destination address that will affect the ECMP path selection.
> 
> How about this?
> 
> Old:
> "When the echo reply is intended to test the return path (the A is not
>   set in the previous received echo request), the destination IP
>   address of the echo reply message MUST never be used in a forwarding
>   decision.  To avoid this problem, the IP destination 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 to 1, the
>   TTL in the outermost label MUST be set to 255."
> 
> New 
> "When the echo reply is intended to test the return path (the A is not
>   set in the previous received echo request), the destination IP
>   address of the echo reply message MUST never be used in a forwarding
>   decision. *In addition, there may be ECMP paths for a specified FEC, in
>   case always select a failure path*, the IP destination address of the
>   echo reply message that is transmitted along the specified return
>   path MUST be set to an address *(random chosen)* 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 to 1, the
>   TTL in the outermost label MUST be set to 255."
> 

I do not think this addresses the issue. First, because that paragraph covers the "A is not set" case, and this is when you are using a destination of 127/8. With a destination of the source of the echo message you can have the same phenomenon. If you send 4 LSP Pings and the fact that they have different source UDP port result in the responder choosing different ECMPs (for a *chosen* FEC), would that confuse more? That should be covered outside of A-bit set vs. not set.

>> 
>> 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.
> 
> Since the echo request carries the source address/identifier of the ingress/initiator, when received a specified return path, the return path should also have the destination address/identifier point to the ingress/initiator , with these two addresses/identifiers, the egress should be able to perform the above check IMHO. 
> 

This seems to assume that the initiator has a single address. If for troubleshooting purposes, an echo is sent with a source address of an interface, and the return path specified is a prefix FEC with a loopback/32 of the same node. How does the responder know it's the same node and not a victim?

>> 
>> 
>> 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 procedures can easily apply to traceroute when only tracing the forward direction; but for reverse direction, the procedures will become complicate, something like proxy traceroute, the egress will be the proxy, more consideration and mechanisms are needed. Thus, we leave it future study.

I did not mean to trace the reverse direction, but rather, perform a regular LSP Trace but specifying the reply path.

> 
>> 
>> 
>>   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)?
> 
> As described in RFC5884, Section 5
> 
> " A BFD session may be established for a FEC associated with an MPLS
>   LSP.  As described above, in the case of PHP or when the egress LSR
>   distributes an explicit null label to the penultimate hop router, or
>   next-hop label allocation, the BFD Control packet received by the
>   egress LSR does not contain sufficient information to associate it
>   with a BFD session."
> 
> Even for bidirectional LSP, only if there are PHP, explicit null label, or next-hop label allocation situations, LSP Ping bootstrapping is needed IMHO. 

I am still concerned about this usage of this draft for BFD bootstrapping.

What is the LSP Ping bootstrap Echo's reply used for? From RFC 5884 (emphasis added by me with "*" markers):

   *On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR*, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  *The egress LSR MAY respond with an LSP Ping Echo
   reply message* that carries the local discriminator assigned by it for
   the BFD session.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.

The responder responds with BFD and *MAY* respond with LSP Ping Echo reply. What do you gain by using this new TLV in the bootstrap? You do not gain anything on the LSP Ping bootstrap side of it.

If, on the other hand, what you gain is that the BFD packets on the return path need to be sent in this specified path, then that functionality is underspecified and should not be called out as something to do. Has the BFD WG looked into this? That needs BFD state and protocol machinery changes, and not something to mention in passing. There are levels of details, like if BFD stores this new return path and then routing or forwarding changes, etc.

And yes, if context is lost on receipt then you need to bootstrap and not use 1hop initialization.

Net-net: I do not see a good reason to keep any BFD mention, this should be a separate piece of work and have BFD WG input. What do you think?

> 
>> 
>>   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?
> 
> Theoretically, PW can be treated as an associated bidirectional LSP, so it's possible to specify another PW other than the reverse PW.
> 
>> 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP control
>> plane (to run LSP Ping)?
> 
> For MPLS-TP (non-control plane), the only difference is the encapsulation, the GAL+GACh can also be used as defined RFC6426. Maybe we could add some text to state this.

Sounds good -- thank you.

>> 
>> 
>> 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?
> 
> RFC 4379 does not explicitly state this, but from procedures it defined, since the echo rely does not carry any FEC stack information, the verification is only for forward direction, not for reverse direction. 
> 
> Maybe it more proper to state: "...and was mainly designed for unidirectional LSPs."
> 

Instead of the design intent, I would call out something similar to you said: not that the echo reply does not carry target FEC stack because that's not correct -- but that "The FEC Stack TLV from the echo request MAY be copied to the reply."

> 
>> 
>>   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.
> 
> We will consider this, it's great if you have some suggested text. 

This is a bit tricky. Note RFC 4379 says by way of example:

   If the Reply Mode in the echo request is "Reply via an
   IPv4 UDP packet with Router Alert", then the IP header MUST contain
   the Router Alert IP option.  If the reply is sent over an LSP, the
   topmost label MUST in this case be the Router Alert label (1) (see
   [LABEL-STACK]).

Which implies that "reply via IPv4 UDP packet with/without RA" does not mean MUST be unlabeled IPv4 packet. If there's an LSP towards source/32, it would go labeled.

> 
>> 
>> 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.
> 
> In Section 3.3.1-3, it defines tunnel (not a particular LSP) to be as the return path, so the return path includes LSP and Tunnel; it seems "Path" is more suitable.
> 

OK, just a suggestion.

>> 
>> 
>>   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?
> 
> Yes.
> 
> Here the IP path refers to pure IP forwarding path, not the LSP.
> 

If I understand these set of rules correctly, this says that when the Reply Path is not found, then the LSP Ping reply can be sent IP unlabeled. Reading Sections 3.2 and 3.3, the Reply Paths field is specified when A is not set.

However, Section 4.3 says:

   When the echo reply is intended to test the return path (the A is not
   set in the previous received echo request), the destination IP
   address of the echo reply message MUST never be used in a forwarding
   decision.  To avoid this problem, the IP destination address of the
   echo reply message that is transmitted along the 

meaning if A is not set, the reply cannot be sent over IP.


By the way, I think that "MUST never" should really be "MUST NOT" in 2119 language.

>> 
>>   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.
> 
> The draft defines:
> "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." 
> 
> I think this definition is straightforward and clear:-) Do you have any suggestion?

One element that is not clear to me is that the path that the LSR sends back the reply depends upon the Reply Mode value. If you are defining in this document a new Reply Mode value, what is "default"? Assuming Reply Mode 1, 2, 3, or 4? Another thing that is not clear is whether default makes any assumptions of labeled versus unlabeled.

> 
>> 
>> 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?
> 
> Of cause, send to wrong LSR is allowable, for this case, the non-default path could be either an IP path or other LSPs (for example, a TE LSP). If there is non-default path, return code 0x0003 should be returned:
> 
>   0x0003        The echo reply was sent successfully using the
>                 specified Reply Path
> 
>> 
>>   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)?
> 
> It's implementation depend.
> 
> RFC 4379 does not specify this;RFC6426 specifies the echo reply MUST be along the reverse direction, but have to use GAL+GACh (application channel mode). 
> 
>> 
>> 3.2. Reply Path (RP) TLV
>> 
>> When reply mode (!= 5) and Reply Path TLV is received, which takes precedence
>> and what is the procedure?
> 
> Per RFC4379, Malformed Error should be returned. 

Does this conflict with the following?

3.2.  Reply Path (RP) TLV

   The Reply Path (RP) TLV is an optional TLV within the LSP Ping
   protocol.


> 
>> 
>> 
>> 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.
> 
> Sometime, using tunnel other that specific LSP is more suitable, for example, when performing a long time ping for an TE LSP (as stated in RFC5884, section 3.2), it could avoid the impact of the changes of LSP ID (e.g.,Make-Before-Break, LSP ID may change, but tunnel ID will not). Another usage is for BFD, it is stated in Section 3.3.1.
> 
> 
> How about this:(new text is in **)
> 
>   The IPv4 RSVP Tunnel sub-TLV is used in the Reply Path TLV to allow
>   the operator to specify a more generic tunnel FEC other than a
>   particular LSP as the return path.  According to the bits set in the
>   Flag field, the egress LSR will then choose an LSP from the specified
>   Tunnel as the return path.  One usage of this generic RSVP Tunnel
>   sub-TLV is for bootstrapping BFD session on an MPLS Tunnel that has
>   primary and secondary LSPs, especially when Make-Before-Break (MBB)
>   is deployed.  The usage is discussed in Section 4.2 of
>   [I-D.chen-mpls-bfd-enhancement]. *Another usage is when LSP Ping is
>   used to periodically verify the control plane against the data plane [RFC5884],
>   using Tunnel other than particular LSP can avoid the impact of LSP changing
>   when MBB is deployed.*
> 
> 
> It may apply to TLV 1, if the WG agree, I am fine to apply this to TLV 1. Then the IANA allocation could be easier. 

I think this should be the other way around.

If this is a functionality that requires a Target FEC Stack definition (like you propose to have an RSVP IPv4 LSP without the LSP ID), then it should be defined for TLV1 and inherited. 

I have concerns that these sub-TLVs apply to TLV21 only.

Now, specifically to the paragraph that you propose: 1. I do not think the BFD case justifies these TLVs. 2. I think that the MBB use case can not only happen on the return way but also on the forward way.

> 
>> 
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |         MUST be zero      |S|P|
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> Further, "primary" and "secondary" are not defined. Which specifications
>> explains what is a primary and a secondary?
> 
> RFC4872 Section 4.2.1 defines the primary and secondary, we will add a reference there. 

This is great as far as the S and P definition. Thank you.

However, RFC 4872 Section 4.1 uses the LSP ID.

> 
>> 
>> 3.3.3. Static Tunnel sub-TLV
>> 
>> Again, why is this not specified for the Echo as well?
> 
> Same as above.
> 

Same as above.

>> 
>> 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"?
> 
> The "A-bit" is as it defined in 3.2, here we just borrow the "A-bit" to indicate whether need to test the return path. The logic here is that since the "A-bit" is to choose an alternate path hence to deliver the echo reply back, test the return path is normally not intention here. And the path could either IP or MPLS path, verify the IP path does not make sense. 

I apologize I still do not understand. The A-bit means Alternate return path. What does "intended to test the return MPLS LSP path" mean? Do you meant "the *default* return path"? With a-bit set, it is also intended to test *a* return path.

> 
>> 
>>   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
> 
> OK.
> 
>> 
>>   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?
> 
> Yes. 

I believe I am getting lost somewhere on this section. When the A-bit is set, that means Alternate non-default path. Is that to apply the default path?

> 
>> 
>> 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?
> 
> Since the draft-ietf-mpls-lsp-ping-ttl-tlv(segment ping) only apply to MS-PW and co-routed bidirectional LSP, hence to make sure the TLL is determined. Specify a different return path other than the reverse path is not workable. IMHO, this draft may not apply to the segment ping.
> 
>> 
>> 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".
> 
> There is no interaction with draft-ietf-mpls-remote-lsp-ping yet. I think this is the result that defining a particular value without the confirmation of IANA other than using TBD. I believe that this issue will be solved by authors, chairs and IANA.
> 
>> 
>> 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?
> 
> "malformed echo" error should be the right choice, a sub-code for unknown reply is better, but the RFC4379 does not specify this behavior. 

Do you need to add a new sub-code?

> 
>> 
>> 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.
> 
> The same situation will happen for Echo Request:-).  Section 2.1 of RFC4379 says:
> 
> "RFC 1122 allocates the 127/8 as "Internal host loopback address" and
>   states: "Addresses of this form MUST NOT appear outside a host."
>   Thus, the default behavior of hosts is to discard such packets.  This
>   helps to ensure that if a diagnostic packet is misdirected to a host,
>   it will be silently discarded."
> 
> So, I think this issue is already solved by RFC4379. 

No. The intent of using a 127/8 destination in the echo request is two-fold:
1. to prevent reaching the Target destination outside the LSP, in an IP-only mode.
2. to allow for traceroute to work, with each hop consuming the datagram.

On the reply, neither of those apply.
1. the LSP Ping reached its intended destination and now you want the reply back
2. no traceroute on the way back.

What does a node do with a reply destined to it, that it did not initiate? Seems also like a security consideration.

> 
>> 
>> 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?
> The same as TLV 16, TLV 21 will reuse all existing and future defined sub-TLVs. Roni also raised this question, we proposed the following text:
> 
> " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
>    are made directly for TLV Type 21, sub-TLVs in these ranges are 
>    copied from the assignments made for TLV Type 1 and kept the same
>    as that for TLV Type 1. All sub-TLVs in these ranges (include existing
>    and future defined) defined for TLV Type 1 apply to TLV Type 21. 
>    Assignments of sub-..."
> 

It is not clear to me which Target FEC stack sub-TLV would apply to TLV21 but not to TLV1.

> 
>> 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?
> 
> The LSP Ping IANA structure has been updated, please refer to: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#downstream-mapping.
> 
> It specifies the 16384-31743 "Specification Required, Experimental RFC needed", and this draft is the Experimental "RFC".
> 
> 
>> 
>> I would include in the IANA instructions details within TLV 1 about the changes
>> and "directly copied" to TLV21.
> 
> I am fine with this.
> 
>> 
>> 
>> 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"
> 
> OK, thanks for the suggestion.
> 
> 
>> 
>> 
>>   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.
> 
> OK, will look through the document to make them consistent with RFC 4379.
> 
>> 
>> 
>>        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).
> 
> OK.
> 
>> 
>>   0x0002        One or more of the sub-TLVs in Reply Path TLV
>>                 was not understood
>> 
>> s/was/were/
> 
> OK.
> 
>> 
>> 
>> 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.
> 
> OK.
> 
>> 
>>  == Unused Reference: 'RFC6426' is defined on line 873, but no explicit
>>     reference was found in the text
> 
> OK.
> 
>> 
>> 
>> I hope these are clear and useful!
> 
> Very useful!
> 
> Many thanks

Thanks to you!

-- Carlos.

> 
> Mach
>> 
>> Thank you,
>> 
>> Carlos Pignataro.
>