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

Stewart Bryant <> Thu, 07 April 2016 12:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9BE112D825; Thu, 7 Apr 2016 05:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IvuSNg2hQ3N7; Thu, 7 Apr 2016 05:07:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EB0E12D810; Thu, 7 Apr 2016 05:07:21 -0700 (PDT)
Received: by with SMTP id l6so22506136wml.1; Thu, 07 Apr 2016 05:07:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=lvn9ful5xEwJ0ePdz5+gyHmG5hDUKtFBsWV2UH2qNL8=; b=CEdp0zwW0VH00A0hCpoctsA/tcnZQ4mpJevh2/HVSc6+CRx3jtn8BInCludU/OTLoB mF973A0sfusHo71Gvxu887zrDRM2CnNclXeuEL0q63qEg3D36HQblfxd0OZLTlH7j1At jtC7mOHN3lULKYk4w3ah3o5agOgiUOVdEoZt3CJ5ztcWS0+nRZqBiU69V2aparKPy0Al 0NVl7xC47ceXMlh3AgWIyeDMHghWqpC7qQoah8j7u2JTvHVVFbh1xUJeazCDacAxJUrY VAmyj0gApvsSYGGrJ9/Bozv1YFCalX0+C6O9/TQ5rc7tvB+u8Udi1XMmOWwCMNHDMZvf 8Q/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=lvn9ful5xEwJ0ePdz5+gyHmG5hDUKtFBsWV2UH2qNL8=; b=mwy3dVIFjUSni+VPvW3iGgGD+9ku0RKFRPmFJV3mwTX0pv2CQk75gmqvNGjpmf0M1w ccV5uRYQZg4hDug2EPQwJA7Dpvq3s4SJxbYyKdBZk6E25oyGHLsaEJf4s5K/IrZ+1R0m Lbg+s+i58XE8p0zH79gAxxf2+4jmw/AWXm0LGtKll92jqXNTnDhhvhz3JMO+X/AqonNN pV/4Ep1UO4M6fIwrwcxQU84Wf6X/VdJYb8hd1VyHix3R9HmqO/3XZ9PXHDGHTzp42h22 4pv/7cAMusy+AQTZ/smAfsToVz3rSChLZ28wX/brrzPDkT4rsvMygPSXsBBPIvtfo44V E8XA==
X-Gm-Message-State: AD7BkJLSpBhirMjTbPGUGRV67va9h8G98PytVwRvVxZV++BZDNuGevMqzsRLZB0Tx8782g==
X-Received: by with SMTP id p1mr3295200wje.87.1460030839961; Thu, 07 Apr 2016 05:07:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id cb2sm8200106wjc.16.2016. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 05:07:18 -0700 (PDT)
To: Benoit Claise <>, The IESG <>
References: <>
From: Stewart Bryant <>
Message-ID: <>
Date: Thu, 7 Apr 2016 13:07:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------010901050207020501000102"
Archived-At: <>
Subject: Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Apr 2016 12:07:27 -0000

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.