Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signal-compatibility-ospf

From: Leeyoung <[email-masked]>
Date: Tue, 4 Feb 2014 00:22:52 +0000

Hi Lou,

Please see inline for my comments. Here's the working version and the idnits results.

Let me know if this is ready for publication.

Thanks.
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, October 29, 2013 1:28 PM
To: CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signal-compatibility-ospf

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.

- In two places
  s/These routing enhancements are required/These routing enhancements are applicable

YOUNG>> Done. 

- Do you want to reference
draft-ietf-ccamp-gmpls-general-constraints-ospf-te? Perhaps in the intro.

YOUNG>> Added in the introduction section, "Related to this document is [GEN-OSPF] which provides GMPLS OSPF routing enhancements to support the generic routing and label assignment process that can be applicable to a wider range of technologies beyond WSON."

- Section 2, SUB-TLV ordering
  Looks like this ordering matches rwa-info, even though the encoding
  document doesn't. (Suggest the encoding document be fixed.)

YOUNG>> Yes. WSON encode is now matching with info and OSPF. 

- Section 2 says:

   All sub-TLVs defined here may occur at most once in any given
   Optical Node TLV. "At most once" means that if there is sub-TLV
   related information, it should be always included.

   The second sentence reads to me to be closer to "at least once".
   "At most once" means no more than one time. Please clarify your
   intent.

YOUNG>> How about: 

   "All sub-TLVs defined here may occur at most once in any given 
   Optical Node TLV. If more than one copy of a sub-TLV is received, 
   only the first one of the same type is accommodated and the rest 
   are ignored upon receipt." 

- Section 2.1: title
  s/Sub-TLV Details/Resource Block Information

YOUNG>> Corrected. 

- Section 2.1, 1st paragraph
  Looks like this belongs at the end of the section 2 (intro)

YOUNG>> Moved to the end of the Section 2. 

- Section 2.1, should be sub-sub-tlv, and there are 4 not 3 or 5

   There are four nested sub-sub-TLVs defined in the Resource Block
   Information sub-TLV.

   Value          Length      sub-Sub-TLV Type

  also add lines for "Input Bit Rate List"

YOUNG>> Done.

- Sections 2.1.1->2.1.4
  shouldn't these be sections 2.2 -> 2.5?

YOUNG>> Not sure these numberings, but we have the following headers: (Note: 2.2-2.5 were promoted from the Level 3 header as they are the same level as Resource Block Information.) 

2. The Optical Node Property TLV	
2.1. Resource Block Information	
2.2. Resource Accessibility	
2.3. Resource Wavelength Constraints	
2.4. Resource Block Pool State	
2.5. Resource Block Shared Access Wavelength Availability	

- Section 2.1.3
  Drop "16 bit"

YOUNG>> Dropped. 

- Section 3:
  Don't you want to require the use of the RFC6205 defined label format
  for interfaces advertised with  WSON-LSC?

YOUNG>> I think this makes sense to put in Section 3.1 as this section discusses the label format. 
Added: "The format of Label is required of the use of the label format defined in [RFC6205] for interfaces advertised with WSON-LSC." 

- Section 6:
  Acee's comment on IANA applies here too. (Should look at his other
  comments too and see if they apply to this document.)

YOUNG>> Added. 

That's it on this one,
Lou

On 10/22/2013 4:34 PM, Lou Berger wrote:
> 
> All,
> 	Given the recent draft submission deadline and only one comment being 
> received to date, we'd like to extend the WG more time for review.
> 
> These drafts represent significant work by the authors and WG, so 
> please review and let the WG know what you think (positive or negative)!
> 
> Please have all comments in by October 29.
> 
> Thank you,
> Lou (and Deborah)
> 
> On 10/1/2013 12:34 PM, Lou Berger wrote:
>> All,
>>
>> This mail begins working group last call on the WSON documents.  As 
>> there are 6 documents in this set, the last call will be three weeks.
>> The documents included in the last call are:
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18
>> (Informational, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode
>> -11
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21
>> (Standards Track)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints
>> -ospf-te-05
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility
>> -ospf-12
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 
>> (Standards
>> Track) Also has one open issue that will need to be resolved as part 
>> of LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52.
>>
>> This working group last call ends on October 22.  Comments should be 
>> sent to the CCAMP mailing list.  Please remember to include the 
>> technical basis for any comments.
>>
>> Positive comments, e.g., "I've reviewed this document and believe it 
>> is ready for publication", are welcome!
>>
>> Please note that we're still missing some IPR statements.  Any 
>> forthcoming publication request will be delayed by late IPR 
>> statements/disclosures.
>>
>>
>> Thank you,
>> Lou (and Deborah)
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Feb 2014 19:45:45 -0500

Young,

I think just one comment:

CURRENT:
   The format of Label is required of the use of the label format
   defined in [RFC6205] for interfaces advertised with WSON-LSC.
NEW
   The label format defined in [RFC6205] MUST be used when
   advertising interfaces with a WSON-LSC type Switching Capability.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Feb 2014 21:49:33 -0500

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
> 
> From: Lou Berger [mailto:[email-masked]] 
> Sent: Monday, January 20, 2014 1:54 PM
> To: Leeyoung; CCAMP; [email-masked]
> 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
>>
>> From: Lou Berger [mailto:[email-masked]]
>> Sent: Tuesday, October 29, 2013 1:27 PM
>> To: CCAMP; [email-masked]
>> Subject: Re: [CCAMP] WG Last Call: WSON documents - 
>> draft-ietf-ccamp-rwa-wson-encode
>>
>> Authors,
>> 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
>

---

From: Leeyoung <[email-masked]>
Date: Thu, 6 Feb 2014 22:01:08 +0000

Hi Lou,

Please see inline for my comment.

Regards,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, February 05, 2014 8:50 PM
To: Leeyoung; CCAMP; [email-masked]
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. 

> 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

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 07 Feb 2014 12:20:02 -0500

Young,

On 2/6/2014 5:01 PM, Leeyoung wrote:
> 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
> 

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

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?

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

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

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

Lou