[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt
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
At 06:58 07/10/09, Young Lee wrote:
>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
-------------------------------------
Wataru Imajuku, Ph.D.@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-46-859-5541