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

[Stewart Bryant <[e-mail]>]

On 05/01/2016 03:10, Alvaro Retana wrote:
> 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.
This text only considers operation when the URO is used.

There are no procedures specified on how to use the address object in 
RFC6374, and
if anyone every writes them (which I honestly doubt) they will be 
responsible
for the disambiguation of the proceedures.

> 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?

It is not updating it in the formal IETF sense, it is adding an extra 
mechanism, but in that
latter sense it is updating the protocol.

>
> * 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).

I have added the following text which should resolve any ambiguity:

To prevent any ambiguity as to which address the Responder needs to 
reply to, an MPLS-PLDM message containing a URO MUST NOT include an 
RFC6374 Return Address TLV (TLV 1). Additionally, the method of 
constructing the return address from the Source Address TLV (TLV 130) 
described in Section 3.5.2 of RFC6374 MUST NOT be used to construct to 
an Query message that contains a URO.
>
> * 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..
Indeed, but I cannot see any interoperability issues.
>
> * 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.
Hopefully the additional text resolves the ambiguity.

>
> * Small nit from the text quoted above in section 4.2: the response may
> in fact not go back to the querier.
>
I cannot see the problem with the text, but of course the response may not
go back to the querier. That is a design intention.

>
> 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."

It now says SHOULD
>       * What happens the URO is received in a query that doesn't have the
> correct Control Code?
It follows the error handling in RFC6374, and responds using the URO. Do 
you think
that this is ambiguous?
>
> 2. Section 3.1. (UDP Return Object)
>       * What happens if the URO contains an address not supported by the
> receiver?

This would be a normal misdelivery-discard. There is now some additional
security text about being more careful with the address you use, but if you
configure a wrong address the packet will go in the bit bucket as normal.

>       * "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?

I think that this a matter for the implementer. There is no interoperability
issue that I can see.

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

- Stewart