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

Lou Berger <lberger@labn.net> Tue, 28 January 2014 22:35 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 CC4371A03EB for <ccamp@ietfa.amsl.com>; Tue, 28 Jan 2014 14:35:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] 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 y0i84zA-Ufka for <ccamp@ietfa.amsl.com>; Tue, 28 Jan 2014 14:35:25 -0800 (PST)
Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id 6A8191A03A6 for <ccamp@ietf.org>; Tue, 28 Jan 2014 14:35:25 -0800 (PST)
Received: (qmail 26283 invoked by uid 0); 28 Jan 2014 22:35:22 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 28 Jan 2014 22:35:22 -0000
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:To:MIME-Version:From:Date:Message-ID; bh=+/dv8xF84CTbnb6IfwMUMX6QVdvoTafDGCuxmYNcY6Y=; b=fw3XNZSKZvtyowGz1m/jedIYyxBe/u+t+3AImjmoNzZqXX9zDLiIdNsvzWEGqbVl3k8QicP2Mx16wgrKhleGZeoDlPRTHcQTskWDNYffFH85uo0ONaq4zHWvsizOfMTP;
Received: from box313.bluehost.com ([69.89.31.113]:54727 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1W8HFa-0000c3-Gq; Tue, 28 Jan 2014 15:35:22 -0700
Message-ID: <52E830A5.2050301@labn.net>
Date: Tue, 28 Jan 2014 17:35:17 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-rwa-info@tools.ietf.org" <draft-ietf-ccamp-rwa-info@tools.ietf.org>
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>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BB4511@dfweml706-chm.china.huawei.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
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: Tue, 28 Jan 2014 22:35:30 -0000

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>]


> 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>

> 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>

> ...
>>
>> - 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> ...]

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

      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> ...
			

> ----------------------------------------------------------------------------------------------------
> 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.

> 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.

> 
> 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.

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.

That's it, thanks,.
Lou

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