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

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

Acee, Hi!

Rev -08 takes care of these two items (I didn't feel like keeping these
pending).

https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-08

Regards,
-Pavan

On Fri, Aug 11, 2017 at 6:38 AM, Acee Lindem (acee) <[e-mail]> wrote:

> Hi Pavan,
> It looks good to me. I generally capitalize words that expand into
> acronyms, e.g., Label Switched Path (LSP) and Wavelength Division
> Multiplexing (WDM). Also, you are missing one comma in section 3.2 –
> replace “preemption etc.” with “preemption, etc.”
> Thanks,
> Acee
>
> From: Vishnu Pavan Beeram <[e-mail]>
> Date: Friday, August 11, 2017 at 2:37 AM
> To: Acee Lindem <[e-mail]>
> Cc: Routing ADs <[e-mail]>, Routing Directorate <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> Subject: Re: [Teas] RtgDir review: draft-ietf-teas-network-
> assigned-upstream-label-06
>
> 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/mat
>> erials/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
>>
>>
>