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

[Young Lee <ylee@huawei.com>]

Hi, 

I think this draft (draft-otani-ccamp-gmpls-lambda-labels-00.txt) is hitting
an important need that would help RWA computation in general wavelength
switched optical network (WSON).  

A fixed mapping between the GMPLS lambda label space and the ITU-T WDM grid
(as suggested by Otani draft) would be very helpful to an entity that deals
with global computation such as PCE. As the PCE technology is envisioned as
a solution for RWA in WSON, global lambda label is the first step to be
agreed upon across the network entities. 

The only issue I can foresee is the right sizing of the lambda labels. It
should be scalable enough to accommodate future growth of WDM channels. 

Regards, 

Young 
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Adrian Farrel
Sent: Sunday, September 30, 2007 6:47 AM
To: ccamp@ops.ietf.org
Cc: Tomohiro Otani; ho-guo@kddilabs.jp; K. Miyazaki; Diego Caviglia (GO/MCI)
Subject: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt

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