Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-teas-network-assigned-upstream-label-06 Reviewer: Acee Lindem Review Date: July 8th, 2017 IETF LC End Date: Completed – Submitted to IESG for publication Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: The document provides an extension to GMPLS RSVP Bi-directional LSP upstream label assignment which supports negotiation of the upstream label. This is accomplished by the upstream router specifying a special value, 0xFFFFFFFF, in the UPSTREAM_LABEL object and a set of candidate labels in the LABEL_SET object of the PATH message. The downstream router will select an appropriate label from the LABEL_SET labels and returns it in the LABEL object of the corresponding RESV message. The document is generally well organized and written. The technical solution is both straight-forward and complete. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: 1. Expand acronyms on first usage. For example, LSP and WDM are not considered “well-known” as defined in https://www.rfc-editor.org/materials/abbrev.expansion.txt 2. Suggested Editorial Changes: *** draft-ietf-teas-network-assigned-upstream-label-06.txt.orig 2017-07-08 12:12:18.000000000 -0400 --- draft-ietf-teas-network-assigned-upstream-label-06.txt 2017-07-08 12:55:57.000000000 -0400 *************** *** 127,138 **** 2. Unassigned Upstream Label This document proposes the use of a special label value - ! "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned Upstream Label. Similar "all-ones" patterns are expected to be used for labels of other sizes. The presence of this value in the UPSTREAM_LABEL object of a PATH message indicates that the upstream node has not assigned an upstream label on its own and has requested ! the downstream node to provide a label that it can use in both forward and reverse directions. The presence of this value in the UPSTREAM_LABEL object of a PATH message MUST also be interpreted by the receiving node as a request to mandate symmetric labels for the --- 127,138 ---- 2. Unassigned Upstream Label This document proposes the use of a special label value - ! "0xFFFFFFFF" (for a 4-octet label) - to indicate an Unassigned Upstream Label. Similar "all-ones" patterns are expected to be used for labels of other sizes. The presence of this value in the UPSTREAM_LABEL object of a PATH message indicates that the upstream node has not assigned an upstream label on its own and has requested ! the downstream node to provide a label that it can use in both the forward and reverse directions. The presence of this value in the UPSTREAM_LABEL object of a PATH message MUST also be interpreted by the receiving node as a request to mandate symmetric labels for the *************** *** 160,166 **** Label in the PATH message even after it receives an appropriate symmetric label in the RESV message. This is done to make sure that the downstream node would pick a different symmetric label if and ! when it needs to change the label at a later point in time. If the --- 160,166 ---- Label in the PATH message even after it receives an appropriate symmetric label in the RESV message. This is done to make sure that the downstream node would pick a different symmetric label if and ! when it needs to change the label at a later time. If the *************** *** 226,237 **** Internet-Draft Network Assigned Upstream-Label June 2017 ! router send signal into the optical network unless it is at the appropriate wavelength. In other words, having the router send ! signal with a wrong wavelength may adversely impact existing optical trails. If the clients do not have full visibility into the optical network, they are not in a position to pick the correct wavelength ! up-front. The rest of this section examines how the protocol mechanism proposed in this document allows the optical network to select and communicate --- 226,237 ---- Internet-Draft Network Assigned Upstream-Label June 2017 ! router send the signal into the optical network unless it is at the appropriate wavelength. In other words, having the router send ! signals with a wrong wavelength may adversely impact existing optical trails. If the clients do not have full visibility into the optical network, they are not in a position to pick the correct wavelength ! in advance. The rest of this section examines how the protocol mechanism proposed in this document allows the optical network to select and communicate *************** *** 272,278 **** o The downstream node (Node F) receives the PATH message, chooses the appropriate wavelength values and forwards them in appropriate ! label fields to the egress client ("Router B") --- 272,278 ---- o The downstream node (Node F) receives the PATH message, chooses the appropriate wavelength values and forwards them in appropriate ! label fields to the egress client ("Router B"). *************** *** 284,290 **** o "Router B" receives the PATH message, turns the laser ON and tunes it to the appropriate wavelength (received in the UPSTREAM_LABEL/ ! LABEL_SET of the PATH) and sends out a RESV message upstream. o The RESV message received by the ingress client carries a valid symmetric label in the LABEL object. "Router A" turns on the --- 284,290 ---- o "Router B" receives the PATH message, turns the laser ON and tunes it to the appropriate wavelength (received in the UPSTREAM_LABEL/ ! LABEL_SET of the PATH message) and sends a RESV message upstream. o The RESV message received by the ingress client carries a valid symmetric label in the LABEL object. "Router A" turns on the *************** *** 306,318 **** After the LSP is set up, the network may decide to change the wavelength for the given LSP. This could be for a variety of reasons ! - policy reasons, restoration within the core, preemption etc. In such a scenario, if the ingress client receives a changed label ! via the LABEL object in a RESV modify, it retunes the laser at the ! ingress to the new wavelength. Similarly, if the egress client ! receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH ! modify, it retunes the laser at the egress to the new wavelength. 4. Acknowledgements --- 306,320 ---- After the LSP is set up, the network may decide to change the wavelength for the given LSP. This could be for a variety of reasons ! including policy reasons, restoration within the core, preemption, ! etc. In such a scenario, if the ingress client receives a changed label ! via the LABEL object in a modified RESV message, it retunes the laser ! at the ingress to the new wavelength. Similarly, if the egress client ! receives a changed label via UPSTREAM_LABEL/LABEL_SET in a modified ! PATH message, it retunes the laser at the egress to the new ! wavelength. 4. Acknowledgements *************** *** 358,364 **** semantics of a specific field in an existing RSVP object and the corresponding procedures. Thus, there are no new security implications raised by this document and the security considerations ! put together by [RFC3473] still applies. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. --- 360,366 ---- semantics of a specific field in an existing RSVP object and the corresponding procedures. Thus, there are no new security implications raised by this document and the security considerations ! discussed by [RFC3473] still apply. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. Thanks, Acee