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

[Lou Berger <[e-mail]>]

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?

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

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.

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.

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:[e-mail]] 
> Sent: Monday, January 20, 2014 1:54 PM
> To: Leeyoung; CCAMP; [e-mail]
> 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:[e-mail]]
>> Sent: Tuesday, October 29, 2013 1:27 PM
>> To: CCAMP; [e-mail]
>> 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 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
>