[CCAMP] AD review of draft-ietf-ccamp-general-constraint-encode

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 03 November 2014 14:55 UTC

Return-Path: <adrian@olddog.co.uk>
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 7BE8B1A0137 for <ccamp@ietfa.amsl.com>; Mon, 3 Nov 2014 06:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 De31SBezRcoq for <ccamp@ietfa.amsl.com>; Mon, 3 Nov 2014 06:55:22 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82971A037B for <ccamp@ietf.org>; Mon, 3 Nov 2014 06:55:21 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sA3EtJGc019233; Mon, 3 Nov 2014 14:55:19 GMT
Received: from 950129200 (unsi-72-29-212-251.unsi.net [72.29.212.251] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sA3EtFxC019143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Nov 2014 14:55:18 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org>
Date: Mon, 3 Nov 2014 14:55:14 -0000
Message-ID: <03f701cff776$2ed81b30$8c885190$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac/3deMo6snXKdO4SF+iFLardtOqTA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21072.007
X-TM-AS-Result: No--20.232-10.0-31-10
X-imss-scan-details: No--20.232-10.0-31-10
X-TMASE-MatchedRID: 2VWjU+VfDMJjoPWaAQeFLuYAh37ZsBDCk8UlXQzLGbxrE1c4mB5UmoNI hVk6p0MOddLzNY2Nt2IVh9CPTUlmMqN+QIqNqZqNSEQN/D/3cG5peZ1cXZibx8Xt25YNeIUSgqL WQyr3mKXs7975EykgpaTthdaWhBAK8m0l4hl+oyIpa6LJktEjgBkqnRJng/51/NpLPdn/hppV7p QjmDjR80JeJ3SFEJJmkT8hfw+0MFWeEslYSMAYcxNEPNwNrw/rTJDl9FKHbrl0TRq4bcxmH1OS9 5hWV5LTsr/K6nap4RjGp/huIU6WTOhKL24lXrDJvHKClHGjjr0jRkifc0blDbrfxlRjqBJ3OHqE u4NkBCQTGo4bHYA3ABhH53OJhEK/LQzUn36IIZbqsFlQXzLr6A3CvJ/nEe1ys/uo6bL1AFSg0hW zUrznJ80yieY+jIy1soggicPrwkbgSfYuq+GvYsxTqHgXR/599yS7vvkvVUbI9BHsOEzeNvxdQa 3mu28iwRHYS7nt5W/5UAOjYBPBr8zLorbh+KyrMN+B8zdlz9FMli8I1FShbmhUuzmCSj0vmNZnx zilqt8PuugVWNaenVznheL9ypiHeQB/CWKgHttswYo64ufkVTDK+BrjR19aGoXIaM/vL8L9irmq gEMJQ/p2jSS8EiepF3jK/jNnx+CMFnqTvCmjcCYRREGYqtmU7+SXqJTPIrvzYcyIF7RSVSzDMBT 1YTdhPdnPWc3oGJr5boH7tm5XcCpx/2ER54NYngIgpj8eDcC063Wh9WVqghziNLWewPgd+gtHj7 OwNO0CpgETeT0ynA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/yWbVYnqbxmU9xbSDbw-M0WxVKpU
Cc: ccamp@ietf.org
Subject: [CCAMP] AD review of draft-ietf-ccamp-general-constraint-encode
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: <http://www.ietf.org/mail-archive/web/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: Mon, 03 Nov 2014 14:55:25 -0000

Hi,

This I-D has been in the pipe for a very long time. Thanks for
persisting with it: hopefully we can stumble through the last stages
and achieve publication.

I have done my usual AD review. The intention is to apply some polish 
and to catch any issues that would otherwise gum up IETF last call and
IESG review.

Set out below you will find a number of relatively minor editorial points
and questions. But there are quite a lot of them, so I think you need to
address them either by responding to my email with rebuttals and 
explanations, or by updating the draft. I'm happy to discuss all/any of
the points.

I'll mark the I-D as "revised I-D needed" until we resolve this
discussion.

Thanks for the work,
Adrian

===

You have a reference to [WSON-Frame] in the first paragraph, but no
citation in the references section. I think it is Informative.

---

In section 1.1

   Note
   that this matrix does not represent any particular internal blocking
   behavior but indicates which input ports and labels (e.g.,
   wavelengths) could possibly be connected to a particular output
   port.

Should this read...

   which input ports and labels (e.g.,
   wavelengths) could possibly be connected to a particular port and
   label pair.

Further, you have

   The connectivity matrix is a
   conceptual M by N matrix representing the potential switched or
   fixed connectivity, where M represents the number of input ports and
   N the number of output ports.

This seems to have smudged the difference between port and label. Do you
not actually have a conceptual M*m by N*n where M represents the number
of input ports each with m labels and N the number of output ports each
with n labels?

---

Section 2 uses [RWA-Info] in a normative way. Please move the referenced
document into the Normative References section.

---

Section 2.1

Presumably you are anticipating more "Connectivity" types. I found it a
little hard to dream of one, but hey, perhaps the future will surprise
me. But will there be another 254 connectivity types? Or should this be
a 4 bit, 2 bit, or 1 bit field?

---

In section 2.1 the concept of a Matrix ID is introduced. I think you
need to discuss this concept in the introduction to section 2. You
need to explain that the ID is unique only on the advertising node, and
you need to explain why a node would have more than one matrix. You
probably also need to note whether a {port, label} can be present in
more than one matrix. Lastly, if two matrices have {sr port, src label,
dst port, dst label} for the same ports and labels, and the values
differ there is presumably some assumption.

I believe all of this is generic and not protocol specific, but maybe
it will help me understand why you need 255 matrices on any one node.

---

Section 2.2

   When more than one of these fields are present the
   resulting restriction is the intersection of the restrictions
   expressed in each field.

Do you really mean "intersection" and not "union". It seems to me that
the intersection of the restrictions is less of a restriction.

---

Section 2.2 

For the explanation of RestrictionType you need to give a forward
pointer to Sections 2.2.1 through 2.2.5 so that the reader isn't
puzzled.

---

Section 2.2 needs to explain the "Additional Restriction Parameters per
RestrictionType" field.

---

Section 2.2.1

   In the case of the SIMPLE_LABEL the GeneralPortRestrictions (or
   MatrixSpecificRestrictions) format is given by:

What are GeneralPortRestrictions and MatrixSpecificRestrictions?

---

2.2.1 and 2.2.4 need to point forward to 2.6 for the definition of label
set.

---

2.2.3 needs a forward pointer to 2.6.2 for the explanation of label
range. Indeed, the whole of this section is hard to interpret. I can't
read it and apply any meaning to the protocol object.

Furthermore:

   It is assumed that
   both center label and range tuning can be done without causing
   faults to existing signals.

Is a passive voice assumption.  Who is assuming this? What if she is
wrong? Who is responsible for making the assumption correct?

---

2.2.5

   In this case the accompanying port set indicate that a label may be
   used at most once among the ports in the link set field.

Not only would a forward pointer to 2.3 be useful, but you need some
clarity between "link set" and "port set".

---

2.3

Why is <ConnectivityMatrix> in angle brackets?

There are just two other uses of angle brackets in the document. Why?

---

2.3

Does the Action field need a registry to track values? 

I am surprised that you think there may be 255 potential settings.

---

Section 2.3

   All Local Interface IP Address are supplied in
   the context of the advertising node

Aren't IP addresses scoped a little more widely?

---

Section 2.3

Wondering why you want a length field rather than a count field.

---

Section 2.4

Priority needs some explanation or reference. Priority with respect to
what?

   At least one priority
   level MUST be advertised that, unless overridden by local policy,
   SHALL be at priority level 0.

I cannot parse this at all! 

---

Sections 2.3, 2.4, and 2.6 seems to have origins in section 2.2 and can
have the necessary forward pointers included.  But where does section
2.5 come from? Where does the "Shared Backup Labels Field" sit?

Assuming that question can be answered, the same issues apply as voiced
for section 2.4.

---

In 2.6 or its subsections you need to explain the Num Labels field.

The explanation of Length in 2.6 is a little lacking, as well...

   Length is the length in bytes of the entire field.

...which "field"? ... why do you need the label count and the length
field?

---

2.6.2

Curious effect if I set start label equal to end label but am required
to set num labels equal to 2.

---

2.6.3

Only support 4096 labels in a bitmap set? Really?

---

In the second example in A.2

"Length = 20 bytes" seems to be wrong
Why does every entry have "n  for lowest frequency"?

---

Section A.3

   This representation uses only 30 32-bit words.

But I count only 29 32-bit words.

---

In A.5 the two priority fields seem to be wrong. I expected 

|1 0 0 0 0 0 0 0|

and

|1 1 1 1 1 1 1 1|

---

[G.694.1] seems to appear as a normative and informative reference.
Furthermore, it isn't actually referenced, but then neither is
[G.694.2].