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

[Lou Berger <[e-mail]>]

Young,


On 2/6/2014 5:01 PM, Leeyoung wrote:
> Hi Lou,
> 
> Please see inline for my comment.
> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Wednesday, February 05, 2014 8:50 PM
> To: Leeyoung; CCAMP; [e-mail]
> 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? 
> 

Only as much as this document defines these to be optional subfields of
the ResourceBlockInfo Field in section 4.1.

If you want to define them as *always* independently fields as you have
in wson-signal-compatibility-ospf then they can't be defined as sub
fields, but rather as standalone fields.

If you want to follow this path, then section 4 should state how the
[RWA-info] ResourceBlockInfo is encoded into the now independent fields.
and sections 4.x can define the now free standing fields. (I'm not sure
4.1 will still have the right name, your call.)


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

You mean the ospf version, encoding each field as it's own OSPF  Optical
Node Property TLV sub-TLVs or as TLVs within the ResourceBlockInfo field?

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

only if you make the above change.  If you leave as is, then you are
defining the TLV format in this document and need to cover it.

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

I think introducing a new information element in the encoding document
runs counter to having an info document. My preference would have been
to have simply not introduced this element type (i.e.,
RBSharedAccessWaveAvailability) and just call it Available Wavelengths.
 But I think it's too late for this change as you'd need to change the
protocol docs that use the new element.

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

I think this would be the easiest change at this point.

Lou

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