Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT)

[Adam Roach <[e-mail]>]

Thanks! These all look good to me.

/a

On 11/2/17 21:01, Dieter Beller wrote:
> Hi Adam,
>
> my apologies for the late response - it was difficult for me finding 
> time in the last weeks to address the IESG review comments.
>
> Please find inline below how we suggest to address your comments.
>
> Could you please let us know whether your comments are adequately 
> addressed.
>
>
> Thanks,
> Dieter and co-authors
>
>
> On 30.08.2017 07:42, Adam Roach wrote:
>> Adam Roach has entered the following ballot position for
>> draft-ietf-teas-lsp-diversity-08: 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 tohttps://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-teas-lsp-diversity/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> The Abstract should stand on its own; and, as such, needs to expand the "XRO"
>> and "EXRS" acronyms (similar to the Introduction).
>
> Changed as suggested:
>
> This document specifies two new diversity subobjects for the RSVP 
> eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject 
> (EXRS).
>
>
>> For completeness, the definition of the "E" flag in section 2.1 probably needs
>> to indicate that bit 0x08 is reserved, and MUST be set to 0 send, ignored on
>> receipt.
>
> Changed as suggested:
>
> 0x08 = reserved
>
> This flag is reserved. It MUST be set to zero on transmission, and 
> MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO subobjects.
>
>
>
>> In section 3.2, on page 19, concerning the following text:
>>
>>        If, subsequent to the initial signaling of a diverse LSP, the
>>        requested exclusion constraints for the diverse LSP are no longer
>>        satisfied and an alternative path for the diverse LSP that can
>>        satisfy those constraints exists, then:
>>
>> The phrasing "no longer satisfied" seems a bit incomplete, as (by my
>> understanding) the constraints might not have been satisfied in the first
>> place, if the L-bit was set in the initial request. I presume that, if this
>> were to happen, you'd want to signal when a compliant path became available --
>> but the current text doesn't indicate that this is okay. Perhaps something
>> like: "...are no longer satisfied (or, in the case that the initial request
>> triggered a "Failed to satisfy Exclude Route" error subcode, remain
>> unsatisfied), and an alternative path for..."
>>
> Here is the re-phrased text:
>
> If, subsequent to the initial signaling of a diverse LSP, an
> excluded path referenced in the XRO subobject becomes known to
> the processing node, or a change in the excluded path becomes
> known to the processing node, the processing node MUST re-
> evaluate the exclusion and diversity constraints requested by the
> diverse LSP to determine whether they are still satisfied.
>
> -   In case the L-flag was not set in the initial setup message,
>    the exclusion and diversity constraints were satisfied at the
>    time of the initial setup. If the processing node re-evaluating
>    the exclusion and diversity constraints for a diverse LSP
>    detects that the exclusion and diversity constraints are no
>    longer met, it MUST send a PathErr message for the diverse LSP
>    with the error code "Routing Problem" (24) and error sub-code
>    "Route blocked by Exclude Route" (67). The Path_State_Removed
>    flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a
>    PathErr message with this error code and sub-code combination
>    SHOULD take appropriate actions and move the diverse LSP to a
>    new path that meets the original constraints.
>
> -   In case the L-flag was set in the initial setup message, the
>    exclusion and diversity constraints may or may not be satisfied
>    at any given time. If the exclusion constraints for a diverse
>    LSP were satisfied before and if the processing node re-
>    evaluating the exclusion and diversity constraints for a
>    diverse LSP detects that exclusion and diversity constraints
>    are no longer met, it MUST send a PathErr message for the
>    diverse LSP with the error code error code "Notify Error" (25)
>    and error sub-code TBA5 "Failed to satisfy Exclude Route"
>    (value: to be assigned by IANA). The PSR flag MUST NOT be set.
>    The source node MAY take no consequent action and keep the LSP
>    along the path that does not meet the original constraints.
>    Similarly, if the exclusion constraints for a diverse LSP were
>    not satisfied before and if the processing node re-evaluating
>    the exclusion and diversity constraints for a diverse LSP
>    detects that the exclusion constraints are met, it MUST send a
>    PathErr message for the diverse LSP with the error code "Notify
>    Error" (25) and a new error sub- code TBA6 "Compliant path
>    exists" (value: to be assigned by IANA). The PSR flag MUST NOT
>    be set. A source node receiving a PathErr message with this
>    error code and sub-code combination MAY move the diverse LSP to
>    a new path that meets the original constraints.
>
>