On 4/18/16, 1:37 PM, "iesg on behalf of Dhruv Dhody"
<[email protected] on behalf of [email protected]> wrote:
Dhruv:
Hi!
...
>> 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.]
>>
>
>[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?
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.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
