Re: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06
Vishnu Pavan Beeram <vishnupavan@gmail.com> Fri, 11 August 2017 06:37 UTC
Return-Path: <vishnupavan@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711C21321A3; Thu, 10 Aug 2017 23:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58TYFbwenU9Y; Thu, 10 Aug 2017 23:37:09 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F7F132496; Thu, 10 Aug 2017 23:37:08 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id u133so10330117vke.3; Thu, 10 Aug 2017 23:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rif9F/hjOPhPWJ5Uvbb7uof3iV7ztwykrtaFd9R+bHU=; b=kwcNbfelDPjSHP9EFFaWIOnZ4wmttskTnEobFNcKFYvJMYACvAtfTP+JczyoX1UU6P BiUtNi2QNUkG436XH1mjrJFgCjbbbh1KlYWvoYdjP3pGkIvfZyO5Y+OYek4MYJZ3vE8v gvvRlYGn8XZHxx8/u0FnwCazD3RROpltbl/awcmmxKUgU0eX67AjrNCuW1JctAI4t1Tz gmHGQ1/kB5mBv8EkncRjJWagwZ4Bl6wAQJY8/YUBJQ/S2Jdc6GwLn0YjpkvrhzTiEfmQ yITOv4AvrGeCRUbL2s6I95ZO68iYoXH3CvUrLAy/tIJWbjVuG7pGhXAGO+oXGGyArys8 Bsng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rif9F/hjOPhPWJ5Uvbb7uof3iV7ztwykrtaFd9R+bHU=; b=DEQVQUXB8tKfuNCoidGgj91LRvrFrJ2Y8IYpc3Ak5mPZV3z0jpJO3BR+i5LTICYwl5 e/nO/u98civSRh6G78eCQ3EI4qJJWK1XmytczDdJX5RyuR1wfFISAEIRw21SyZJoGpKK tHXeNUCGMzreo5zjJPMKCTxlMtT1J3nTMH+05StXWmwB8YmaAmNh8eabPwe74ldMxPf+ J151p6L29CV/5Tv6RHj1O3Yf5xuXGtxbaS8enEBJZwNOrOHvJTX8v8jDvrnGWy7Q9jgj Av+G/MNVYcQvAHPWRY3c278fuKl3ElY67QhwDSUCAFHbagDnQGfiYZwXwKLLKIw+Y+tl DMWQ==
X-Gm-Message-State: AHYfb5hsLWI45Ll+Ki8VSS6y54hBuK/p3C1h6UGiBrWwQSO/qfmoefwj 86LsJuNK31AFrYvbzyTK/acHMNahcg==
X-Received: by 10.31.79.4 with SMTP id d4mr10030696vkb.194.1502433427922; Thu, 10 Aug 2017 23:37:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.60.74 with HTTP; Thu, 10 Aug 2017 23:37:07 -0700 (PDT)
In-Reply-To: <D5868ED1.B78F3%acee@cisco.com>
References: <D5868ED1.B78F3%acee@cisco.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Fri, 11 Aug 2017 02:37:07 -0400
Message-ID: <CA+YzgTt8TE-EzWbe7M7LAd2iVuB4eDmRm3a9PVbnfJ2o28TpOw@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Routing ADs <rtg-ads@tools.ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "draft-ietf-teas-network-assigned-upstream-label@ietf.org" <draft-ietf-teas-network-assigned-upstream-label@ietf.org>
Content-Type: multipart/alternative; boundary="001a114dfb48c527ba0556748aaa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/WuKcw4r3rAaI6gj0iExw7vOyH0k>
Subject: Re: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2017 06:37:13 -0000
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) <acee@cisco.com> 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 > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > >
- [Teas] RtgDir review: draft-ietf-teas-network-ass… Acee Lindem (acee)
- Re: [Teas] RtgDir review: draft-ietf-teas-network… Vishnu Pavan Beeram
- Re: [Teas] RtgDir review: draft-ietf-teas-network… Acee Lindem (acee)
- Re: [Teas] RtgDir review: draft-ietf-teas-network… Vishnu Pavan Beeram