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

"Alvaro Retana" <aretana@cisco.com> Tue, 05 January 2016 03:10 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B71ACED8; Mon, 4 Jan 2016 19:10:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alvaro Retana" <aretana@cisco.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160105031027.29211.97181.idtracker@ietfa.amsl.com>
Date: Mon, 04 Jan 2016 19:10:27 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/_Et5mwm1DHyEwuBofy7CvMakojU>
Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org
Subject: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 03:10:27 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-rfc6374-udp-return-path-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The text related to when the URO is used of not clear, and I think it
could even result in technical incompatibility.  I don't think that this
main concern raises to the level of a DISCUSS since it should be resolved
easily (but it might be close).  In short, it is not completely clear
when the URO should be considered in light of the rules in RFC6374; it is
not completely clear if the rules in RFC6374 always take precedence. 
Here are the specifics of my concern:

Section 4.2. (Receiving an MPLS PM Query Request) says that "in addition"
to the processing in RFC6374, "with a URO present, then the responder
SHOULD use that IP address and UDP port to send MPLS-PLDM response back
to querier."  RFC6374 says that the "Source Address of a query message
SHOULD be used as the destination for an out-of-band response unless some
other out-of-band response mechanism has been configured, and unless a
Return Address object is present, in which case the Return Address
specifies the target of the response."  Several questions/observations:

* What does the phrase "in addition" mean in 4.2?  I'm interpreting it as
adding rules to what RFC6374 says.  IOW, this document seems to be
updating what RFC6374 says (or at least adding extra rules if the URO is
present).  Is that the intent?

* As far as I can tell, there is no restriction for having both a Return
Address object and the URO in the same query, right?  If so, and if the
intent is *not* to update RFC6374, then it seems (from the text in
RFC6374) that the URO would never be used (if a Return Address object is
also present).

* Nitpicking a little at the meaning/interpretation of "configuration". 
RFC6374 mentions (from above) "some other out-of-band response mechanism
has been configured", but as you imply in (i.e as I interpret) Section 5.
(Manageability Considerations) the mechanism in this document is
signaling, not configuration:  "Nothing in this document precludes the
use of a configured UDP/IP return path in a deployment in which
configuration is preferred to signalling."   Yes, you could configure the
system to prefer the URO signaling..  

* The point with all this is that it is not clear what exactly is meant,
and that the current text can result in more than one (defensible)
interpretation.

* Small nit from the text quoted above in section 4.2: the response may
in fact not go back to the querier.



I have a couple of other minor comments:

1. Section 3. (Solution Overview)  says (in the first sentence) that if
the URO "is present in a MPLS-PLDM Query, the responder MUST use the IP
address and UDP port in the URO to reply back to the querier".   Clearly
related to the comments above, but also an incomplete statement: as
explained in 4 and 4.1, the Control Code should also be set to
"Out-of-band Response Requested".  Comments/questions:
     * [Nit] I don't think there's anything explicitly wrong with that
first sentence, but it just doesn't sound right because of the
conditional MUST ("unless configured otherwise").  You might want to
consider something like this instead:  "This document specifies that if
the  Control Code of the MPLS-PLDM query is set to "Out-of-band Response
Requested", and a UDP Return Object (URO) is present in a MPLS-PLDM
Query, the responder SHOULD use the IP address and UDP port in the URO to
reply back to the querier."
     * What happens the URO is received in a query that doesn't have the
correct Control Code?

2. Section 3.1. (UDP Return Object)
     * What happens if the URO contains an address not supported by the
receiver?
     * "The URO MUST NOT appear in a response."  What should the receiver
do if it does?  Should it ignore the URO or the whole datagram?

3. s/MPLS-PM (and MPLS PM)/MPLS-PLDM