Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt

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

Hi,

I think this draft is introducing a useful feature for LSC networks by 
allowing lambda labels to have a global semantic.

Although this work is functionally not an absolute requirement (it is always 
possible to map lambdas on a hop-by-hop basis) it is clearly a 
simplification to have a common semantic just as in the TDM label case.

Here are some nits and issues in the current draft.

===
Abstract
You should not use square bracket [ ] references in the Abstract
===
Abstract
d/ and getting significant/
===
Abstract
"new generation"
Do you mean "next generation" or "new"?
===
Abstract
s/proposes/defines/
===
Section 3
s/vendors?  network is/vendors'  networks are/
===
Section 3
 "It is needless to say, a LSP must be appropriately provisioned
  between a selected pair of ports within Domain A, considering
  wavelength information. Even over multiple domains, a LSP must be
  accordingly established satisfying wavelength constraints."
I'm having some trouble parsing this paragraph!
===
Figure 2
The node numbers in figure 2 don't match those in figure 1, and that is 
confusing since it is supposed to show the details of the connection shown 
in figure 1.
===
Section 4
I think you need to be careful here.
These requirements should probably not be expressed in RFC2119 language.
Reference to advertising labels is a distraction. I understand that this is 
interesting to you, but as described in the text here and in 
draft-bernstein-ccamp-wavelength-switched-01.txt there are some considerable 
concerns about extending the IGPs to carry label identifiers. I suggest you 
restrict your I-D to the identification of lambdas in GMPLS labels and let 
future work decide how these encodings might be used outside signaling.
===
Section 5.2
It looks like you have already almost run out of Channel Spacing bits in the 
CS field. Given that technology developments are likely to find ways of 
decreasing the channel spacing, I would suggest allocating another bit to 
the CS field.
Similarly, n is limited to 511 (if my bit counting is right), and it seems 
to me that the potential for more than 500 lambdas on a fiber is not so 
improbable.
So, how about...
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |S|    Reserved   |               n               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
===
Section 5.3
To correspond with the field placement suggested for section 5.2, I would 
suggest the following for CWDM.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |     Reserved        |              Lambda               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
===
Section 6.1
I think some of the progression here is faulty.
We have:
 "An all-optical network imposes the Lambda continuity constraint, that
  is, a label cannot be changed hop by hop, but must have an end to end
  scope.

  The above is not supported by RFC3471 that states that a label has
  significance only between two neighbors."
It is true that 3471 lambda labels only have link-local significance, but 
that does not mean that end-to-end lambda continuity cannot be supported. 
Nor does it mean that the label must or must not be changed hop-by-hop.

I suspect that the whole of section 6.1 is surplus to the needs of this I-D, 
and could be dropped without any problem.
The two things you do need in this section are:
1. How do I use a new Lambda Label?
  Answer: in all of the places that an existing Generalized
  Label can be used.
2. How do I tell when a new Lambda Label is being used
  and when an existing Generalized Label is being used?
  Does this remain a link local issue (as it always has done)
  or do you propose to define a new field value in the
  Generalized label Request or a new C-Type for the
  Generalized Label Object?
===
Section 6.2
As mentioned before, I think that discussion of advertising lambda 
availability is best removed from this I-D.
===
Section 7
You might like to consider that the use of a global semantic makes the 
control plane signaling information slightly more vulnerable to snooping and 
external control. I don't think this changes the security model, but you 
should mention the fact.
===
Section 10
I think [G.694.1] and [G.694.2] are probably normative references.
===

Cheers,
Adrian