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

From: Dieter Beller <[email-masked]>
Date: Thu, 2 Nov 2017 14:01:04 +0100

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

---

From: Adam Roach <[email-masked]>
Date: Sat, 11 Nov 2017 13:14:25 +0800

Thanks! These all look good to me.

/a

On 11/2/17 21:01, Dieter Beller wrote:
> 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
>
>
>> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> This document specifies two new diversity subobjects for the RSVP 
> eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject 
> (EXRS).
>
>
> 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.
>
>
>
> If, subsequent to the initial signaling of a diverse LSP, an
> evaluate the exclusion and diversity constraints requested by the
>    time of the initial setup. If the processing node re-evaluating
>    longer met, it MUST send a PathErr message for the diverse LSP
>    flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a
>    exclusion and diversity constraints may or may not be satisfied
>    diverse LSP with the error code error code "Notify Error" (25)
>    (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
>    Similarly, if the exclusion constraints for a diverse LSP were
>    detects that the exclusion constraints are met, it MUST send a
>    PathErr message for the diverse LSP with the error code "Notify
>    exists" (value: to be assigned by IANA). The PSR flag MUST NOT
>    error code and sub-code combination MAY move the diverse LSP to