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

Leeyoung <leeyoung@huawei.com> Thu, 06 February 2014 22:01 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 3A29E1A044D for <ccamp@ietfa.amsl.com>; Thu, 6 Feb 2014 14:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.736
X-Spam-Level:
X-Spam-Status: No, score=-3.736 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, RP_MATCHES_RCVD=-0.535, 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 SIHm96FWiXuu for <ccamp@ietfa.amsl.com>; Thu, 6 Feb 2014 14:01:16 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 354741A0427 for <ccamp@ietf.org>; Thu, 6 Feb 2014 14:01:15 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDI19185; Thu, 06 Feb 2014 22:01:13 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 22:00:14 +0000
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 22:01:13 +0000
Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml704-chm.china.huawei.com ([169.254.6.202]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 14:01:08 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" <draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org>
Thread-Topic: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHPFhlbHunPM4cigU27jgjJpKdHqZqly19QgAJaq4CAAKNoYA==
Date: Thu, 6 Feb 2014 22:01:08 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BB6FFC@dfweml706-chm.china.huawei.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFE06.20207@labn.net> <7AEB3D6833318045B4AE71C2C87E8E17291E3AF2@dfweml511-mbs.china.huawei.com> <52DD7EC4.9050801@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729BB64AC@dfweml706-chm.china.huawei.com> <52F2F83D.2090407@labn.net>
In-Reply-To: <52F2F83D.2090407@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.137.208]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
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, 06 Feb 2014 22:01:19 -0000

Hi Lou,

Please see inline for my comment.

Regards,
Young

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Wednesday, February 05, 2014 8:50 PM
To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode

Young,

     There are still open issues on this document.  The most significant issues still relate to the handling of the optional fields of the Resource Block Information fields.  In the latest rev you replaced the type and length fields with a single length field. As there are no ordering requirements for these fields or indications of which are present how is this supposed to work?

YOUNG>> I can add the type field and the length field to all the optional field. For instance, for optical interface class list field will look like

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Type                    |            Length             |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                        |I|O|   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Optical Interface Classes                   |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But, in the corresponding OSPF draft, I have defined the following nested sub-TLVs for Resource Block Information sub-TLV as follows.

6.1.2. Types for sub-TLVs of WDM Resource Block Information

   Additionally, a new IANA registry will be created for nested sub-
   TLVs of the Resource Block Information sub-TLV to create a new
   section named "Types for sub-TLVs of WDM Resource Block Information"
   and allocate new values as follows:

   Value          Length      Sub-TLV Type                  Reference

   0                          Reserved
   1 (suggested)  variable    Optical Interface Class List [This.I-D]
   2 (suggested)  variable    Acceptable Client
                              Signal List                  [This.I-D]
   3 (suggested)  variable    Input Bit Rate List          [This.I-D]
   4 (suggested)  variable    Processing Capability List   [This.I-D]
   5-65535                    Unassigned

My question is, since we defined Optical Interface Class List field as sub-TLV with Type (optical interface class) and its type value =1, do I need Type and length encoding in the WSON-encode draft? 
If we were to just say the encoding for this is as follows, would this be good enough? Since the OSPF draft treats this encoding as sub-TLV, I thought we do not need to specified Type and Length in the 
WSON encoding draft --- is this rational wrong? 

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                        |I|O|   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Optical Interface Classes                   |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Regarding the ordering requirement, are you talking about the order of these info fields as to if the sequence matters? If this is a question, the answer is that there is no ordering problem. But I can put the type to all optional fields to clearly indicate which fields are present. 

My understanding is there are several implementations of this out there, what do they do?  (i.e., what format are they processing?)

YOUNG>> TLV was used for some implementation (as the old version).



I really think you also need a common definition for the type/length portion of the optional fields.  This is where you can also capture any ordering and alignment requirements.  You should also consider a type registry.  I can help you with text if need be, but I would like to hear the answers to the above questions in any case. 

YOUNG>> Are you referring 'alignment' problem to the padding issue if there is not used bits in the 32 bit-field? I said in the previous email as follows, is this answering your question? If not, please clarify it:

> YOUNG>> RFC 2370 says: "Opaque LSAs contain some number of octets padded to 32-bit alignment." 
> Since the TLV's in this draft are part of Opaque LSAs, do you see the need to say explicitly on the padding issue? I guess not.


Finally:
One of the other emails mentioned the need for rwa-wson-encode to be realigned with rwa-info

   3.4. Resource Block Shared Access Wavelength Availability
   (RBSharedAccessWaveAvailability) Field

I don't see where RBSharedAccessWaveAvailability is defined in the latest info document.  Seems that this section needs additional alignment.

YOUNG>> In Info Section 5.1, <RBPoolState> ::=<ResourceBlockID> <NumResourcesInUse>
   [<InAvailableWavelengths>] [<OutAvailableWavelengths>]
   [<RBPoolState>]

Where <InAvailableWavelengths> and <OutAvailableWavelengths> are what is referred to as RBSharedAccessWaveAvailability in the WSON-encode. In the info,
We did not introduce an explicit name for this. If you want this to be explicitly defined in the info, I can introduce the following in the info (though I 
don't think we need this):

<RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>] [<OutAvailableWavelengths>]. 

Thanks,
Lou

On 2/4/2014 7:35 PM, Leeyoung wrote:
> Hi Lou,
> 
> Please see inline for my comments. Here's the working version (24) and the idnits results. 
> Let me know if you feel this is ready for publication.
> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Monday, January 20, 2014 1:54 PM
> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org
> Subject: Re: [CCAMP] WG Last Call: WSON documents - 
> draft-ietf-ccamp-rwa-wson-encode
> 
> Young, (all),
> 
> There are few minor items in this document.
> 
> idnits says:
> (see
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rwa-wson-encode-23.txt)
>   == Line 497 has weird spacing: '...(number  of  r...'
>   == Missing Reference: 'RWA-INFO' is mentioned on line 154, but not defined
>   == Unused Reference: 'RFC2578' is defined on line 1248, but no explicit
>      reference was found in the text
> 
> YOUNG>> Corrected. 
> 
> On 11/12/2013 9:06 PM, Leeyoung wrote:
>> Hi Lou,
>>
>> Please see inline for my responses to your comments. Let me know if there are still further issues. 
>>
>> Thanks.
>> Young
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, October 29, 2013 1:27 PM
>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org
>> Subject: Re: [CCAMP] WG Last Call: WSON documents - 
>> draft-ietf-ccamp-rwa-wson-encode
>>
>> Authors,
>> 	I have some comments on this document. Many are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information.
>>
>> - Please address my general comments on the WSON document set
>>
>> YOUNG>> Done. See Terminology Section changed as follows: 
>>
>> Refer to [RFC6163] for CWDM, DWDM, RWA, WDM. 
>> Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool.
>>
> 
> you now have two section 1s.  Perhaps the second should be 1.1?
> 
> ...
> 
> YOUNG>> Terminology is under 1.1 now. 
> 
>> - Section 3.1
>>     0 1 2 3 4 5 6 7 8
>>     | Connectivity  |
>>   Why is connectivity a byte here, but only a bit in section 2.1?
>>   Either it should be a bit here to, or section 2.1 should be a byte.
>>   Note, that this can be fixed in a compatible way by defining it here
>>   as:
>>     0 1 2 3 4 5 6 7 8
>>     |   Reserved  |C|
>>
>> YOUNG>> Your suggested encoding accepted. 
>>
> 
> I expected that the "C" bit would end up in the same bit location all things being equal.  The new text has the reserved field of 7 bits, the corresponding 'action' field is 8 bit's so I think you're one bit too
> short.   Either way, you should give the number of bits that are in each
> reserved field to make this unambiguous. Perhaps?
>    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
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |Reserved(8bits)|C|             Reserved  (23 bits)             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> YOUNG>> Accepted. 
> 
>> - Section 4.
>>   The definitions of sub-sub-TLVs are a bit underspecified.  Some
>>   specific questions to address:
>>
>>   - Are there any sub-sub-TLV ordering requirements?
>>
>> YOUNG>> No.
>>
> 
> Where is this stated?  Now that they are list as fields this is even less self evident.
> 
> YOUNG>> In Section 4.1, the following text was added:
> 
> "In case where there are multiple Resource Block information fields, 
> there are no ordering requirements as these fields represent 
> independent and mutually disjoint information to each other."
> 
>>   - How are multiple sub-sub-TLVs of the same type to be handled?
>>
>> YOUNG>> I don't see why there are multiple sub-sub-TLVs of the same
>> type. In case where there are multiple sub-sub-TLVs of the same type, 
>> there would be no error as these information are not order-sensitive.
>> Is this what you have in mind?
>>
> 
> Again, just looking for an explicit statement of processing requirements.
> 
> YOUNG>> Added a next text in section 4.1: "In case where there are 
> YOUNG>> multiple sub-sub-TLVs
> of the same type, only the first sub-sub-TLV should be processed while 
> the redundant TLVs will be ignored."
> 
>>   - What is the sub-sub-TLV header (TL format)?
>>
>> YOUNG>> Added TLV format
> 
> It looks like only the Optical Interface Class List field has a type and length field (neither of which are defined).  What about the other 3?
> (Acceptable Client Signal Type, Input Bit Rate List, Processing 
> Capabilities List)
> 
> YOUNG>> The other three fields are now in TLV format. 
> 
> Also, note that you reference the "Processing Capabilities List" but don't define it.
> 
> YOUNG>> In Section 4.6, "Processing Capability List" is defined as follows:
> 
> The processing capability list field is a list of capabilities that can be achieved through the referred resources: 
> 1.	Regeneration capability
> 2.	Fault and performance monitoring
> 3.	Vendor Specific capability
> 
> 4.6. is titled "Processing Capability List Field", 4.6.1 is titled "Processing Capabilities Field" which defines the "processing capability field".  Clearly you need to pick just one.
> 
> YOUNG>> Subtitle 4.6.1 was deleted. 
> 
>>
>>   - Are there any alignment requirements?
>>
>> YOUNG>> Not sure what this is. 
> 
> It's part of a typical TLV definition.
> 
> YOUNG>> RFC 2370 says: "Opaque LSAs contain some number of octets padded to 32-bit alignment." 
> Since the TLV's in this draft are part of Opaque LSAs, do you see the need to say explicitly on the padding issue? I guess not. 
> 
>>
>>   - What happens when a sub-sub-TLV is larger than 256 bytes?
>>     (There are already systems that advertise 192 wavelengths on a
>>     fiber and an application code takes 8 bytes, right? But
>>     of course this presents a problem when carried within an RSVP
>>     object too.)
>>
>>   If you find you need more specifics, we can discuss / I can propose
>>   new text.  Feel free to discuss the details on or off list (your
>>   choice.)
>>
>>
>> YOUNG>> Please see the other email response to this comment. 
>>
> [copied]
>> YOUNG>> For the last dash item, "what happens when sub-sub-TLV is
> larger than 256 bytes", I guess you meant that the RB Info Field (in which to contain sub-sub-TLVs) can exceed 256 bytes as opposed to individual sub-sub-TLVs in the RB Info Field?
> 
> It was a general question, as the topic has showed up as a general in in ccamp. I'd expect it to be addressed as part of the TLV definition.
> 
> YOUNG>> All sub-sub-TLVs defined in Section 4 are given 16 bits of the length in the newer version. 
> 
>>
>> YOUNG>> As for the resolution for this case, should this be addressed
> in the respective routing and signaling drafts?
> 
> If it's likely to happen, then I think you need to say something about it.  If it should never happen, e.g., due to fixed sizes, then it can be ignored.
> 
> YOUNG>> 16 bit length should take care of this issue. 
> 
>> YOUNG>> I am not familiar the method to resolve this kind of issues
> --- can you suggest some references or relevant text?  I think this issue would arise both routing and signaling.
> 
> Agreed.  Truncation and semantic fragmentation show up in a bunch of places. The real question is, is how worried do we need to be about this case?
> 
> YOUNG>> Again 16 bit length defined for TLV and 32-bit alignment rule for Opaque LSAs (per RFC2370) should take of these issues (??). 
> 
> ...
> 
>>
>> - Section 3.4, 4.1
>>   - Bits I & E are defined here, but I & O are used in parallel ways in
>>     Section 3.2. For consistency it should be I & O everywhere (to
>>     match input and output).
>>
>> YOUNG>> Corrected to I & O.
>>
> 
> You still have one case of an E-bit (rather than O-bit) in Section 4.3.
> 
> YOUNG>> Corrected. 
> 
> ...
> I think this covers all open points on this one.
> 
> Lou
>