[RTG-DIR] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06

["Acee Lindem (acee)" <[e-mail]>]

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