Proxy MPLS Echo Request
RFC 7555

Note: This ballot was opened for revision 04 and is now closed.

(Adrian Farrel) (was Discuss, Yes) Yes

Comment (2015-03-25)
No email
send info
Thanks for addressing IANA's concerns (my Discuss) and for picking up the Comments.

(Jari Arkko) No Objection

Comment (2015-03-05 for -04)
No email
send info
Thanks for writing this document, and for working through issues raised
in the Gen-ART review.

There was still a couple of questions in the review that I also looked into,
and after reading the text in question, I also do not know the answer to.
Perhaps some clarifications would be useful? Or otherwise, maybe there
is some other explanation that at wasn't obvious to me.

---

2. Section 3.2.1, third paragraph, second sentence currently reads:

  "If the Proxy LSR is a budnode, 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 and DS/DDMAPs only if the Proxy initiator requested information to
   be returned in a MPLS proxy ping reply."

Do you mean that the DS/DDMAP TLV is included only if the initiator
asked for it (which seems like redundant advice) or do you mean that the
reply is sent only if the initiator asked for the DS/DDMAP information?

3. Same paragraph, next sentence: why SHOULD rather than MUST? What is
the exception?

4. Section 3.2.1, last paragraph (dealing with MP2MP case): the second
to fourth sentences read:

"LSP pings sent from a leaf of a MP2MP has
   different behavior in this case. MPLS Echo Request are sent to all
   upstream/downstream neighbors. The Proxy LSRs need to be consistent
   with this variation in behavior."
s/has/have/ to get that out of the way.

Do you mean that the initiator is a leaf of the MP2MP? How does the
Proxy LSR know this? Does it matter?

(Alia Atlas) No Objection

Comment (2015-03-03 for -04)
No email
send info
I wish this draft had both a picture or two to show the message paths and had something that clearly showed what fields were copied and which generated and what the conditions were for the various message replies.

I don't have concerns about the details of the text - but it is hard to pull the full picture together of what is happening.
Sadly, I'm not expecting changes now.

(Richard Barnes) No Objection

Comment (2015-03-04 for -04)
No email
send info
+1 on diagrams.

(Benoît Claise) No Objection

Comment (2015-03-05 for -04)
No email
send info
That always makes me a sad when I see OAM technologies developed in silo.
At least, existing OAM terminology and concepts should be reused. At the minimum, a mapping should be explained.
Why? Because this is what network operators will have to do: here is yet another OAM technology they have to learn and integrate, how does it fit with the existing OAM tools? Note that LIME was created with that goal in mind. Anyway, I'm getting sidetracked: this issue is actually an issue for the IESG, not for this document. Hence a COMMENT and not a DISCUSS.

For example, RFC 5357

         +----------------+               +-------------------+
         | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
         +----------------+               +-------------------+
           ^                                     ^
           |                                     |
           |                                     |
           |                                     |
           |  +----------------+<----------------+
           |  |     Server     |
           |  +----------------+
           |    ^
           |    |
           | TWAMP-Control
           |    |
           v    v
         +----------------+
         | Control-Client |
         +----------------+


I've been trying to modify this picture with the concepts/terminology in this draft. So I contemplated the following definitions for some time (and read the text around it obviously)...

     Initiator - the node which initiates the ping operation by sending
      an MPLS Proxy Ping Request message

      Proxy LSR - the node which is the destination of the MPLS Proxy
      Ping Request message and potential initiator of the MPLS Echo
      Request

      Receiver(s) - the nodes which receive the MPLS Echo Request
      message

      Responder - A receiver that responds to an MPLS Proxy Ping Request
      or an MPLS Echo Request

   We note that in some scenarios, the initiator could also be the
   responder, in which case the response would be internal to the node.

... and I gave up.

As mentioned by the Alia, Brian, Richard, without a diagram this is really not easy.
Let me quote Alia's COMMENT: "Sadly, I'm not expecting changes now."
I guess (and trust your routing AD) that the draft is fine from OPS point of view!

Spencer Dawkins No Objection

Comment (2015-03-04 for -04)
No email
send info
It's a nit, but in this text:

   It is anticipated that very large Point-to-Multipoint and Multipoint-
   to-Multipoint (MP2MP) Label Switched Paths will exist. 
   
I'm not understanding what dimension "very large" is conjuring up. Is this bandwidth, or length, or something else?

(Stephen Farrell) No Objection

Comment (2015-03-05 for -04)
No email
send info
- the security considerations seems to use the term "proxy
node" when "proxy lsr" is used (there and) elsewhere. Maybe
that could do with a bit of clean up? In particular the 3rd
last para is unclear as to which node is meant in the 2nd
sentence. (Or it wasn't clear to me at least.)

(Brian Haberman) No Objection

Comment (2015-03-03 for -04)
No email
send info
I agree with Alia's assessment that a diagram or two would have made the document much easier to understand.

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-03-04 for -04)
No email
send info
The security considerations looks good, thanks for that.  

I don't see a response on the SecDir review.  The comments are mainly ones that might help a reader less familiar with the space as there are a few requests for clarifying details.
https://www.ietf.org/mail-archive/web/secdir/current/msg05454.html

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection