[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
- [mpls] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana
- Re: [mpls] Alvaro Retana's No Objection on draft-… Stewart Bryant
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana (aretana)