Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Mon, 18 Apr 2016 09:03:23 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-iro-update-06: 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-pce-iro-update/

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

1. WG Consensus

The Abstract talks about this document resulting from an "informal
survey".  The Shepherd writeup also mentions the survey and how it was
"not unanimous".  However, while the survey itself is mentioned in the
document (10 times in 6 pages!), there is no reference, and more
importantly nothing is mentioned about WG consensus.

What I'm getting to here is the following:  regardless of what the survey
says (or not), this document is on the Standards Track so I expect the
update to be the result of WG consensus.  If the survey is not even
referenced (which is fine with me), then the document should forget about
it and simply point at the updates.  In other words, the survey, like
discussion on the mailing list, seems to have been used as a tool to
reach consensus — no need to repeatedly mention the tool.

I don't think this point raises to the level of a DISCUSS because it
should be an editorial change.  Even though the archives don't provide
much in terms of discussion around this document (or
draft-dhody-pce-iro-survey), I have to assume that it reached this point
because there is in fact consensus on the update.

2. Non conforming implementations

Section 3. (Other Considerations).  Given that other interpretations of
rfc5440 were possible, I think that the considerations in this section
are operational, so renaming may be a good idea.  I would expect that
because this is a Standards Track document that people will eventually
conform to it, so I think that the "RECOMMEND" at the bottom is not
needed.  [I think that's the only rfc2119 key word.]

3. Section 2.1. (Update to RFC 5440): 

a. Where should the new statements be added?  I'm assuming after the
first paragraph.

B. "An abstract node could be a simple abstract node…"  Is there a better
way to define "abstract node" than by using it in the definition?  Maybe
just point to rfc3209.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 18 Apr 2016 17:37:32 +0000

Hi Alvaro, 

Thanks for your comments, see inline... 

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Alvaro Retana
> Sent: 18 April 2016 21:33
> To: The IESG
> Cc: [email-masked]; [email-masked]; pce-
> [email-masked]
> Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-
> update-06: (with COMMENT)
> 
> What I'm getting to here is the following:  regardless of what the
> survey says (or not), this document is on the Standards Track so I
> expect the update to be the result of WG consensus.  If the survey is
> not even referenced (which is fine with me), then the document should
> forget about it and simply point at the updates.  In other words, the
> survey, like discussion on the mailing list, seems to have been used as
> a tool to reach consensus — no need to repeatedly mention the tool.
> 
> much in terms of discussion around this document (or draft-dhody-pce-
> iro-survey), I have to assume that it reached this point because there
> is in fact consensus on the update.
> 
 
[Dhruv]: Reference to the survey document was removed in the last update (based on the AD review). I can reduce the number of times, survey is mentioned, but I do see value in mentioning it in the document. Anyways I will further discuss this point with our shepherd, chairs and AD.   

> needed.  [I think that's the only rfc2119 key word.]

[Dhruv]: Will rename the section to "Operational Considerations". 
What would be a better wording to suggest not to have a mix deployment because of the issue mentioned in the section? 

> a. Where should the new statements be added?  I'm assuming after the

[Dhruv]: Yes, I can add text! 

> 
> B. "An abstract node could be a simple abstract node…"  Is there a
> better way to define "abstract node" than by using it in the
> definition?  Maybe just point to rfc3209.

[Dhruv]: Ok.

Thanks for your review. 

Regards,
Dhruv

> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 18 Apr 2016 17:55:09 +0000

On 4/18/16, 1:37 PM, "iesg on behalf of Dhruv Dhody"
<[email-masked] on behalf of [email-masked]> wrote:

Dhruv:

Hi!

...
>What would be a better wording to suggest not to have a mix deployment
>because of the issue mentioned in the section?

The "RECOMMENDATION" in the text is to conform to the document, not to
avoid mixed deployments.

I think that the rest of the text is mostly ok -- maybe simply focus it on
the potential impact of mixed deployments (see below).

Thanks!

Alvaro.

NEW>
3.  Operational Considerations

   Because of the lack of clarity in RFC 5440, it is possible to encounter
   implementations that always interpret the IRO sub-objects as loose.
When
   these implementations interwork with an implementation conforming to
   this document, the following impact might be seen:

   o  If a non-conforming (to this document) PCC sends an IRO, to a
      conforming (to this document) PCE, then the PCE may unexpectedly
      fail to find a path (since the PCC may think of IRO sub-objects as
      loose hops, but the PCE interprets them as strict hops).

   o  If a conforming PCC sends an IRO containing strict hops to a non-
      conforming PCE, then the PCE may erroneously return a path that
      does not comply with the requested strict hops (since the PCE
      interprets them all as loose hops).  The PCC may check the
      returned path and find the issue or it may end up using an
      incorrect path.