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

From: Greg Bernstein <[email-masked]>
Date: Wed, 03 Oct 2007 10:46:38 -0700

Hi folks, I agree with Adrian that this draft is very valuable for LSC 
networks. In addition, it seems that  these "global semantic" labels can 
be very useful in characterizing optical subsystems and that information 
can feed into a PCE performing the routing and wavelength assignment 
problem.

For example a single wavelength drop port on a ROADM may be either a 
fixed lambda, or a range of lambda. So I'd like to characterize  this 
port with either one of your globally defined labels or via a range 
specified by by two of your nicely defined lambdas.

Note that in ultra high capacity systems multiple optical bands could be 
used. In 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt 
we estimated that to cover a wide band fiber at the narrowest channel 
spacing currently defined (12.5GHz) would require 4800 labels. Hence 
with advances in modulation formats and narrower channel spacing 
Adrian's suggestion of 16 bits for the "n" field below allows us to 
fully characterize a wide band fiber with room to grow.

Regards

Greg B.

Adrian Farrel wrote:
> 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.
---snip---
> ===
> 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               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ===
>
--snip--
> 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
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Dan Li <[email-masked]>
Date: Mon, 08 Oct 2007 15:22:22 +0800

Hi,

If the wavelength label only has the local significance, then the routing 
problem needs to be addressed only at the level of the TE link choice, 
and wavelength assignment can be resolved locally by the switches on 
a hop-by-hop basis.

But if we can have the "global semantic" labels, we can run into the 
wavelength level to choose the path.

I also agree with Adrian on the definition of the "global semantic" label,
current the 160 wavelengths per fiber WDM system is deployed by 
some carriers, and the 320 wavelengths per fiber is under developed. 
The 640 wavelengths per fiber is expected in the near future. So the
"n" field is better to be expanded, and leave some room for the new 
technologies. 

Regards,

Dan

---

From: Tomohiro Otani <[email-masked]>
Date: Mon, 08 Oct 2007 21:05:00 +0900

Hi Adrian, Greg and Dan,

Thank you very much for your comments and feedback.
We will update the draft and distribute it for reviewing.

I basically agree with more wavelength channels. At this moment,
how many wavelengths should we support ? 1024 ?
(I was a guy of transmission, but at that time, it was 8 to 16...)

With best regards,

Tomo

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 08 Oct 2007 12:08:19 -0700

Hi Tomo et. al., I know that the 16 bits that Adrian suggested seems
like a lot, but wouldn't we'd like to describe the full range of the
latest fibers (this doesn't mean all the channels are populated!!!) at a
narrow spacing.

At the low end of the U-band is 1675nm (179.0THz), and the high end of
the O-band is 1260nm (237.9THz), and we're basing the center (per ITU-T)
at 193.1THz.

So positive n would go to 3586, and negative n would go to 1130. Now
given things could change in the future, tighter spacing with new
modulation formats it seems that 16 bits isn't out of the question.
Remember, that an MPLS LSR doesn't usually support 2^32 LSPs on a link
either ;-)

I was thinking about something involving optical bands but those
definitions aren't really firm and can't really see an advantage to that.

When it comes to reporting available lambda on a link then we may want
to look at ways to describe that usage in a very compact manner but I
think that can be orthogonal. For example if I have a 32 channel C-band
based system and I want a compact way to represent the usage (for
example in routing) I could use something like:

(Otani Lambda Label indicating low start frequency and spacing) +
(Channel Count m) + (Bit map that is m bits long with 0/1 indication
available/in use).

Similarly if I wanted to specify the range of a single wavelength
colorless drop port on a ROADM I could use something like:
(Otani Lambda Label indication low start frequency and spacing) +
(channel range as a 16 bit integer).

Hence, the revision to your format that Adrian suggested (below) seems
reasonable, provides for growth and we can leverage its use in many
other contexts!

Regards

Greg

---

From: Young Lee <[email-masked]>
Date: Mon, 08 Oct 2007 16:58:16 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Sunday, September 30, 2007 6:47 AM
To: [email-masked]
Cc: Tomohiro Otani; [email-masked]; K. Miyazaki; Diego Caviglia (GO/MCI)
Subject: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt

Hi,

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

---

From: Wataru Imajuku <[email-masked]>
Date: Sun, 14 Oct 2007 07:30:14 +0900

Hi, Tomo and Adrian

 As I commented before in this mailing list, this draft is useful.
 In my understanding, one of merit of Lambda label other than that Young pointed out 
is the elimination of some manual configuration of TE-Link attributes which were required in current specification for WDM links, specifically when handling "colorless" fibers between the add/drop port of ROADM/OXCs and single tunable laser in its client node.
 In this case, Lambda label well simplifies TE-Link configuration for the fibers which can possibly transmit optical signal in many wavelengths while only one signal channel is actually transmitted.

 Regarding to the question "a new C-Type for the Generalized Label Object?" which Adrian pointed out, current my understanding is as follows,

A) If we do not enforce "Lambda Labels" for all LSC nodes, and 
 1)  If we employ current C-type, nodes at termination of the TE-links should pre-negotiate each other whether the TE-Link is "Lambda" Label or not.
 2)  If we define new C-type, nodes can understand whether remote node identify the TE-link as is 
  "Lambda Label" link without pre-negotiation. We can pursuit the merit of Lambda Label mentioned above.
  But, requires new C-types (i.e. new extension)

B) If we do enforce "Lambda Labels" for all LSC nodes, 
 we can pursuit the merit of Lambda Label mentioned above without new C-type.
 Also, this helps to eliminate new burden for service providers taking care whether 
"Lambda Label" link or not for each TE-link. 
 But, this choice brings large impact on NEs which already developed.

 I can not speak which one is better selection at this moment, but how far pursuit 
the merit of "Lambda Label" to simplify the configuration seem one of important view point to determine solution.

Best Regards
Wataru

>to me that the potential for more than 500 lambdas on a fiber is not so 

-------------------------------------
Wataru Imajuku, Ph.D.@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-46-859-5541