Re: [CCAMP] Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

[Leeyoung <[e-mail]>]

Hi Alia,

Thank you first of all for providing very useful comments. 

Here's my attempt to your comments/DISCUSS. Please see inline. 

Thanks.
Young

-----Original Message-----
From: Alia Atlas [mailto:[e-mail]] 
Sent: Wednesday, August 05, 2015 9:47 AM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

Alia Atlas has entered the following ballot position for
draft-ietf-ccamp-wson-signal-compatibility-ospf-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to see clearer descriptions on particularly the error-handling
around multiple TLVs and sub-TLVs. 
I see a few points of ambiguity - as described below.  I think these
should be straightforward to clarify but
interoperability could be affected if this isn't done.   Thanks!

In Sec 2, it says "Only one Optical Node Property TLV shall be advertised
in each LSA." What is the error-handling if multiple of this TLV are
seen?

YOUNG>> This is to allow for fine granularity changes in topology per [RFC3630]. It is not an error per se if there are multiple of this TLV are in each LSA. 

Is that a SHALL or a "at most one... MUST be advertised"?  I'd expect
normative language.

YOUNG>> "SHALL" seems to be right one, again per [RFC3630].

In Sec 2, it says "   Among the sub-TLVs defined above, the Resource
Block Pool State sub-
   TLV and Resource Block Shared Access Wavelength Availability are
   dynamic in nature while the rest are static. As such, they can be
   separated out from the rest and be advertised with multiple TE LSAs
   per OSPF router, as described in [RFC3630] and [RFC5250]."
So - one can advertise multiple TE LSAs - each with at most one  Optical
Node Property TLV 
and at most one of these sub-TLVs?  

YOUNG>> This is correct except that the Optical Node Property TLV would carry "at least" one of these sub-TLVs as opposed to "at most one of these sub-TLVs." For instance, one TE LSA can carry one Optical Node Property TLV under which two dynamic sub-TLVs (i.e., the Resource
Block Pool State sub-TLV and Resource Block Shared Access Wavelength Availability sub-TLV) can be advertised while another TE LSA can carry one Optical Node Property TLV under which the rest of static sub-TLVs can be advertised.  


If the same sub-TLV appears in
different TE LSAs, how
are they merged or is a particular one preferred and the rest ignored?  I
see the text in the
previous paragraph of "If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt." but what does the "first one" mean?  Is that
decided based on
a particular identifier? 

YOUNG>> The text in Section 2 you quoted is not dealing with the case for two different TE LSAs. In such case, then the sub-TLVs will identify by the value of the sub-TLV. 

The case you are referring to is for the case where the same sub-TLV is advertised in different TE LSAs. It should NOT happen that way, but in case it happens by mistake of packaging, then it will be updated one after another. There is no way for the routers to distinguish this sub-TLV as the same one (as it is under different TE LSAs), which is actually fine. It is not an error condition. The router would simply process the same sub-TLV multiple times. 

I can suggest the following changes:

OLD: 

   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 processed and the rest are
   ignored upon receipt. These restriction need not apply to future
   sub-TLVs. Unrecognized sub-TLVs are ignored.

NEW: 

   All sub-TLVs defined here may occur at most once in any given
   Optical Node TLV under one TE LSA. If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt. These restriction need not apply to future
   sub-TLVs. Unrecognized sub-TLVs are ignored.

   In case where the same sub-TLV is advertised in different TE LSAs (which would take place by a 
   packaging error), then the sub-TLV will be updated one after another. There is no way for the  
   routers to distinguish this sub-TLV as the same one (as it is under different TE LSAs), which is 
   actually fine. It is not an error condition. The router would simply process the same sub-TLV 
   multiple times.

END.

In Sec 3.1, "The format of the SCSI MUST be as depicted in the following
figure:" implies that
both the Available Label Sub-TLV and the Shared Backup Label Sub-TLV must
be included and
in the specified order.   Please clarify (and use separate diagrams)
details about how many times
each sub-TLV can appear, if ordering matters, and how to handle conflicts
or duplicates.

YOUNG>> Good point. I would relax "MUST" to "SHALL" as there is no issue of ordering here. The number of each sub-TLV depends on the number of labels this field describes. If we were talking about, 100 channel (wavelength) system, this can be as many as 100 sub-TLVs for the Available Label sub-TLV + Shared Backup Label TLV. But there are ways to reduce the entry by Label Range, etc per [Gen-Encode]. 

In case duplicated sub-TLVs appear (which should not happen), the router/node will ignore the duplicated labels which are identified by the Label format defined in [RFC6205]. 

May I suggest the following changes:

OLD

	The format of the SCSI MUST be as depicted in the following figure:

NEW

	The format of the SCSI SHALL be as depicted in the following figure:

END

OLD

	Where the Available Label Sub-TLV and Shared Backup Label sub-TLV
   	are defined in [Gen-Encode]. (right below Figure 1)

NEW

	Where the Available Label Sub-TLV and Shared Backup Label sub-TLV
   	are defined in [Gen-Encode]. In case where duplicated sub-TLVs are advertised, 
      the router/node will ignore the duplicated labels which are identified by the Label format 
      defined in [RFC6205].

END

End of Sec 4: "In case where the new sub-TLVs or their attendant
encodings are
   malformed, the proper action would be to log the problem and
ignore..."  First, please be explicit in
what behavior MUST be done.  

YOUNG>> malformed sub-TLVs or their attendant encodings refer to that which are not parse-able due to corruption, etc. and cannot be stored in the TED. 

How about adding a new sentence to describe the expected action as follows:

OLD

   In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore
   just the sub-TLVs in GMPLS path computations rather than ignoring
   the entire LSA.

NEW

   In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore
   just the sub-TLVs in GMPLS path computations rather than ignoring
   the entire LSA. This should not stop the LSA advertisement process. 


Is this just for malformed sub-TLVs?  Is it
safe to assume that sub-TLVs
further on in the TLV (or following TLVs) can be properly parsed? 

YOUNG>> Yes we are just talking about malformed sub-TLVs. It is safe to assume that other sub-TLVs in the TLV or following TLVs can be properly parsed as they are a distinct sets of info elements with proper sub-TLV types, TLV types. 

 
Second, please add in some words
about the expected load of logs.

YOUNG>> How about adding one sentence followed by "In case..."

NEW
	The expected load of logs is not expected to be a high volume as malformed TLVs do not occur 
      frequently in GMPLS.  

END


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



In Sec 2, it's useful to use TBA1, TBA2, etc. instead of reusing TBA -
adds to clarity of the text and makes it easier to make sure replacement
is done
properly when the values are assigned.

YOUNG>> Good point. I will change that way as you suggest. 

In Sec 3.1, it says "   The technology specific part of the WSON ISCD may
include a variable
   number of sub-TLVs called Bandwidth sub-TLVs.  Two types of
   Bandwidth sub-TLV are defined (TBA by IANA):"   If this document is
creating the
bandwidth sub-tlv space, then this draft simply assigns initial values -
so no need for the "TBA
by IANA".

YOUNG>> Correct. Will address that. 

In Sec 4, "In a typical node configuration, the optical node property TLV
will not exceed the IP MTU."
Can you please describe the assumptions about a "typical node
configuration"?  In a few years, these
assumptions are likely to have changed.

YOUNG>> I can add:

NEW

	A typical node configuration refers to a system with several hundreds of channels. In addition, [WSON-Encode] provides mechanisms to compactly encode required information elements. 

END