Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt
Lou Berger <lberger@labn.net> Tue, 03 February 2015 17:23 UTC
Return-Path: <lberger@labn.net>
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 8CC3A1A6EE8 for <ccamp@ietfa.amsl.com>; Tue, 3 Feb 2015 09:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 HhLs88xbHuEe for <ccamp@ietfa.amsl.com>; Tue, 3 Feb 2015 09:23:07 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id C89231A3BA1 for <ccamp@ietf.org>; Tue, 3 Feb 2015 09:23:07 -0800 (PST)
Received: (qmail 4851 invoked by uid 0); 3 Feb 2015 17:23:03 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 3 Feb 2015 17:23:03 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ntMa1p00B2SSUrH01tMdvi; Tue, 03 Feb 2015 10:21:45 -0700
X-Authority-Analysis: v=2.1 cv=NPZGpSKg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=Vhvw94NMJWsA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=0HtSIViG9nkA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=CyRW7yT0AAAA:8 a=hgIBC_BEqxCIUh3y30cA:9 a=nD5RYZfzY6wZS5Vn:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=FMqkjLkjl2If+ICGyAsTg+YwwoGmKqGl+HlpS/BwXJ0=; b=tgO1PegvMCQwmd0pk1YI2VjGx8utPyX9bp45GHfot3bpSBWmXXBNcHdTzgFBudV/VuuiIbxSVwvbp8oAjTvs6wH7wHZmAh/EtaD4Nh8tzUiW8Cvd+c1W2S4hBysdbGPF;
Received: from box313.bluehost.com ([69.89.31.113]:46347 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1YIhAM-00041F-8E; Tue, 03 Feb 2015 10:21:34 -0700
Message-ID: <54D1039A.8030301@labn.net>
Date: Tue, 03 Feb 2015 12:21:30 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>
References: <EB0F2EAC05E9C64D80571F2042700A2A6C46DC@C0010I0.coe.ntt.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <EB0F2EAC05E9C64D80571F2042700A2A6C5EEF@C0010I0.coe.ntt.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> <EB0F2EAC05E9C64D80571F2042700A2A6C6FF6@C0010I0.coe.ntt.com> <54CFEC08.7010304@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C80259@dfweml706-chm> <54D0D43E.1010702@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C805B8@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C805B8@dfweml706-chm>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/iLlowbMZIyzJcs9DxMO6rFMfC4o>
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>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "'ccamp@ietf.org'" <ccamp@ietf.org>, Tomonori Takeda <tomonori.takeda@ntt.com>
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: Tue, 03 Feb 2015 17:23:10 -0000
Young, I think we're close, but lets tighten up the language a bit. On 2/3/2015 12:08 PM, Leeyoung wrote: > Lou, > > OK, How about: > > OLD > > ... There may be more than one matrix associated with > a node as the node can partition the switch matrix into several sub- > matrices for various reasons such as incremental updates, etc. When > the matrix is partitioned into sub-matrices, it is envisioned that > they are mutually exclusive to one another in representing which > ports/labels are associated with each sub-matrix. This implies that > two matrices will not have the same {src port, src label, dst port, > dst label}. > > Each sub-matrix is assigned a unique Matrix ID to represent a > mutually exclusive set of {src port, src label, dst port, dst label} > from other sub-matrices. > > NEW: > > ... There may be more than one matrix associated with > a node as the node can partition the switch matrix into several sub- > matrices for various reasons primarily to limit the size of any > individual information element used to represent the matrix or allow > incremental updates, etc. When the matrix is partitioned into > sub-matrices, it is envisioned that they are mutually exclusive to > one another in representing which ports/labels are associated with > each sub-matrix. This implies that two matrices will not have the > same {src port, src label, dst port, dst label}. > > Each sub-matrix is assigned a unique Matrix ID to represent a > mutually exclusive set of {src port, src label, dst port, dst label} > from other sub-matrices. How about: There may be more than one Field associated with a node as a node can partition the switch matrix into several sub- matrices. This partitioning is primarily to limit the size of any individual information element used to represent the matrix and to enable incremental updates. When the matrix is partitioned into sub-matrices, each sub-matrix will be mutually exclusive to one another in representing which ports/labels are associated with each sub-matrix. This implies that two matrices will not have the same {src port, src label, dst port, dst label}. Each sub-matrix is identified via a different Matrix ID which MUST represent a unique combination of {src port, src label, dst port, dst label}. Lou > Would this be Ok with you? Then I will publish a revision upon your approval. Also we need to hear from Tomonori on if his issues is addressed. Thanks, Lou > Thanks, > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, February 03, 2015 7:59 AM > To: Leeyoung > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org'; Tomonori Takeda; rtg-ads@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt > > Young, > > I guess I didn't see the new text as substantively different or more > informative than preceding text: > > ... There may be more than one matrix associated with > a node as the node can partition the switch matrix into several sub- > matrices for various reasons such as incremental updates, etc. When > the matrix is partitioned into sub-matrices, it is envisioned that > they are mutually exclusive to one another in representing which > ports/labels are associated with each sub-matrix. This implies that > two matrices will not have the same {src port, src label, dst port, > dst label}. > > I'd suggest directly addressing the ambiguity by revising the first > sentence and "for various reasons such as incremental updates, etc. " in > particular. Perhaps "primarily to limit the size of any individual > information element used to represent the matrix." or however else > you'd like to capture the intent. > > Lou > > On 2/2/2015 5:15 PM, Leeyoung wrote: >> Hi Lou, >> >> The original question Tomonori raised was if sub-matrices are like virtual nodes attached to connectivity matrix. The answer was no, and sub-matrix is simply a partition of connectivity matrix into smaller pieces. To that end, I added the following text in Section 2.1 >> >> Each sub-matrix is assigned a unique Matrix ID to represent a >> mutually exclusive set of {src port, src label, dst port, dst label} >> from other sub-matrices. >> >> Let me know what you think. >> >> Thanks, >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Monday, February 02, 2015 3:29 PM >> To: Leeyoung >> Cc: Tomonori Takeda; rtg-ads@tools.ietf.org; '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 Young, >> >> I see you just published an update. I have one question below. >> >> On 1/23/2015 3: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. >> Can you explain how the revised text clarifies this point? >> >> Thanks, >> Lou >> >>> .... >
- [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