Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt

Leeyoung <leeyoung@huawei.com> Mon, 02 February 2015 21:09 UTC

Return-Path: <leeyoung@huawei.com>
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 E0B4F1A1A46; Mon, 2 Feb 2015 13:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ck39CBqOKn3s; Mon, 2 Feb 2015 13:09:36 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D321A036F; Mon, 2 Feb 2015 13:09:33 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOR77395; Mon, 02 Feb 2015 21:09:31 +0000 (GMT)
Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 21:09:30 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 13:09:25 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Lou Berger'" <lberger@labn.net>, "'Tomonori Takeda'" <tomonori.takeda@ntt.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt
Thread-Index: AQHQNyua4bPWa0fjYUSk1DJvggIdkZzN6UpAgACQuAD//3pWcIAQUeuA//+kGeA=
Date: Mon, 2 Feb 2015 21:09:25 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C80204@dfweml706-chm>
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> <011d01d03f17$413d52c0$c3b7f840$@olddog.co.uk>
In-Reply-To: <011d01d03f17$413d52c0$c3b7f840$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.141.14]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/sSud8l1OmHuGHgqFdyjKPqO3X24>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org" <draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org>, "ccamp@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
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 21:09:41 -0000

Hi Adrian and Lou,

Updated (v.18) with a set of clarifying text on sub-matrix and bidirectional link sets. 

http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/

Thanks,
Young

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Monday, February 02, 2015 12:37 PM
To: Leeyoung; '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

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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; '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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; '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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; '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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; '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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; 'ccamp@ietf.org'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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; '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'org'; 'draft-ietf-ccamp-general-constraint-
> encode.all@tools.ietf.org'#39;; '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
> >>