Chair review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

And another draft...

Adrian

===
IPR boilerplate, blah blah

===

Abstract and Section 1

s/technology independent/technology-independent/

===

Section 1

s/Both of extensions/Both of these extensions/

===

In general, I think the definition of DCSC in this document is missing some 
clarity.

For example, in section 2 we have
  One type of
  switching that is not well represented in this current set switching
  that takes all data received on an ingress port and switches it
  through a network to an egress port.
which implies that you are describing a service request signaling type.

But you also have
  DCSC interfaces are able to
  support switching of the whole digital channel presented on single
  channel interfaces.

Perhaps a picture would help?
It might also be helpful to say in the document why FSC is not suitable.

I'm wondering if the D in DCSC actually stands for Digital.

===

IANA section

Along with the allocation from the Switching Type registry, you should 
remind IANA to make an entry in IANAGmplsSwitchingTypeTC at 
http://www.iana.org/assignments/ianagmplstc-mib

===

Sections 2 and 3

  Port labels, as defined in [RFC3471], SHOULD be used for LSPs
  signaled using the DCSC Switching Type.
3. Generalized Channel_Set Label Related Formats
  This section defines a new type of generalized label and updates
  related objects.

This text is not immediately obvious.
The Port label in 3471 is 32 bits.
The label defined in section 3 seems to have variable length depending on 
what it contains.

Perhaps the paragraph you need in section 2 is:
  Port labels, as defined in [RFC3471], SHOULD be used for LSPs
  signaled using the DCSC Switching Type in the Generalized Label
  Request object.

===

Section 3.1 (slightly ties in with the previous point)

It isn't clear from the text why you need a new type of label request 
object.
The reader might assume that it would be enough to set the switching type as 
is done for all other generalized labels.
In fact, it has been the operational assumption of GMPLS that the parameters 
of the Generalized Label Request were enough to set the context for the 
label type that would be used. It is a shame to reverse this.

===

Section 3.2

I would like you to make direct reference to RFC 4606. Why is label 
concatenation as described in section 3 not appropriate in this case? Why is 
it necessary to invent a new mechanism? (Yes, I know why, but you haven't 
explained the limitations of simple concatenation.)

What do you mean by:
  The format of the Generalized
  Channel_Set LABEL Object is based on the LABEL_SET object defined in
  [RFC3473].
I don't think it is. I think it is the format of the Channel_Set subobject 
that is based on the LABEL_SET object.

===

Section 3.2

     Subchannel: Variable

        See [RFC3471] for a description of this field. Note that this
        field may not be 32 bit aligned.

s/may/might/

I think it is worth highlighting the context for the meaning and the length 
of the subchannel ID

===

Section 3.3

Don't you think it is a layer of complexity too far to have a Label Set made 
up of a set of Channel_Set Labels each made up of a series of Channel_Set 
subobjects each made up of a set of channels?

What on earth is the meaning of the Label Set if the action is set to 
"inclusive range" or "exclusive range" and the label entries are Channel_Set 
labels? What if the Label Set says "inclusive list" and one of the 
Channel_Set subobjects says "exclusive list", or the other way around.

Perhaps you can set some limits on the action field in the Label Set etc?

===

Section 3.3

What happens with the use of this new label format in ERO and RRO label 
subobjects? Isn't there serious risk of this making RSVP-TE completely 
unworkable?

===

Section 5.
You should probably reference 
draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt

Doesn't a mechanism that allows a Path or Resv message to be legitimately 
grown to be extremely large cause concern for security?

===

Would it be possible to add a short section of backward compatibility?

===