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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 11 Aug 2017 02:37:07 -0400

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) <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 11 Aug 2017 10:38:28 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 11, 2017 at 2:37 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Routing ADs <[email-masked]<mailto:[email-masked]>>, Routing Directorate <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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,

On Sat, Jul 8, 2017 at 1:29 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> 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.

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

--- 160,166 ----

***************
*** 226,237 ****

--- 272,278 ----

***************
*** 284,290 ****

  4.  Acknowledgements

--- 306,320 ----

  4.  Acknowledgements

***************
*** 358,364 ****

Thanks,
Acee

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 11 Aug 2017 07:00:14 -0400

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) <[email-masked]> 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 <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Routing ADs <[email-masked]>, Routing Directorate <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> 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,
>> considered “well-known” as defined in https://www.rfc-editor.org/mat
>> erials/abbrev.expansion.txt
>>