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

"Alia Atlas" <akatlas@gmail.com> Wed, 05 August 2015 14:46 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DB1ACEE8; Wed, 5 Aug 2015 07:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.898
X-Spam-Level:
X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FQKtVQNAEDe; Wed, 5 Aug 2015 07:46:46 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61651A9241; Wed, 5 Aug 2015 07:46:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alia Atlas <akatlas@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.3.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150805144646.28443.8959.idtracker@ietfa.amsl.com>
Date: Wed, 05 Aug 2015 07:46:46 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/w_SAL3p-jEnmVjmj6_uH3667Z9g>
Cc: draft-ietf-ccamp-wson-signal-compatibility-ospf@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org
Subject: [CCAMP] Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 14:46:48 -0000

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?
Is that a SHALL or a "at most one... MUST be advertised"?  I'd expect
normative language.

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

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.

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.  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? 
Second, please add in some words
about the expected load of logs.


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

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

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.