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 for providing your good comments.

Please see in-line for my comments.

Best regards,
Young

From: Alia Atlas [mailto:[e-mail]]
Sent: Friday, August 21, 2015 4:07 PM
To: Leeyoung
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

Hi Young,

My apologies for the long delay in responding.  My responses are in-line.

Thanks,
Alia

On Wed, Aug 5, 2015 at 3:11 PM, Leeyoung <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>]
Sent: Wednesday, August 05, 2015 9:47 AM
To: The IESG
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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].

[Alia] Ok - SHALL is fine.  Perhaps text like
"To allow for fine granularity changes in topology, only one Optical Node Property TLV SHALL be
advertised in each LSA.  An implementation MUST support receiving multiple Optical Node Property
TLVs in an LSA."

YOUNG>> From another email thread (per Adrian), we discussed this.

NEW


When using the extensions defined in this document, at least one Optical Node Property TLV MUST be advertised in each LSA. To allow for fine granularity changes in topology, more than one Optical Node Property TLV MAY be advertised in a single LSA. Implementations MUST support receiving multiple Optical Node Property TLVs in an LSA.



END


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.

 [Alia] Ok.  Thanks for clarifying.

 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.

[Alia] My concern is about the phrase "only the first one" because two different routers may
received the TE LSAs in different order depending upon flooding dynamics.  I would much rather
that you define a tie-breaking mechanism - for instance  picking the largest LSA ID (Sec 2.2 of RFC 3630),
because that is considered newer.

YOUNG>> Thanks for the reference. Taking the largest LSA ID is a good idea in this situation. How about then:

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 the sub-TLV is received,
            in the same LSA, the redundant sub-TLV SHOULD be ignored. In case where the same sub-TLV
            Is advertised in different TE LSA (which would take place only by a packaging error), then the sub-TLV
            with the largest LSA ID (Sec 2.2 of RFC 3630) SHOULD be picked.
            These restriction need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.

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

[Alia] Wouldn't the information contained be redundant?  I'm not sure why you think that the duplication
can't be detected based on fields in the sub-TLV.  Again, just a simple tie-breaker would provide interoperability.

YOUNG>> Please see the previous comment.

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

[Alia] How about "A SCSI may contain multiple Available Label sub-TLVs and multiple Shared Backup Label sub-TLVs.  The following figure shows the format for a SCSI that contains these sub-TLVs.  The order of the sub-TLVs in the SCSI is arbitrary."

YOUNG>> Accepted.


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

[Alia] Sounds good.

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.


[Alia] Usually, one doesn't reflood LSAs with malformed TLVs or sub-TLVs.  I'm certainly willing
to listen to reasoning on why flooding potentially corrupt data would be a good idea, but you'll need
really clear reasoning.

YOUNG>>  We discussed in other thread.  To-recap here, how about


NEW

      In case where the new sub-TLVs or their attendant encodings are

      malformed, the proper action SHOULD log the problem and MUST stop

      sending the LSA in which to contain malformed TLVs or sub-TLVs.

END




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.

[Alia]  Are you picturing that a sub-TLV is malformed if its length isn't accurate or just if one of the fields inside the sub-TLV is using a bad value or setting a reserved value?  In the latter cases, perhaps it might be tolerable to assume that there wasn't data-corruption that will affect the rest of the parsing - but I'm dubious.   For the first, if the length is wrong, then you can't accurately know where the next sub-TLV starts so all parsing after isn't trustable, IMHO.

YOUNG>> Both cases. Please see the previous comment. I think in either case, the safe way is to stop the LSA advertisement.




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

[Alia] Uh - of course error conditions aren't expected to be common!  How about considering how often the
advertising router might send the LSA?  How about considering the number of neighbors that will be flooding it?
How about dampening the number of logs?  Making it a MAY log also makes it clear that it's up to the implementation.

YOUNG>> Per Adrian’s suggestion, how about:

NEW


Errors of this nature SHOULD be logged for the local operator. Implementations MUST provide a rate limit on such logs, and that rate limit SHOULD be configurable.



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

[Alia] Thanks - could you take this one step further and specify about the expected size of the TLV based on these assumptions?

YOUNG>> OK. I will calculate this and add in the text in the revision.

Thanks,
Alia