抄送： zhangfatai <at> huawei.com;
fu.xihua <at> zte.com.cn; dbrungard <at> att.com; lberger <at> labn.net;
diego.caviglia <at> ericsson.com; daniele.ceccarelli <at> ericsson.com;
zhangguoying <at> mail.ritt.com.cn; xuyunbin <at> mail.ritt.com.cn
Hi Fatai and all:
I agree with the issues of excessive number of labels if using the same
label concept of RFC4328. By using bit map for label encoding is a good
idea. And from my understanding,
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00 can merge this bit
map idea if Fatai agree.
For backward compatibility, we can not assume that RFC4328 is not
deployed unless we can provide some kind of survey report. So currently
the right assumption is that RFC4328 has been deployed, and backward
compatibity should be considered.
Best Regards
Lizhong Jin
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Jul 2009 11:33:56 +0200
From: "BELOTTI SERGIO" <Sergio.Belotti <at> alcatel-lucent.it
>
Subject: [CCAMP] R: Discussion about the GMPLS Signaling Extension
forEvolutive OTN
To: "Fatai" <zhangfatai <at> huawei.com >,
<fu.xihua <at> zte.com.cn >,
<dbrungard <at> att.com >, <lberger <at> labn.net >,
<diego.caviglia <at> ericsson.com >,
<daniele.ceccarelli <at> ericsson.com >,
<zhangguoying <at> mail.ritt.com.cn >,
<xuyunbin <at> mail.ritt.com.cn >
Cc: ccamp <at> ietf.org
Message-ID:
<3F44186D7141E247972EAC6655B0A29101FA7A56 <at> FRVELSMBS21.ad2.ad.alcatel.com
>
Content-Type: text/plain; charset="iso-8859-1"
Dear Fatai and all,
We agree on the major points raised by Fatai as general issue to be
solved in the context of extension needed to cope with new containers
defined in ITU q11 context, in addition to handling ODU multiplexing
scenarios in existing OTN.
There are two basic points that brings to the need to update the RFC4328
anyway.
1) the present RFC does not permit the link based negotiation for time
slot allocation . No information about tributary port numbers is present
and only in case we have "single layer" , no multiplexing LO --
> HO you
can apply . So this is a lack against the original G.709 even without
considering G.709 Am3 .
2) Scalability: The extension required in the context of new OTN with
the introduction of ODU0, ODU4, and above all ODUflex , required a real
modifications of the structure of the label to avoid real big size of
number of labels to transmit offloading signalling session. Extension
based on RFC4328 logic do not scale when ODU-flex is used. Large ODU
flex containers will generate
an excessive number of labels (in principle up to 80 per link) causing
problems with the size of the RSVP-TE message.
This two points together call to the need to change something in RFC.
Backward compatibility aspects, present in all the drafts, are surely to
be considered and if there are single layer systems deployed using
RFC4328 this should be grandfathered.
Best Regards
Sergio
Sergio Belotti
CTO Optics Division
Alcatel-Lucent
+39 039 6863033
+39 039 6863590
________________________________
Da: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] Per conto di
Fatai
Inviato: mercoled? 29 luglio 2009 18.33
A: fu.xihua <at> zte.com.cn; dbrungard <at> att.com; lberger <at> labn.net;
diego.caviglia <at> ericsson.com; daniele.ceccarelli <at> ericsson.com;
zhangguoying <at> mail.ritt.com.cn; xuyunbin <at> mail.ritt.com.cn
Cc: ccamp <at> ietf.org
Oggetto: Re: [CCAMP] Discussion about the GMPLS Signaling Extension
forEvolutive OTN
Hi all,
To support the current verison of G.709, we think the label format
defined in RFC4328 need to be re-defined anyway. The new OTN label
format should support the whole ODU sets, not only the ODU1, 2, and 3,
but also ODU0, ODU4, even ODUFlex. The following three aspects should be
considered carefully:
1) The extensibility of the label format is the first thing we should
consider. With the development of OTN technology, RFC4328 label format
style needs to be extended to support the new bitrate ODU (eg. ODU5,
6...). By the end, we may need keep extending the label formats.
Managing lots of label format may cause big trouble, so we need one-shot
label format for the evolving OTN.
2) Scalability is another key issue. RFC4328 style format may result in
big size of the total labels, which definitely increase the burden of
the signaling. An efficient approach is needed to carry the same label
information but with less amount of the data, bitmap style is the right
way to go.
3) For backward compatibility, if there are no implementations for
RFC4328 (or if there are no deployments it is desirable to deprecate
even if it is uncomfortable for existing implementations), it is very
safe to deprecate the old definition, and an extensible, efficient and
scalable solution could be helpful. The label defined in draft-zhang
does not overwrite RFC4328, it can allow the old definition to continue
to exist.
Hope this can clarify your concern.
Authors of draft-zhang
----- Original Message -----
From: fu.xihua <at> zte.com.cn
To: dbrungard <at> att.com ; lberger <at> labn.net ; zhangfatai <at> huawei.com
; diego.caviglia <at> ericsson.com ; daniele.ceccarelli <at> ericsson.com
Cc: ccamp <at> ietf.org
Sent: Tuesday, July 28, 2009 5:33 PM
Subject: Discussion about the GMPLS Signaling Extension for
Evolutive OTN
Hi Fatai and All,
We have presented the following two document in the CCAMP
morning session. But we have no more time to further discuss GMPLS
extension for evolutive OTN
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-00.txt
l-otn-00 >
draft-zhang-ccamp-gmpls-evolving-g709-01.txt
>
We have a couple of comments and questions for the draft-zhang.
(1) draft-zhang defined the extensions including what has been
done in RFC4328 (i.e., ODU1, ODU2 and ODU3).
draft-ceccarellifuxh defined new Gneralized Label only for
new application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e,
ODU3e1, ODU3e2, ODUflex and ODU4).
draft-ceccarellifuxh is only a supplement of RFC4328.
How can we used RFC4328 and draft-zhang ?
Any way, if we need to update an previous RFC, we should
assume that it has been deployed, not asking if someone did or not.
(2) Do you really want to remove NMC from the Traffic
Parameters?
If you do that, I think we have to abandon RFC4328.
(3) The compatibility consideration in draft-zhang.
We don't think the extensions in draft-zhang can coexist with
RFC4328.
You point out "we can just do some translation or mapping in
the new nodes".
But before the translation or mapping, you have to know the
Generalized Label Format.
We concern about:
i) How does one node know the Generalized Label format,
especially for ODU1, ODU2 and ODU3 base on your solution?
It may depend on the capability of the adjacent network
element.
ii) But how can the control plane know the adjacent network
element's capability without discovery mechanism?
You should know that GMPLS signaling extension should be
independent on the discovery mechanism and the configuration of
management plane.
iii) The control plane don't need to know the G.709(2003/03)
or G.709 Amendment3 network element?
In a word, we think it can not do the translation and
mapping. So we can not get the compatibility with RFC4328 in
draft-zhang.
(4) The Generalized Label in draft-zhang
- managing a variable length label could be a mess.
- draft-zhang uses a first part of the label which has fixed
values and then a variable number of bit that is the bitmap.
The bitmap can be long from 0 to 80 bits depending on the
signal type.
- the value of the bitmap is not independent but depends on
the values of two previous fields (ODUk and ODUj) and becomes reserved
in case of K=J
- a bitmap label have not been used nor in SDH and not in
WSON where a fixed label (4 bytes) is used.
Xihua Fu
ZTE
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
4/attachment.htm >
------------------------------
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
End of CCAMP Digest, Vol 14, Issue 26
*************************************
.
>
> thx
> G
>
>> Implications for CCAMP: An impairment information model is needed.
>> Distributed impairment validation (via signaling) could be possible.
>>
>> General comments: it would seem to be the responsibility of the WSON
>> network designer to insure that the network is operating in a
>> "region" where these linear approximations for impairments are valid.
>> This seems beyond the purview of a standards organization to specify.
>>
>> An architecture to accommodate this case is contained in the WSON
>> impairment framework draft.
>>
>>
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP <at> ietf.org
>> 
RSS Feed