Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt
"Adrian Farrel" <adrian@olddog.co.uk> Mon, 02 February 2015 18:37 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EA61A884E; Mon, 2 Feb 2015 10:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
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 It3Tq__m4fQP; Mon, 2 Feb 2015 10:37:19 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C311A87A9; Mon, 2 Feb 2015 10:37:18 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t12IbA5T030639; Mon, 2 Feb 2015 18:37:10 GMT
Received: from 950129200 (089144215032.atnat0024.highway.a1.net [89.144.215.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t12Ib84J030613 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 18:37:09 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Leeyoung' <leeyoung@huawei.com>, 'Lou Berger' <lberger@labn.net>, 'Tomonori Takeda' <tomonori.takeda@ntt.com>, rtg-ads@tools.ietf.org
References: <EB0F2EAC05E9C64D80571F2042700A2A6C46DC@C0010I0.coe.ntt.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <EB0F2EAC05E9C64D80571F2042700A2A6C5EEF@C0010I0.coe.ntt.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> <EB0F2EAC05E9C64D80571F2042700A2A6C6FF6@C0010I0.coe.ntt.com> <54C279EE.3070200@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C7E063@dfweml706-chm> <54C28342.8040606@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C7E0BA@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E0BA@dfweml706-chm>
Date: Mon, 02 Feb 2015 18:37:07 -0000
Message-ID: <011d01d03f17$413d52c0$c3b7f840$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHf3fFwHIohxEP+64swMOaqflviLAG+Thr2AhpxmwsB55H6vwH0UPS1AqpUmUECcLI06gHUAM8FAiXsnlycOCUdAA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21300.001
X-TM-AS-Result: No--39.460-10.0-31-10
X-imss-scan-details: No--39.460-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtGXKs94NAOH8ru9iqQJLR0vk8UlXQzLGby2F4a+vI22PkoX KBbeyLpPTWLw2jvbfpwQIIqVNQDiwQkSzeMXko3JlVHM/F6YkvSp7eIcybi6odJgDNnoqapa++3 gQ26tbbjuzcUA0q2gBTeT288mssTUC4+rppBRJ3bDr0AjBcmfRhZO94uK1VSBX5ol8zUEkXx5LC y5OWaU1Fulu2xVUpYqQnGWzKenedTDkHnJwIRKWxVXx+49zfW31kqyrcMalqWsafcFLFlU1HENj fFARL3nCtOd6Fi7KxAopAQlzvHAh3qSLwsG0mU0EPf7TDUOGopTes6dDCWUQxL6MU7t349blrmn v6uGqHH1uSXrxAlVTKQPGNuwxITiXBtzGjIuBpn6daZahG7qsQeCHewokHM/LzNBnatH86nrvMp CIr/ArJTR8dO1sjyqBK/0EBgIJCIlVaqTQ2WNXPzu9Lw9C7fAo8tN19oTXleJ6icw2HMxEJYnCY jfX1IRERiBVxMZi/F+R+CMyT2S945S/4bo68Nb2OSj4qJA9QYYrnuRn/aZqQ2G3vz8l/IEFM7Yd tmBCGh3250SfQPJ3UaFycOdfe/ZxAFMYEMzeR1u4W5gEinK6UDwlkRNC6PCyL0CMroLynVY7aa4 /f753JxiKuuiWeaODXt87zYS/45R6DT7jy4uvXBRIrj8R47FGW6TfocNCnuX1RWcrwojHBFxevg Hxu1O2s6JOBmw1fKNqIq1NZDvDhnQcX6X6WNYeP1J5vpgPKfHeXKrbMIpACzUMV4ULgLdN1SzVL YnI7pq1c7VkTNDaZSY3T4pUgS4B7wMVHvtNz2eAiCmPx4NwFkMvWAuahr8p2c3EY8h4cmrusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/LsBAAnJvUCjkl-UYOwOtYVFFawg>
Cc: rtg-dir@ietf.org, draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org, ccamp@ietf.org
Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 18:37:23 -0000
I think that the bottom line of this thread was a new revision clarifying sub-matrix and bidirectional link sets. Then (hopefully) we're done. Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 23 January 2015 17:25 > To: Lou Berger; Tomonori Takeda; rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org' > Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > > Lou, > > I can add some clarifying text in the next revision. > > Thanks, > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, January 23, 2015 11:22 AM > To: Leeyoung; Tomonori Takeda; rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org' > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > > Young, > > On 1/23/2015 11:51 AM, Leeyoung wrote: > > Hi Lou, > > > > Are you referring 'any specific language changes' to Adrian's 'Resource' > language? > Actually, no. > > If so, yes, I expect Adrian's input on where to place any changes in the draft. > Other than that I believe the version 17 (which was published) reflects > Tomonori's rtg-dir review. Let me know if you believe any other aspect (other > than 'resource' language) should be updated in the upcoming version 18. > > I may have misunderstood the thread below, but I read it as there are > two areas in -17 that should be clarified. > > Thanks, > Lou > > > Thanks, > > Young > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Friday, January 23, 2015 10:42 AM > > To: Tomonori Takeda; Leeyoung; rtg-ads@tools.ietf.org > > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org' > > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > > > > Young, > > Can you review any changes planned as a result of the rtg-dir review? > > Please also include any specific language changes, that you may have > > already identified. > > > > Thanks, > > Lou (as doc Shepherd) > > > > On 01/23/2015 03:01 AM, Tomonori Takeda wrote: > >> Hi Young, > >> > >> OK, thanks, > >> > >> Tomonori > >> > >> -----Original Message----- > >> From: Leeyoung [mailto:leeyoung@huawei.com] > >> Sent: Thursday, January 22, 2015 2:44 AM > >> To: Tomonori Takeda(武田知典); Leeyoung; rtg-ads@tools.ietf.org > >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org' > >> Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > >> > >> Hi Tomonori, > >> > >> Thanks for your comment. Please see in-line for my response. Please let me > know if the response would satisfy you. > >> > >> Best regards, > >> Young > >> > >> -----Original Message----- > >> From: Tomonori Takeda [mailto:tomonori.takeda@ntt.com] > >> Sent: Wednesday, January 21, 2015 12:48 AM > >> To: Leeyoung; rtg-ads@tools.ietf.org > >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org'; Tomonori Takeda > >> Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > >> > >> Hi Young, > >> > >> Thanks. > >> > >> Two follow-up questions/comments. > >> (I am fine with other points, which you already addressed in the updated > draft.) > >> > >>> 2) In section 2.1, it says "two matrices will not have the same {src port, src > label, dst port, dst label}". To be precise, I guess this should be > "two matrices > will not have the same {src port, src label}, and two matrices will not have the > same {dst port, dst label}"? > >>> > >>> YOUNG>> I think your suggestion may be too restrictive. For instance, if we > have one source (port 1) and one destination (port 2) with two labels > each. > Then we would have: {(1,1,2,1), (1,1,2,2), (1,2,2,1), (1,2,2,2)} I think with the > current statement, we can send this info in any combination > of multiple > matrices, which I think perfectly fine. With your suggestion, I would not be able > send (1,1,2,1) and (1,1,2,2) together. Why would this > not be made possible? My > take is as long as each submatrix represents a set of disjoint quadruples, that > should be allowed. > >> My reading of "two matrices will not have the same {src port, src label, dst > port, dst label}" is as follows. > >> > >> <Example A> > >> > >> input port=1 --> Submatrix#1 --> output port=2 > >> input label=1 output label=1 > >> > >> input port=1 --> Submatrix#2 --> output port=2 > >> input label=1 output label=2 > >> > >> This is allowed. > >> > >> <Example B> > >> > >> input port=1 --> Submatrix#1 --> output port=2 > >> input label=1 output label=1 > >> > >> input port=1 --> Submatrix#2 --> output port=2 > >> input label=1 output label=1 > >> > >> This is not allowed. > >> > >> <Example C> > >> > >> input port=1 --> Submatrix#1 --> output port=2 > >> input label=1 output label=1 > >> > >> input port=1 --> Submatrix#2 --> output port=2 > >> input label=2 output label=2 > >> > >> This is allowed. > >> > >> Is above understanding correct? > >> If so, I am not sure how example A works, since I am not sure what is the > indentifier to direct from input to each submatrix. > >> > >> Maybe I am mis-understanding what sub-matrix is. I thought sub-matrix is a > sort of virtual node, splitting the single matrix (or switch) into smaller pieces. > >> > >> YOUNG>> OK, I think the definition of submatrix was not clear. It is simply > dividing up a matrix into several pieces in case the size of the matrix becomes too > big or a way to advertize the changed port/label set in one place (sub-matrix) > then other unchanged port/label set in other place (different sub-matrix). The > identifier for each sub-matrix is the MATRIX ID. There is not separate identifier to > direct from input. The input is a part of the sub-matrix. Say if we have N*M > matrix that describes all input and output port/label. We might divide up into > N*(M-L) and N*L or any other combinations as far as they are all disjoint from > each other. > >> > >>> 4) In section 2.1, for Link Set A dir=bidirectional, Link Set B dir=bidirectional, if > any signal on an input link X is output on a link Y, then any > signal on an input link > Y is output on a link X (after cross-connect)? Or any constraint on such signal flow > (after cross-connect) is out of scope? > >>> > >>> <YOUNG>> I am not sure what "after cross-connect" is meant. > >> <Example> > >> > >> Link set A: link#1, link#2, link#3 > >> Link set B: link#4, link#5, link#6 > >> > >> Both of Link set A and Link set B are specified as "dir". > >> > >> In this case, > >> - Is it possible to problem the cross-connect as input=link#1, output=link#4 > >> & input=link#5, output=link#1 simultaneolusly? > >> - Or is it automatically assumed if input=link#1, output=link#4, > >> then input=link#4, output=link#1? > >> - Or this sort of constraint is not specified in Link Set Field? > >> > >> The text seems like saying the first option, but I do not think this is a common > equipment implementaion. > >> > >> YOUGN>> OK. I think I understand you more clearly. For this case > (bidirectional link sets), the first case is definitely not the intention. The second > case is assumed. > >> > >> Thanks, > >> Tomonori > >> > >> -----Original Message----- > >> From: Leeyoung [mailto:leeyoung@huawei.com] > >> Sent: Tuesday, January 20, 2015 7:54 AM > >> To: Tomonori Takeda(武田知典); rtg-ads@tools.ietf.org > >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org' > >> Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > >> > >> Hi Tomonori, > >> > >> Thanks for providing good comments. Here's my response. Please see in-line. > >> > >> Regards, > >> Young > >> > >> -----Original Message----- > >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Tomonori Takeda > >> Sent: Saturday, January 17, 2015 7:59 AM > >> To: rtg-ads@tools.ietf.org > >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint- > encode.all@tools.ietf.org'; 'ccamp@ietf.org' > >> Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint- > encode-16.txt > >> > >> 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-ccamp-general-constraint-encode-16.txt > >> Reviewer: Tomonori Takeda > >> Review Date: 17 January, 2015 > >> IETF LC End Date: 17 January, 2015 > >> Intended Status: Standards Track > >> > >> Summary: > >> > >> This document is basically ready for publication, but has nits that should be > considered prior to publication. > >> > >> Comments: > >> > >> This document specifies protocol-agnostic encodings for general information > elements described in draft-ietf-ccamp-rwa-info. > >> I think the document is in good shape but there are a few points that should > be clarified for better understanding. > >> > >> Major Issues: > >> > >> None > >> > >> Minor Issues: > >> > >> None > >> > >> Nits: > >> > >> 1) In section 1.2, label continuity constraint (e.g., wavelength continuity in > WSON) is mentioned. However, I am not sure whether information elements for > which this document specifies encodings can describe such constraint. My > reading is that information element such as Port Label Restriction is rather for > describing wavelength tuning capabilities/restrictions. > >> > >> YOUNG>> Label continuity constraints can be inferred from the two places in > the draft: (i) Port Label Restriction, which gives the set of labels (wavelengths) > that may not be available on certain links including tuning range/restriction; (ii) > Available/Shared Backup Label Fields (section 2.4 & section 2.5). There is no > encoding for label continuity constraint per se. The aforementioned constraints > are encoded to give a node or a PCE to be able to compute a path (i.e., path with > wavelength continuity) subject to these constraints. > >> > >> 2) In section 2.1, it says "two matrices will not have the same {src port, src > label, dst port, dst label}". To be precise, I guess this should be "two matrices will > not have the same {src port, src label}, and two matrices will not have the same > {dst port, dst label}"? > >> > >> YOUNG>> I think your suggestion may be too restrictive. For instance, if we > have one source (port 1) and one destination (port 2) with two labels each. Then > we would have: {(1,1,2,1), (1,1,2,2), (1,2,2,1), (1,2,2,2)} I think with the current > statement, we can send this info in any combination of multiple matrices, which I > think perfectly fine. With your suggestion, I would not be able send (1,1,2,1) and > (1,1,2,2) together. Why would this not be made possible? My take is as long as > each submatrix represents a set of disjoint quadruples, that should be allowed. > >> > >> 3) In section 2.1, it says "The value of 0xFF is reserved for use with port > wavelength constraints". I think "port wavelength constraints" should be "port > label restriction". > >> > >> YOUNG>> Yes, thanks. > >> > >> 4) In section 2.1, for Link Set A dir=bidirectional, Link Set B dir=bidirectional, if > any signal on an input link X is output on a link Y, then any signal on an input link Y > is output on a link X (after cross-connect)? Or any constraint on such signal flow > (after cross-connect) is out of scope? > >> > >> YOUNG>> I am not sure what "after cross-connect" is meant. > >> > >> 5) In section 2.2.1, it says "In this case the accompanying label set indicates the > labels permitted on the port." I think "port" should be "port/matrix". > >> > >> YOUNG>> Yes, thanks. > >> > >> 6) In section 2.2.2, it would be better to describe the type (e.g., integer) for > MaxNumChannels. > >> This also applies for MaxLabelRange (in section 2.2.3) and Num Labels (in > section 2.6). > >> > >> YOUNG>> OK. > >> > >> 7) In section 2.6, it says "Label Set Field is used within the <AvailableLabels> or > the <SharedBackupLabels>". But I think Label Set Field is also used within > SIMPLE_LABEL, LABEL_RANGE and SIMPLE_LABEL & CHANNEL_COUNT. > >> > >> YOUNG>> Yes, it is used in multiple places. > >> > >> How about: > >> OLD: Label Set Field is used within the <AvailableLabels> or the > >> <SharedBackupLabels>, which is defined in Section 2.4. and 2.5., > >> respectively. > >> NEW: Label Set Field is used within the <AvailableLabels> or the > >> <SharedBackupLabels>, which is defined in Section 2.4. and 2.5., > >> respectively. It is also used within the <SIMPLE_LABEL>, > >> <LABEL_RANGE>, <SIMPLE_LABEL> or <CHANNEL_COUNT>, which is > defined > >> in Sections 2.1.1 - 2.1.4, respectively. > >> > >> > >> Thanks, > >> Tomonori > >>
- [CCAMP] RtgDir review: draft-ietf-ccamp-general-c… Tomonori Takeda
- [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Gregory Mirsky
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Tomonori Takeda
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Tomonori Takeda
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Lou Berger
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Lou Berger
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Adrian Farrel
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Lou Berger
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Lou Berger
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Lou Berger
- Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-c… Leeyoung