RSVP-TE Path Diversity Using Exclude Route
draft-ietf-teas-lsp-diversity-10

[Ballot comment]
* Section 2.1
  Is there a separate diversity identifier type called "IPv6 Client Initiated Identifier" as referenced in the following text

"When the diversity identifier type is set to "IPv6 Client Initiated Identifier""

If there isn't such a DI Type, can you please fix this text.

[Ballot comment]
I'm not sure that the security considerations here are accurate. Specifically, the PAS seems like it might potentially leak information about paths, because if I am able to learn someone else's PAS values, I can tell if they are routed along the same paths as I am. Is that correct? If so, it seems like it might be useful to recommend self-encrypting PAS values so that two identical paths given to separate people have different PAS values.

Also, it seems like it S 2.3 would be clearer if you factored out the algorithm for processing the XRO values from the differential treatment depending on the L bit. Perhaps you could just have one list and use [SHOULD (L=1), MUST(L=0)] or something?

[Ballot comment]
I support Adam's position. I also think that Ignas Bagdonas' OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-teas-lsp-diversity-08-opsdir-lc-bagdonas-2017-08-30/ ) needs careful consideration / addressing. I almost balloted DISCUSS from them, but trust that they will be addressed.

I did find much of the document well written and an easy read. The diagrams were also (surprisingly) clear.

I have some nits / comments, mainly around the abstract.
1:  "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"  - s/ReserVation/ReSerVation/ (otherwise the (R)RSVP would be (R)RVP)

2: " Three different mechanisms are supported how LSP diversity can be accomplished in the provider or core network: ..." - this doesn't really parse. Perhaps " Three different
mechanisms providing LSP diversity in the provider or core network are supported:..." ? Not great, but ...

3: "The solution described in this document is based on the assumption that LSPs are requested sequentially, i.e., the time period between the LSP setup requests for the two LSPs may be longer (days, weeks, months)." -- may be longer than what? Perhaps "may be relatively long" or "may be on the order of days / weeks / months"?

4" "Re-routing the first LSP that may have existed for a longer period of time is not considered." - again, longer than what? Longer than the second (/ Ntn)? Longer than months?

[Ballot comment]
The Abstract should stand on its own; and, as such, needs to expand the "XRO" and "EXRS" acronyms (similar to the Introduction).

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.

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

[Ballot comment]
From the abstract: "Three different
mechanisms are supported how LSP diversity can be accomplished in
the provider or core network:..."

Is there a missing word around "... supported how..."?

[Ballot comment]
I’m looking at this text,

          0x04 = Penultimate node exception
 
              Indicates that the penultimate node of the LSP being
              signaled MAY be shared with the excluded path even when
              this violates the exclusion flags.

and wondering whether you could either provide some recommendation about doing this/not doing this, or give an example of why doing this/not doing this makes operational sense. The other exceptions do make sense to me, so I’m only curious about this one.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-teas-lsp-diversity-08. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete.

First, on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-parameters/

the EXCLUDE_ROUTE object is C-Type 232. However, the current draft references C-Type 1.

IANA Question --> Are the two registrations requested in section 4.1 intended to be inserted in the Sub-Object types subregistry for the Class Types or C-Types - 232 EXCLUDE_ROUTE registry?

Second, in the Sub-object type - 20 EXPLICIT_ROUTE ? Type 1 Explicit Route subregistry of the Class Types or C-Types - 20 EXPLICIT_ROUTE registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-parameters/

two new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: IPv4 Diversity subobject
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: IPv6 Diversity subobject
Reference: [ RFC-to-be ]

We note that the values used for these two registrations are requested to be the same values used in the registration for the request in Section 4.1 of the current draft.

Third, in the Sub-Codes - 24 Routing Problem subregistry of the Error Codes and Globally-Defined Error Value Sub-Codes registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-parameters/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: Unsupported Diversity Identifier Type
Reference: [ RFC-to-be ]

Fourth, in the Sub-Codes - 225 Notify Error subregistry of the Error Codes and Globally-Defined Error Value Sub-Codes registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-parameters/

three, new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: Route of XRO LSP identifier unknown
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Failed to satisfy Exclude Route
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Compliant path exists
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-08-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-teas-lsp-diversity@ietf.org, lberger@labn.net, teas-chairs@ietf.org, teas@ietf.org, db3546@att.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route) to Proposed Standard


The IESG has received a request from the Traffic Engineering Architecture and
Signaling WG (teas) to consider the following document: - 'Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
  Diversity using Exclude Route'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Resource ReserVation Protocol-Traffic Engineering provides support
  for the communication of exclusion information during label switched
  path (LSP) setup. This document specifies two new diversity
  subobjects for the RSVP XRO and EXRS subobjects. Three different
  mechanisms are supported how LSP diversity can be accomplished in
  the provider or core network: the signaled diversity type, indicates
  whether diversity is based on client, path computation engine (PCE),
  or network assigned identifiers.
  The solution described in this document is based on the assumption
  that LSPs are requested sequentially, i.e., the time period between
  the LSP setup requests for the two LSPs may be longer (days, weeks,
  months). Re-routing the first LSP that may have existed for a longer
  period of time is not considered.

 



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1943/
  https://datatracker.ietf.org/ipr/2383/

gt; disclosures.

IPR has been disclosed.  It has been repeatedly pointed out on the
TEAS and CCAMP (where this work started) lists. No one has raised
any specific concerns with the existence or relevance of these
disclosures. 

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

strong concurrence, largely by contributors.  There are no objections.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

Not with the current version. 

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

None.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

None required/apply.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

None.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

None.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

Yes.

>
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The Shepherd conducted an full review of the section, and suggested
changes to the section that were made prior to publication
request. No new registries are created.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

N/A.

17/21:
ibryskin at advaoptical.com/i_bryskin at yahoo.com
  https://www.ietf.org/mail-archive/web/teas/current/msg01365.html   
origerstel at gmail.com
  https://www.ietf.org/mail-archive/web/teas/current/msg01364.html

Still missing:
  ogondio at tid.es
  fu.xihua at zte.com.cn
  Ruediger.Kunze at telekom.de
  Lieven.Levrau at nokia.com

2nd poll started June 5: https://www.ietf.org/mail-archive/web/teas/current/msg01348.html
directed to:
ibryskin@advaoptical.com/i_bryskin@yahoo.com
Daniele.Ceccarelli@ericsson.com
dhruv.ietf@gmail.com
ogondio@tid.es
don.fedyk@hp.com
cfilsfil@cisco.com
fu.xihua@zte.com.cn
ggalimbe@cisco.com
origerstel@gmail.com
mhartley@cisco.com
ke-kumaki@kddi.com
Ruediger.Kunze@telekom.de
Lieven.Levrau@nokia.com
cyril.margaria@gmail.com
julien.meuric@orange.com
tochio@jp.fujitsu.com
zhang.xian@huawei.com
zali@cisco.com
Dieter.Beller@nokia.com
swallow@cisco.com
zhangfatai@huawei.com

IPR response 13 of 21: Don Fedyk: Yes I'm aware of IPR that applies to the draft. The IPR that I'm aware of has been disclosed in compliance with IETF IPR rules.

(sent to WG list but not visible in list archive for some reason)

IPR response 1 of 21: Kenji Kumaki: https://mailarchive.ietf.org/arch/msg/teas/OVh0dr7-X8GxWPqXoq6WUCv_owg
IPR response 2 of 21: Dhruv Dhody: https://mailarchive.ietf.org/arch/msg/teas/lY9W-fXa5Va3aOcBloL9akI8128
IPR response 3 of 21: Fatai Zhang: https://mailarchive.ietf.org/arch/msg/teas/_CpXn9PiyjxIvznhUQVaevXI6bY
IPR response 4 of 21: Daniele Ceccarelli: https://mailarchive.ietf.org/arch/msg/teas/mrIbYYjwXDFmiVfBki7gzUx1tU8
IPR response 5 of 21: Gabriele Galimberti: https://mailarchive.ietf.org/arch/msg/teas/6UJXzp-T_u7FHPfJbd3Fny341mw
IPR response 6 of 21: Clarence Filsfils: https://mailarchive.ietf.org/arch/msg/teas/s1XYmZTaV4X6JHrbt1jvaqfTaAw
IPR response 7 of 21: Dieter Beller: https://mailarchive.ietf.org/arch/msg/teas/Ftrbn8rdNsnt-IiPd6cgCvoeXmU
IPR response 8 of 21: Zafar Ali: https://mailarchive.ietf.org/arch/msg/teas/bPfSITI6vxBA_XlUFk7XDqLovWE
IPR response 9 of 21: Xian Zhang: https://mailarchive.ietf.org/arch/msg/teas/wHc0K8kgjsD-Arz3RRFUie-Wnts
IPR response 10 of 21: Matt Hartley: https://mailarchive.ietf.org/arch/msg/teas/cDzsDcw8gti8oY4XH_zM1Njk19E