Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT)

[Stewart Bryant <[e-mail]>]

And we're now redoing the OWAMP/TWAMP protocols ... This is kind of sad that there is no alignment. At the very minimum, in the terminology and concepts.
 From RFC 5357

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


Something I already mentioned to the RFC 6374 authors in the past when doing my OPS-DIR review. Sigh...

SB> That is water that passed under the bridge a long time ago.


  Anyway, please engage in the discussion regarding Eric Vyncke's OPS DIR review:
This short I-D is quite clear and easy to understand, security & manageability sections are correct. I found nothing in this framework document which could cause operational issues EXCEPT:

     as I am unsure of the usual PLDM procedures, what is the expected behavior when a PLDM message (incl a URO) is received by a PLDM node which does not support this object type? If it is well defined in PLDM, then there is no problem of course.


SB> Section 3.5 or RFC6374 states:

    "Upon receipt of a query message including an unrecognized mandatory
    TLV object, the recipient MUST respond with an Unsupported Mandatory
    TLV Object error code."

SB> That the error case is well handled in the base protocol.

  Can a reply be fragmented? Should the reply contains the DF bit for IPv4? Probably worth mentioning what to do over fragmentation.

SB> Given the short size of the messages, I cannot imagine this will ever happen but in any case
SB> I cannot see why fragmentation at the IP layer would introduce any particular problem.

  What is the expected behavior when the URO contains an IPv6 address and the PLDM responder only has IPv4 address(es)?

SB> I have updated the text as follows to address this point:

When the requested return path is an IP forwarding path and this method is in use, the destination IP address and UDP port is copied from the URO. The source IP address and the source UDP Port of Response packet is left to discretion of the Responder subject to the normal management and security considerations. If the Querier has included URO(s) for only one IP address family and a return path of that type is not available, then the query message MUST be discarded, and the operator SHOULD be informed of the error through the management system using the normal rate limited approach. If the Responder is configured to only respond with a single response, and a path using the IP address family in the first URO is not available, the Responder MAY search the UROs for the first URO specifying a return address family for which it does have a path, and use the parameters in that URO to respond. If the responder is designed or configured not to search for a URO that it can respond to,  then the operator SHOULD be informed of the error through the management system using the normal rate limited approach.

Small nits:

     in introduction, I guess you meant "internally be forwarded" rather than "internally forwarded"

SB> Fixed

     Section 4.3, when selecting the source address, you may want to refer to RFC 6724

SB> Surely the router is either aware of this or in is not and in either case it is really part of the IP service in the router rather than a part of this protocol.