Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt

From: [email-masked]
Date: Thu, 21 Feb 2013 00:33:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control
	Author(s)       : Fatai Zhang
                          Guoying Zhang
                          Sergio Belotti
                          Daniele Ceccarelli
                          Khuzema Pithewan
	Filename        : draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt
	Pages           : 28
	Date            : 2013-02-21

Abstract:
   ITU-T Recommendation G.709 [G709-2012] has introduced new Optical
   channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex)
   and enhanced Optical Transport Networking (OTN) flexibility.

   This document updates RFC4328 to provide the extensions to the
   Generalized Multi-Protocol Label Switching (GMPLS) signaling to
   control the evolving OTN addressing ODUk multiplexing and new
   features including ODU0, ODU4, ODU2e and ODUflex.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-signaling-g709v3-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 21 Feb 2013 08:38:50 +0000

Hi all,

Two major updates that the WG agreed: 

(1) Kept "Tolerance" field as proposed by Zafar. 
(2) Removed "N" field for ODUflex(GFP) as we all agreed (ie., crank-back to version 05).

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 21, 2013 4:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt

Abstract:

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 25 Feb 2013 14:51:45 -0500

Fatai, Authors,

Looks like forward progress, but some comments/questions from the prior
versions are still open:

>From mail I sent off-list:
On 2/17/2013 8:04 PM, Lou Berger wrote:
> - It would be good to resolve all warnings. I have to say that I
> always find the IPR related sections to be particularly painful.
> Please review the related portions of Section 2.2. of 
> https://www.ietf.org/id-info/checklist.html and verify that you
> (authors and contributors) have complied with the requirements.
> Revise if/how you see necessary.
> 
> - WRT the NVC and MT definitions: Shouldn't their usage with flex
> signal types be defined as flex wasn't supported in 4328 and the data
> plane only allows for a single behavior? (either ignored or must be
> set to 0 and 1, if I understand it correctly.)
> 
> - In a number of places you say "this field is not necessary and MUST
> be set to 0", wouldn't it be better to either just ignore the field
> or treat it as reserved? i.e., either "this field MUST be ignored" or
> "this MUST be set to zero on transmission and MUST be ignored on
> receipt. This field SHOULD be passed unmodified by transit nodes."
> 
> Also don't forget to respond to my open question on the list regarding
> client signals
> (http://www.ietf.org/mail-archive/web/ccamp/current/msg14542.html).

>From earlier discussions, WRT:

   For a particular sender in a session, the contents of the FLOWSPEC
   object received in a Resv message SHOULD be identical to the contents
   of the SENDER_TSPEC object received in the corresponding Path
   message. If the objects do not match, a ResvErr message with a
   "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.

Given the defined data plane constraints, is there ever a valid case
where the ResvErr message shouldn't be generated, i.e., is this a SHOULD
or a MUST?

You previously said:
> [Fatai] Accepted and updated.

But this was (and remains) a question, and I don't think there was any
change to the text.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 25 Feb 2013 22:48:12 +0000

Hi Lou,

Sorry for forgetting to re-visit some of your points after we discussed ODUflex-related encoding stuff. 

See more in-line below.

Thanks

Fatai

________________________________________
发件人: Lou Berger [[email-masked]]
发送时间: 2013年2月26日 3:51
到: Fatai Zhang
Cc: [email-masked]; [email-masked]
主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt

Fatai, Authors,

> Revise if/how you see necessary.

[Fatai] I don't see any warnings through NITS checking.

> set to 0 and 1, if I understand it correctly.)

[Fatai]   I think MT should be applicable for ODUflex. For your question, do you mean that the following text in Section 6.3 is not sufficient? If Yes, could you give specific proposed text?

Support for Virtual Concatenation of ODU1, ODU2 and ODU3 signal  types, as defined by [RFC6344], is not modified by this document.  Virtual Concatenation of other signal types is not supported by  [G709-2012]. 
Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328]. 

> receipt. This field SHOULD be passed unmodified by transit nodes."

[Fatai] Sorry for forgetting to revisit this comment. I would prefer to treating it as reseved. I will update it in the next version.

> (http://www.ietf.org/mail-archive/web/ccamp/current/msg14542.html).

[Fatai] OK. I saw Sergio replied you off-line.  I will ask Sergio to forward his mail to the list.

[Fatai] OK. I will change "SHOULD" to "MUST".

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 25 Feb 2013 18:16:22 -0500

Fatai,
	See below.

> Sorry for forgetting to re-visit some of your points after we discussed ODUflex-related encoding stuff. 
The -07 rev triggers what is now called a "warning"

-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
   have content which was first submitted before 10 November 2008.  The
   disclaimer is necessary when there are original authors that you have
   been unable to contact, or if some do not wish to grant the BCP78 rights
   to the IETF Trust.  If you are able to get all authors (current and
   original) to grant those rights, you can and should remove the
   disclaimer; otherwise, the disclaimer is needed and you can ignore this
   comment. (See the Legal Provisions document at
   http://trustee.ietf.org/license-info for more information.)

I suspect that the final paragraph of the -06 section was added in
response to the following warning with -05

-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
   have content which was first submitted before 10 November 2008.  If you
   have contacted all the original authors and they are all willing to grant
   the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
   this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
   (See the Legal Provisions document at
   http://trustee.ietf.org/license-info for more information.)

So nits will give you a warning either way, the question is which way
accurately reflects the authors view of the right IPR statements. My
personal experience has been that the warning seen in -05 can be ignored
in most cases unless doing a bis.

My request to the authors is to verify that the document IPR/Copy Right
Notices are accurate (and that you are getting the intended warning from
ipnits.)

> [Fatai]   I think MT should be applicable for ODUflex. For your
> question, do you mean that the following text in Section 6.3 is not
> sufficient? If Yes, could you give specific proposed text?
> 
> Support for Virtual Concatenation of ODU1, ODU2 and ODU3 signal
> types, as defined by [RFC6344], is not modified by this document.
> Virtual Concatenation of other signal types is not supported by
> [G709-2012]. Multiplier (MT) usage is as defined in [RFC6344] and
> [RFC4328].
How about:

   NVC: 16 bits
      As defined in [RFC4328] Section 3.2.3. This field MUST be set to
      0 for ODUflex signal types.

   Multiplier (MT): 16 bits
      As defined in [RFC4328] Section 3.2.4.This field MUST be set to
      1 for ODUflex signal types.

> [Fatai] Sorry for forgetting to revisit this comment. I would prefer
> to treating it as reseved. I will update it in the next version.
> 

okay.

> [Fatai] OK. I saw Sergio replied you off-line. 

Oops, I must have missed his response.  I'll take a look, but it would
be best to have it answered on list in any case.

> I will ask Sergio to
> forward his mail to the list.
> 

> [Fatai] OK. I will change "SHOULD" to "MUST".

okay, wasn't if there was a reason to have SHOULD vs MUST.

Thanks for the quick response!

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 25 Feb 2013 23:50:01 +0000

Hi Lou,

For the IPR disclaimer, I think the authors need to check again. 

If all the authors agree to use version 05 statement, I would accept your suggestion to remove pre-RFC5378 disclaimer.

Thanks

Fatai

________________________________________
发件人: Lou Berger [[email-masked]]
发送时间: 2013年2月26日 7:16
到: Fatai Zhang
Cc: [email-masked]; [email-masked]
主题: Re: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt

Fatai,
        See below.

How about:

   NVC: 16 bits

   Multiplier (MT): 16 bits

okay.

Lou