[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

See in-line for responses...

On 2/19/2009 9:27 AM, Adrian Farrel wrote:


And another draft...


which is much appreciated!


Adrian

===
IPR boilerplate, blah blah

===

Abstract and Section 1

s/technology independent/technology-independent/


sure, whatever...

===

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.


done.


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


okay.


===

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.


how about:

    Port labels, as defined in [RFC3471], SHOULD be used for LSPs
    signaled using the DCSC Switching Type.  The DCSC Switching Type
    may be used with wither the in the Generalized Label Request
    object, [RFC3473], or the Generalized Channel_Set LABEL_REQUEST
    Object defined below.
keep in mind that Generalized Channel_Set and DCSC are orthogonal extensions... 


===

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.
the new request object is used to indicate that a channel_set label is to be used vs a generalized (or MPLS) label. I don't see how switching type can be used to request/indicate label type... 


===

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


added:
  Simple concatenation of
  labels as is done in [RFC4606] was deemed impractical given the large
  number of VLAN IDs (up to 4096) that may need to be communicated.


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.
yes. the subobject is part of the object so the statement is correct. the next sentence explains the difference. 



===

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/


sure.


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


can you be more specific? I don't understand what you are asking for.

===

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?
yes, this is a tad excessive. I'm not sure why anyone would construct such an object though... 



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.



nothing that can't be represented with some nice logical expressions.


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



Do you have a suggestions?


===

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?
actually, this is the whole reason to have the complete set defined in a single object (rather than the multiple objects used in LABEL_SET). The defined approach is better than the concatenated object approach where you have say, 1K concatenated labels, or the separate LSP approach where you have 1K LSPs each with a single label! 



===

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

okay



Doesn't a mechanism that allows a Path or Resv message to be
legitimately grown to be extremely large cause concern for security?
Growth of RSVP messages has been raised numerous times before, but I've never heard anyone suggest that there was a security consideration to such growth. What issue are you referring to? 



===

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


will do.

Thanks again for the feedback,
Lou

===