Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

Leeyoung <leeyoung@huawei.com> Thu, 30 January 2014 00:20 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 A48041A041C for <ccamp@ietfa.amsl.com>; Wed, 29 Jan 2014 16:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.175
X-Spam-Level:
X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, T_HTML_ATTACH=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 9W0-e_N-vMmH for <ccamp@ietfa.amsl.com>; Wed, 29 Jan 2014 16:20:29 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD221A041D for <ccamp@ietf.org>; Wed, 29 Jan 2014 16:20:27 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAP65126; Thu, 30 Jan 2014 00:20:22 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 00:19:43 +0000
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 00:20:18 +0000
Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 16:20:07 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-rwa-info@tools.ietf.org" <draft-ietf-ccamp-rwa-info@tools.ietf.org>
Thread-Topic: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
Thread-Index: AQHPFhk5SibPPk0qa0SourRWd8AFq5qQ+nOAgApR5oCAARMoMA==
Date: Thu, 30 Jan 2014 00:20:06 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BB4EC9@dfweml706-chm.china.huawei.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFDBB.4020504@labn.net> <7AEB3D6833318045B4AE71C2C87E8E17291E1BD8@dfweml511-mbs.china.huawei.com> <52DD7E93.1000805@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729BB4511@dfweml706-chm.china.huawei.com> <52E830A5.2050301@labn.net>
In-Reply-To: <52E830A5.2050301@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.140.163]
Content-Type: multipart/mixed; boundary="_003_7AEB3D6833318045B4AE71C2C87E8E1729BB4EC9dfweml706chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
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: Thu, 30 Jan 2014 00:20:41 -0000

Hi Lou,

Please see inline for my resolution to your comments. 

Attached is working version of draft-ietf-ccamp-rwa-info-20 and idnit results that indicate no issue found with the draft.

Let me know if this is ready to publish.

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Tuesday, January 28, 2014 4:35 PM
To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

Young,

See below.

On 1/27/2014 6:46 PM, Leeyoung wrote:
> Hi Lou,
> 
> Here's my comments to your comments. Please see inline for detail. Enclosed is a working draft that reflects all the changes per your comments.
> Let me know if this is ready to be published.
> 
> Thanks,
> Young
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Monday, January 20, 2014 1:53 PM
> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org
> Subject: Re: [CCAMP] WG Last Call: WSON documents - 
> draft-ietf-ccamp-rwa-info
> 
> Young, (all),
> 
> Now that the IPR issues are resolved on the document set, it's time to get these documents published.
> 
> There are few minor items in this document.
> 
> On 11/7/2013 5:32 PM, Leeyoung wrote:
>> Hi Lou,
>>
>> Here's my response to specific comments to draft-ietf-ccamp-rwa-info. 
>>
>> Thanks.
>> Young
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, October 29, 2013 1:26 PM
>> To: CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org
>> Subject: Re: [CCAMP] WG Last Call: WSON documents - 
>> draft-ietf-ccamp-rwa-info
>>
>>
> ...
> 
>>
>> YOUNG>> [Switch] moved to normative reference section.
> 
> A normative reference to a a journal paper, are you sure?  I would have just changed the language to make it informative, but it's your call.
> (Unless the RFC editor chimes in on it...)
> 
>>
> ...
> 
> YOUNG>> It was a mistake I think that took place while I was shifting some references around. I will put [Switch] back to informative reference section. 
> 
>>
>> - Section 5: I found it hard to parse the following:
>>    As resources are the smallest identifiable unit of
>>    processing resource, one can group together resources into blocks if
>>    they have similar characteristics relevant to the optical system
>>    being modeled, e.g., processing properties, accessibility, etc.
>>   Do you perhaps mean?
>>    A resource is the smallest identifiable unit of
>>    allocation. One can group together resources into blocks if
>>    they have similar characteristics relevant to the optical system
>>    being modeled, e.g., processing properties, accessibility, etc.
>>
>> YOUNG>> Agreed. Changed.
> 
> I think you have a bad cut and paste.
> 
> s/resource./allocation.
> 
> YOUNG>> Agree. Done. "A resource is the smallest... allocation...."
> 
>> -Section 5.1: States: " Note that except for <ResourcePoolState>
>>   all the other components of <ResourcePool> are relatively static."
>>   But the related definitions are:
>>
>>    <ResourcePool> ::= <ResourceBlockInfo>...
>>    [<ResourceAccessibility>...] [<ResourceWaveConstraints>...]
>>    [<RBPoolState>] (section 5)
>>
>>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePoolState>] (section 
>> 7.2)
>>
>>    What's the intent here?
>>
>> YOUNG>> See the cleaned text in Section 7.2:
>>    Currently the only node information that can be considered dynamic
>>    is the resource pool state and can be isolated into a dynamic node
>>    information element as follows:
>>
>>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePool>]
>>
>>    Where
>>
>>    <ResourcePool> ::= <ResourceBlockInfo>...[<RBPoolState>]
> 
> sorry, I didn't mean for you to incorporate the <ResourcePool> 
> definition into the document.  this was just for our discussion.  I 
> don't think adding a duplicate/incomplete definition here is the right 
> thing.  So I'd drop it (starting with Where.)
> 
> YOUNG>> OK. "Where..." is dropped. Also changes in Section 5.1: 
> Original: <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> <InAvailableWavelengths> <OutAvailableWavelengths>)...
> Changed:  <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> 
> [<InAvailableWavelengths>] [<OutAvailableWavelengths>])*
> 

As was the case below, an asterisk isn't valid RBNF, so shouldn't be in this line.

Also recall that parentheses implies strict ordering. Perhaps you mean:
<RBPoolState> ::= <ResourceBlockID> <NumResourcesInUse> 		
		[<InAvailableWavelengths>] [<OutAvailableWavelengths>]
		[<RBPoolState>]

YOUNG>> This works for me. Thanks. 

> As <InAvailableWavelengths> <OutAvailableWavelengths> are only used in the cases of shared input or output access to the particular block.
> 
> 
> 
>>
>>
>> - Section 5.2: What is the asterisk "*" all about.
>>
>> YOUNG>> That means whatever within () can be repeated. 
>>
> 
> I don't recall this syntax definition in BNF/RBNF. Take a look at http://tools.ietf.org/html/rfc5511#section-2.2.5.
> 
> YOUNG>> Yes, I replaced "*" with "..." (per 2.2.5) which means 'repetition.' 
> 

So you now have:
   <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints>
   [<ProcessingCapabilities>] <OutputConstraints>)...

That's fine, but keep in mind that use of parenthesis implies ordering.
Do you mean:

   <ResourceBlockInfo> ::= [<ResourceSet>] <InputConstraints>
		   [<ProcessingCapabilities>] <OutputConstraints>
		   [<ResourceBlockInfo>]

Actually since the use of <ResourceBlockInfo> already indicates repetition in section 5, no  repetition is needed here, which yields

   <ResourceBlockInfo> ::= [<ResourceSet>] <InputConstraints>
		   [<ProcessingCapabilities>] <OutputConstraints>

YOUNG>> This works well. In light of the next comment (with a consistent naming with encode draft, the following is agreed: 

<ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] [<ProcessingCapabilities>] [<OutputConstraints>]

> Also you list [<ResourceSet>] as optional, yet it is mandatory in 
> section 4.1 of
> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-23
> 
> YOUNG>> <ResourceSet> is optional. I don't think section 4.1 of wson-encode-23 treats this as mandatory. Wson-encode-23 document simply provides encoding details irrespective of whether it is mandatory or optional. Let me know if you disagree with this. 
> 

So 4.1 of wson-encode-24 you just distributed says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|O|                         Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Optical Interface Class List(s) (opt)          |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Acceptable Client Signal Type (opt)             |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Bit Rate List (opt)                  |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Processing Capabilities List (opt)             |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To me, I'd read this as

   <ResourceBlockInfo> ::= <ResourceBlockSet>
		   [<InputConstraints>] [<OutputConstraints>]
		   [<ProcessingCapabilities>]

Which is correct?  Also note that you have ResourceSet in this document and "RB Set Field" in wson-encode-24. to align this document:
s/<ResourceSet>/<ResourceBlockSet>

YOUNG>> As discussed previously, <ResourceBlockInfo> ::= <ResourceBlockSet> [<InputConstraints>] [<ProcessingCapabilities>] [<OutputConstraints>]. 

> ...
>>
>> - Section 6.6.  I think you have a BNF problem here.  The BNF says 
>> restriction parameters are always optional, but your text says that 
>> there are requirements based on <RestrictionTypes>.  I think the BNF 
>> needs to be aligned with the text and reflect the requirements.
>>
>> YOUNG>> Made all mandatory element. 
> 
> The new text says:
> 
>    <PortLabelRestriction> ::= <GeneralPortRestrictions>...
>    <MatrixSpecificRestrictions>...
> 
> This now says that a PortLabelRestriction MUST (and always) include
> *both* GeneralPortRestrictions and MatrixSpecificRestrictions.  Is this correct in all cases?
> 
> YOUNG>> No. Actually <PortLabelRestriction> is an optional information. It will be corrected as follows:
> 
>    <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] 
> [<MatrixSpecificRestrictions>...]

A few points here:
1) to get repetition of <PortLabelRestriction> I suggest:
OLD
   <LinkInfo> ::=  <LinkID> [<AdministrativeGroup>]
   [<InterfaceCapDesc>] [<Protection>] [<SRLG>]...
   [<TrafficEngineeringMetric>] [<PortLabelRestriction>] 

NEW
   <LinkInfo> ::=  <LinkID> [<AdministrativeGroup>]
   [<InterfaceCapDesc>] [<Protection>] [<SRLG> ...]
   [<TrafficEngineeringMetric>] [<PortLabelRestriction> ...]

YOUNG>> Accepted. 

2) What is unclear is that when <PortLabelRestriction> what it must contain.  looking at 2.2 of wson-encode-24 I see


YOUNG>> Actually this is 2.2 of gen-encode-14. 

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MatrixID    |RestrictionType| Switching Cap |     Encoding  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Additional Restriction Parameters per RestrictionType     |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which translates to me to be:
    <PortLabelRestriction> ::= <MatrixID> <RestrictionType>
				<Restriction parameters list>

    <Restriction parameters list> ::=
		<Simple label restriction parameters> |
		<Channel count restriction parameters> |
		<Label range restriction parameters> |
		<Simple+channel restriction parameters> |
		<Exclusive label restriction parameters>

    <Simple label restriction parameters> ::= <LabelSet> ...
	

    <Channel count restriction parameters> ::= <MaxNumChannels>
	

    <Label range restriction parameters> ::=
	<MaxLabelRange> (<LabelSet> ...)
	

    <Simple+channel restriction parameters> ::=
	 <MaxNumChannels> (<LabelSet> ...)

    <Exclusive label restriction parameters> ::= <LabelSet> ...
			
YOUNG>> OK. These are consistent with Gen-Encode-14. All accepted. 

> ----------------------------------------------------------------------
> ------------------------------
> also:
> 
>    <RestrictionParameters> ::= <LabelSet>... <MaxNumChannels>
>    <MaxWaveBandWidth>
> 
> So all parameters MUST be included for all RestrictionTypes?  I 
> suspect you mean to say there alternatives based on RestrictionType.
> If correct, syntax is covered in
> http://tools.ietf.org/html/rfc5511#section-2.2.4.
> 
> YOUNG>> No. Indeed these parameters appear only if they match with Restriction Types. So it should be as follows:
> 
> <RestrictionParameters> ::= (<LabelSet>...) | <MaxNumChannels> | 
> <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> (Note: 
> this is arranged to be consistent with 
> draft-ietf-ccamp-general-constraint-encode-13.txt in the naming and 
> order)
> 

Addressed above.

YOUNG>> OK.

> In Section 6.6, this is a summary of all encoding changes: 
> 
> <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] 
> [<MatrixSpecificRestrictions>...]
> 
> <GeneralPortRestrictions> ::= <RestrictionType> 
> <RestrictionParameters>  (RestictionType and one of the parameters 
> corresponding to the RestrictionType must be there)
> 
> <MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> 
> <RestrictionParameters> (the same rational apples as above)
> 
> <RestrictionParameters> ::=
> (<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... 
> <MaxNumChannels>) | <LinkSet>
> 
> 

Addressed above.

YOUNG>> OK.

> 
> Also the RestrictionParameters object/field naming doesn't match draft-ietf-ccamp-general-constraint-encode-13.txt, this section should be updated to match.
> 
> YOUNG>> RestrictionParameters are now matching with draft-ietf-ccamp-general-constraint-encode-13.txt.
> 
> s/PortSet/LinkSet
> s/MaxWaveWidth/MaxLabelRange
> 

I think I sense some fatigue. (on my part too!)

OLD
   LABEL_RANGE:   Waveband device with a tunable center frequency and
   passband. This constraint is characterized by the MaxLabelRange
   parameter which indicates the maximum width of the waveband in terms
   of channels. Note that an additional wavelength set can be used to
   indicate the overall tuning range. Specific center frequency tuning
   information can be obtained from dynamic channel in use information.
   It is assumed that both center frequency and bandwidth (Q) tuning
   can be done without causing faults in existing signals.
NEW
   LABEL_RANGE:  Used to indicated a restriction on a range of labels
   that can be switched.  For example a waveband device with a tunable
   center frequency and passband. This constraint is characterized by
   the MaxLabelRange parameter which indicates the maximum range of the
   labels, e.g., which may represent a waveband in terms of channels.
   Note that an additional parameter can be used to
   indicate the overall tuning range. Specific center frequency tuning
   information can be obtained from dynamic channel in use information.
   It is assumed that both center frequency and bandwidth (Q) tuning
   can be done without causing faults in existing signals.

YOUNG>> Accepted with a few grammar/style corrections: indicated -> indicate; For example -> For example,

and
OLD
     MaxLabelRange is the maximum width of a tunable waveband switching
     device.
NEW (from general-constraint-encode)
   MaxLabelRange indicates the maximum range of the labels.

YOUNG>> Accepted. 

That's it, thanks,.
Lou

> ...
> I think this covers all open points on this one.
> 
> Lou
>