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

Leeyoung <leeyoung@huawei.com> Tue, 03 February 2015 17:28 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 BBC971A1ADF; Tue, 3 Feb 2015 09:28:09 -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 tGHqZkV0G9WX; Tue, 3 Feb 2015 09:28:07 -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 ABC4A1A1AE3; Tue, 3 Feb 2015 09:28:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSB18202; Tue, 03 Feb 2015 17:28:04 +0000 (GMT)
Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Feb 2015 17:28:03 +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; Tue, 3 Feb 2015 09:27:54 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt
Thread-Index: AQHQPy8+PnFc7CCv4Eq3OFRtEP+ii5zd6dhwgAGRIwD//6sYUIAAjV0A//97jaA=
Date: Tue, 3 Feb 2015 17:27:53 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C80610@dfweml706-chm>
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> <54D1039A.8030301@labn.net>
In-Reply-To: <54D1039A.8030301@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.186]
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/FmLIg0ZAzeM4R5xB1khz44Gy1aY>
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:28:09 -0000

Lou,

That sounds good to me. I will upload with this change.

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Tuesday, February 03, 2015 11:22 AM
To: Leeyoung
Cc: 'rtg-dir@ietf.org'org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'org'; 'ccamp@ietf.org'org'; Tomonori Takeda; rtg-ads@tools.ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt

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'org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'org'; 'ccamp@ietf.org'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'org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'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'org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'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'org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'org'; '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.
>> Can you explain how the revised text clarifies this point?
>>
>> Thanks,
>> Lou
>>
>>> ....
>