Re: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06

[Vishnu Pavan Beeram <[e-mail]>]

Acee, Hi!

Much Thanks for the review. We (the authors) just posted a new rev (-07) to
address the all the nits identified below. Please do go over the diffs (
https://tools.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-07.txt
) and let us know if there are any further concerns.

Regards,
-Pavan (on behalf of the authors)

On Sat, Jul 8, 2017 at 1:29 PM, Acee Lindem (acee) <[e-mail]> wrote:

> 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
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>