Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 21 Oct 2009 19:42:15 +0200

Dear authors, 

Thanks for submitting your document on "Framework for GMPLS and PCE
Control of G.709 Optical Transport Networks".

We have reviewed the document and we are a little bit concerned to find
out that some significant items described in the document are not
aligned with what is defined in G.709.

Especially the mappings into ODU3e1 and ODU3e2 are only defined in
G.Sup43 which is not a standard. 

In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and
ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are
4x ODU2e.

We are afraid that this is not inline with the view of the majority of
participants in SG15/Q11.

Except of the extensions that are already described in two draft
(draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn,
draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3,
4 is copied from ITU standards. Would not it be better to just refer to
the ITU-T document?

Best regards,

Nurit

	> -----Original Message-----

	> From: [email-masked] 

	> [mailto:[email-masked]] On Behalf Of ext 

	> [email-masked]

	> Sent: Friday, October 16, 2009 11:45 AM

	> To: [email-masked]

	> Subject: I-D
Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt 

	> A New Internet-Draft is available from the on-line 

	> Internet-Drafts directories.

	>     Title           : Framework for GMPLS and PCE Control 

	> of G.709 Optical Transport Networks

	>     Author(s)       : F. Zhang, et al.

	>     Filename        :
draft-zhang-ccamp-gmpls-g709-framework-00.txt

	>     Pages           : 27

	>     Date            : 2009-10-16

	> This document provides a framework for applying Generalized
Mulit-

	> Protocol Label Switching (GMPLS) and the Path Computation
Element 

	> (PCE) architecture to the control of G.709 Optical Transport
Networks 

	> (OTN) as specified in the ITU-T G.709 recommendation,
including the 

	> enhanced functionality in the recently consented revision. 

	> zhang

	>   Expires April 2010

	>   [page 1] 

	> draft-zhang-ccamp-gmpls-g709-framework-00.txt

	>   October 2009 

	> Conventions used in this document 

	> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", 

	> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this 

	> document are to be interpreted as described in [RFC2119].

	> A URL for this Internet-Draft is:

	> http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7

	> 09-framework-00.txt

	> Internet-Drafts are also available by anonymous FTP at:

	> ftp://ftp.ietf.org/internet-drafts/

	> Below is the data which will enable a MIME compliant mail
reader

	> implementation to automatically retrieve the ASCII version of
the

	> Internet-Draft.

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 23 Oct 2009 15:40:18 +0800

Hi Nurit,

Thanks for your comments.

Please see below for in-line responses.

Thanks

Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
  ----- Original Message ----- 
  From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
  To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Cc: Clemens, Rainer (NSN - DE/Munich) ; [email-masked] ; Soininen, Jonne (NSN - FI/Espoo) 
  Sent: Thursday, October 22, 2009 1:42 AM
  Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

  Dear authors, 

  Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks".

  We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709.

  Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard. 

  In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e.

  [Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard currently,so I think we have some options for this. (1)add a note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) change the title of this draft to "Framework for GMPLS and PCE Control of Optical Transport Networks" (3) move ODU3e2  to an appendix.  

  In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because they are being developed in ITU-T and may be accepted by ITU-T some day.

  I will reflect this in the next version. 

  We are afraid that this is not inline with the view of the majority of participants in SG15/Q11.

  [Fatai] I don't know whether it is true or not. But I think we can hear the opinions from SG15/Q11.

  Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document?

  [Fatai]  In Section 3, some part of information is from G.709 and G.872 and we reference this recommendations explicitly. We just try to give a brief overview of OTN to CCAMP experts from the perspective of Control Plane and make everyone quickly understand why we need more considerations on OTN control. I think it is really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for  Section 4, I don't know why you said that it is copied from ITU standards.  In Section 4, it describes the connection management model for OTN networks, which is based on our understanding and some discussions in ITU-T Q12. 

  Best regards,

  Nurit

    > Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt 

    >     Filename        : draft-zhang-ccamp-gmpls-g709-framework-00.txt

    > This document provides a framework for applying Generalized Mulit-

    > Protocol Label Switching (GMPLS) and the Path Computation Element 

    > (PCE) architecture to the control of G.709 Optical Transport Networks 

    > (OTN) as specified in the ITU-T G.709 recommendation, including the 

    > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 

    > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

    > Below is the data which will enable a MIME compliant mail reader

    > implementation to automatically retrieve the ASCII version of the

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 23 Oct 2009 15:40:56 +0200

Hi Fatai,

Thanks for your response.

Referring to a document which is not a standard is problematic and even
confusing. I am not sure that all the IETF colleagues could realize that
a supplement document in the ITU-T is not considered as a standard. As
you agreed below, G.Sup43 is NOT a standard. 

I believe it is NOT in the scope of CCAMP to define the dataplane
behavior of ODU switching...we can define a control plane for a standard
dataplane and refer to the dataplane standard behavior. 

Once (and if) it is defined as a standard behavior in the ITU-T, there
will be room to specify an extension for GMPLS (if necessary) to support
it. 

Also, I would like to note that it was NEVER discussed in SG1/Q11 to
allow other mappings than ODU2e into ODU3e. It was even explicitly
stated that no other mapping should be described in G.Sup43. The WP3
report from the plenary in December 2008 states that :"After discussion,
the agreement was reached to document two versions of ODU3e, one based
on the Huawei and CMCC proposal (using the eventual GMP chosen for ODU4)
and the other based on the NTT and Japan proposals.  Agreement was
reached to only document the mapping of four 10GBASE-R clients into each
of these two versions of ODU3e in an updated G.Sup43.".

Nevertheless, even if specified in G.Sup43, we need to keep in mind that
this is NOT a standard and we cannot refer to it as such.

Best regards,

Nurit

________________________________

From: ext Fatai Zhang [mailto:[email-masked]] 
Sent: Friday, October 23, 2009 9:40 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN -
FI/Espoo); Li Dan; han jianrui; [email-masked]
Subject: Re: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

Hi Nurit,

 

Thanks

Fatai

	----- Original Message ----- 

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
<mailto:[email-masked]>  

	To: [email-masked] ; [email-masked] ;
[email-masked] ; [email-masked] 

	Cc: Clemens, Rainer (NSN - DE/Munich)
<mailto:[email-masked]>  ; [email-masked] ; Soininen, Jonne (NSN
- FI/Espoo) <mailto:[email-masked]>  

	Subject: RE: I-D

	Dear authors, 

	Thanks for submitting your document on "Framework for GMPLS and
PCE Control of G.709 Optical Transport Networks".

	We have reviewed the document and we are a little bit concerned
to find out that some significant items described in the document are
not aligned with what is defined in G.709.

	Especially the mappings into ODU3e1 and ODU3e2 are only defined
in G.Sup43 which is not a standard. 

	In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2
and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43
are 4x ODU2e.

	[Fatai] Yes, you are right and we also indicated in this draft
that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not
standard currently,so I think we have some options for this. (1)add a
note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly
(2) change the title of this draft to "Framework for GMPLS and PCE
Control of Optical Transport Networks" (3) move ODU3e2  to an appendix.

	In addition, I think we can cover ODU3e1 and ODU3e2 in this
draft at this stage (i.e., individual draft), because they are being
developed in ITU-T and may be accepted by ITU-T some day.

	 

	We are afraid that this is not inline with the view of the
majority of participants in SG15/Q11.

	[Fatai] I don't know whether it is true or not. But I think we
can hear the opinions from SG15/Q11.

	[Fatai] In Section 3, some part of information is from G.709 and
G.872 and we reference this recommendations explicitly. We just try to
give a brief overview of OTN to CCAMP experts from the perspective of
Control Plane and make everyone quickly understand why we need more
considerations on OTN control. I think it is really tough for everyone
to go through G.709, G.872 and other recommendations detailedly. As for
Section 4, I don't know why you said that it is copied from ITU
standards.  In Section 4, it describes the connection management model
for OTN networks, which is based on our understanding and some
discussions in ITU-T Q12. 

	Best regards,

	Nurit

including the

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 26 Oct 2009 20:55:48 +0800

Hi Nurit,

Thanks for your further comments.

We think we can move the content of G.sup43 to an appendix ( just for information), and explain that this part of information is not consented by ITU-T SG15.

We can also remove this appendix later, if this draft is ready to be RFC and the content of G.sup43 is still not consented (i.e., non-standard).

Is it OK for you? :-)~~~~, If Yes, we will reflect it in the next version.

Thanks

Fatai
 
  ----- Original Message ----- 
  From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
  To: ext Fatai Zhang 
  Cc: Clemens, Rainer (NSN - DE/Munich) ; CCAMP ; Soininen, Jonne (NSN - FI/Espoo) ; Li Dan ; han jianrui ; [email-masked] 
  Sent: Friday, October 23, 2009 9:40 PM
  Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

  Hi Fatai,

  Referring to a document which is not a standard is problematic and even confusing. I am not sure that all the IETF colleagues could realize that a supplement document in the ITU-T is not considered as a standard. As you agreed below, G.Sup43 is NOT a standard. 

  I believe it is NOT in the scope of CCAMP to define the dataplane behavior of ODU switching.we can define a control plane for a standard dataplane and refer to the dataplane standard behavior. 

  Once (and if) it is defined as a standard behavior in the ITU-T, there will be room to specify an extension for GMPLS (if necessary) to support it. 

  Also, I would like to note that it was NEVER discussed in SG1/Q11 to allow other mappings than ODU2e into ODU3e. It was even explicitly stated that no other mapping should be described in G.Sup43. The WP3 report from the plenary in December 2008 states that :"After discussion, the agreement was reached to document two versions of ODU3e, one based on the Huawei and CMCC proposal (using the eventual GMP chosen for ODU4) and the other based on the NTT and Japan proposals.  Agreement was reached to only document the mapping of four 10GBASE-R clients into each of these two versions of ODU3e in an updated G.Sup43.".

  Nevertheless, even if specified in G.Sup43, we need to keep in mind that this is NOT a standard and we cannot refer to it as such.

  Best regards,

  Nurit

------------------------------------------------------------------------------

  Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li Dan; han jianrui; [email-masked]

  Hi Nurit,

   

  Thanks

  Fatai

    ----- Original Message ----- 

     

    Dear authors, 

     

    Best regards,

    Nurit

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Oct 2009 17:36:20 +0100

Hi Fatai,
I think that in the IETF we should only put things in the normative part
of the document that is also normative in ITU-T, i.e. in this case only
what is written in the normative sections in G.709. 
Everything in G.Sup43 can go into an appendix, i.e. mappings of 4x ODU2e
into ODU3e1/2 and even OTU2e line signals. We should also mention what
is the actual status of the G.sup43. 
Other things that are being discussed in ITU-T and are not approved
should stay completely out.
Best regards,
Nurit 

Sent: Monday, October 26, 2009 2:56 PM

Hi Nurit,

We think we can move the content of G.sup43 to an appendix ( just for
information), and explain that this part of information is not consented
by ITU-T SG15.
 
We can also remove this appendix later, if this draft is ready to be RFC
and the content of G.sup43 is still not consented (i.e., non-standard).
 
Is it OK for you? :-)~~~~, If Yes, we will reflect it in the next
version.

Thanks
 
Fatai

	----- Original Message ----- 
	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
<mailto:[email-masked]>  
	To: ext Fatai Zhang <mailto:[email-masked]>  
	Cc: Clemens, Rainer (NSN - DE/Munich)
<mailto:[email-masked]>  ; CCAMP <mailto:[email-masked]>  ;
Soininen, Jonne (NSN - FI/Espoo) <mailto:[email-masked]>  ; Li
Dan <mailto:[email-masked]>  ; han jianrui
<mailto:[email-masked]>  ; [email-masked] 
	Sent: Friday, October 23, 2009 9:40 PM
	Subject: RE: I-D
Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

	Hi Fatai,

	Referring to a document which is not a standard is problematic
and even confusing. I am not sure that all the IETF colleagues could
realize that a supplement document in the ITU-T is not considered as a
standard. As you agreed below, G.Sup43 is NOT a standard. 

	I believe it is NOT in the scope of CCAMP to define the
dataplane behavior of ODU switching...we can define a control plane for
a standard dataplane and refer to the dataplane standard behavior. 

	Once (and if) it is defined as a standard behavior in the ITU-T,
there will be room to specify an extension for GMPLS (if necessary) to
support it. 

	Also, I would like to note that it was NEVER discussed in
SG1/Q11 to allow other mappings than ODU2e into ODU3e. It was even
explicitly stated that no other mapping should be described in G.Sup43.
The WP3 report from the plenary in December 2008 states that :"After
discussion, the agreement was reached to document two versions of ODU3e,
one based on the Huawei and CMCC proposal (using the eventual GMP chosen
for ODU4) and the other based on the NTT and Japan proposals.  Agreement
was reached to only document the mapping of four 10GBASE-R clients into
each of these two versions of ODU3e in an updated G.Sup43.".

	Nevertheless, even if specified in G.Sup43, we need to keep in
mind that this is NOT a standard and we cannot refer to it as such.

	Best regards,

	Nurit

	From: ext Fatai Zhang [mailto:[email-masked]] 
	Sent: Friday, October 23, 2009 9:40 AM
	To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne
(NSN - FI/Espoo); Li Dan; han jianrui; [email-masked]
	Subject: Re: I-D
Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

	Hi Nurit,

	 

	Thanks

	Fatai

		----- Original Message ----- 

		Subject: RE: I-D

		Dear authors, 

		Thanks for submitting your document on "Framework for
GMPLS and PCE Control of G.709 Optical Transport Networks".

		We have reviewed the document and we are a little bit
concerned to find out that some significant items described in the
document are not aligned with what is defined in G.709.

		Especially the mappings into ODU3e1 and ODU3e2 are only
defined in G.Sup43 which is not a standard. 

		In addition G.Sup43 does not define mappings of ODU0,
ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined
in G.Sup43 are 4x ODU2e.

		[Fatai] Yes, you are right and we also indicated in this
draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is
not standard currently,so I think we have some options for this. (1)add
a note to explain that ODU3e1 and ODU3e2 are still non-standard
explicitly (2) change the title of this draft to "Framework for GMPLS
and PCE Control of Optical Transport Networks" (3) move ODU3e2  to an
appendix.  

		In addition, I think we can cover ODU3e1 and ODU3e2 in
this draft at this stage (i.e., individual draft), because they are
being developed in ITU-T and may be accepted by ITU-T some day.

		 

		We are afraid that this is not inline with the view of
the majority of participants in SG15/Q11.

		[Fatai] I don't know whether it is true or not. But I
think we can hear the opinions from SG15/Q11.

		Except of the extensions that are already described in
two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn,
draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3,
4 is copied from ITU standards. Would not it be better to just refer to
the ITU-T document?

		[Fatai] In Section 3, some part of information is from
G.709 and G.872 and we reference this recommendations explicitly. We
just try to give a brief overview of OTN to CCAMP experts from the
perspective of Control Plane and make everyone quickly understand why we
need more considerations on OTN control. I think it is really tough for
everyone to go through G.709, G.872 and other recommendations
detailedly. As for  Section 4, I don't know why you said that it is
copied from ITU standards.  In Section 4, it describes the connection
management model for OTN networks, which is based on our understanding
and some discussions in ITU-T Q12. 

		Best regards,

		Nurit

---

From: [email-masked]
Date: Thu, 29 Oct 2009 14:55:58 +0800

Hi Nurit,

I agree with you. All content of section 3 in this draft  is from G.709. 
In order to be consistent with G.709 (e.g., ODU3 shoudl occupy 31 of the 
80 TS in ODU4 based on the current G.709 Amd3), I suggest the whole 
content about G.709 be just refered to G.709 or move to the Appendix.

Best Regards,
Xihua Fu
ZTE Corporation

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
发件人:  [email-masked]
2009-10-29 上午 12:36

收件人
"ext Fatai Zhang" <[email-masked]>
抄送
"Clemens, Rainer \(NSN - DE/Munich\)" <[email-masked]>, "Soininen, 
Jonne \(NSN - FI/Espoo\)" <[email-masked]>, CCAMP <[email-masked]>
主题
Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

Hi Fatai,
I think that in the IETF we should only put things in the normative part 
of the document that is also normative in ITU-T, i.e. in this case only 
what is written in the normative sections in G.709. 
Everything in G.Sup43 can go into an appendix, i.e. mappings of 4x ODU2e 
into ODU3e1/2 and even OTU2e line signals. We should also mention what is 
the actual status of the G.sup43. 
Other things that are being discussed in ITU-T and are not approved should 
stay completely out.
Best regards,
Nurit 

Hi Nurit,

 

 
Thanks
 
Fatai
 
----- Original Message ----- 
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
To: ext Fatai Zhang 
Cc: Clemens, Rainer (NSN - DE/Munich) ; CCAMP ; Soininen, Jonne (NSN - 
FI/Espoo) ; Li Dan ; han jianrui ; [email-masked] 
Sent: Friday, October 23, 2009 9:40 PM
Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

Hi Fatai,
 
Referring to a document which is not a standard is problematic and even 
confusing. I am not sure that all the IETF colleagues could realize that a 
supplement document in the ITU-T is not considered as a standard. As you 
agreed below, G.Sup43 is NOT a standard. 
I believe it is NOT in the scope of CCAMP to define the dataplane behavior 
of ODU switching…we can define a control plane for a standard dataplane 
and refer to the dataplane standard behavior. 
Once (and if) it is defined as a standard behavior in the ITU-T, there 
will be room to specify an extension for GMPLS (if necessary) to support 
it. 
 
Also, I would like to note that it was NEVER discussed in SG1/Q11 to allow 
other mappings than ODU2e into ODU3e. It was even explicitly stated that 
no other mapping should be described in G.Sup43. The WP3 report from the 
plenary in December 2008 states that :"After discussion, the agreement was 
reached to document two versions of ODU3e, one based on the Huawei and 
CMCC proposal (using the eventual GMP chosen for ODU4) and the other based 
on the NTT and Japan proposals.  Agreement was reached to only document 
the mapping of four 10GBASE-R clients into each of these two versions of 
ODU3e in an updated G.Sup43.".

Best regards,
Nurit

Hi Nurit,

 

Thanks
 
Fatai
 
----- Original Message ----- 
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
To: [email-masked] ; [email-masked] ; [email-masked] ; 
[email-masked] 
Cc: Clemens, Rainer (NSN - DE/Munich) ; [email-masked] ; Soininen, Jonne 
(NSN - FI/Espoo) 
Sent: Thursday, October 22, 2009 1:42 AM
Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

Dear authors, 

We have reviewed the document and we are a little bit concerned to find 
out that some significant items described in the document are not aligned 
with what is defined in G.709.
 
Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 
which is not a standard. 
In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and 
ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x 
ODU2e.
 
[Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 
and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard 
currently,so I think we have some options for this. (1)add a note to 
explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) 
change the title of this draft to "Framework for GMPLS and PCE Control of 
Optical Transport Networks" (3) move ODU3e2  to an appendix. 
In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this 
stage (i.e., individual draft), because they are being developed in ITU-T 
and may be accepted by ITU-T some day.
I will reflect this in the next version. 

[Fatai] I don't know whether it is true or not. But I think we can hear 
the opinions from SG15/Q11.
 
Except of the extensions that are already described in two draft 
(draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, 
draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 
is copied from ITU standards. Would not it be better to just refer to the 
ITU-T document?
 
[Fatai] In Section 3, some part of information is from G.709 and G.872 and 
we reference this recommendations explicitly. We just try to give a brief 
overview of OTN to CCAMP experts from the perspective of Control Plane and 
make everyone quickly understand why we need more considerations on OTN 
control. I think it is really tough for everyone to go through G.709, 
G.872 and other recommendations detailedly. As for  Section 4, I don't 
know why you said that it is copied from ITU standards.  In Section 4, it 
describes the connection management model for OTN networks, which is based 
on our understanding and some discussions in ITU-T Q12. 
 
Best regards,
Nurit

> _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp