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

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 [lberger@labn.net]
发送时间: 2013年2月26日 3:51
到: Fatai Zhang
Cc: ccamp@ietf.org; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt

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.

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

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

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

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

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

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

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

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?

[Fatai] OK. I will change "SHOULD" to "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

On 2/21/2013 3:38 AM, Fatai Zhang wrote:
> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Thursday, February 21, 2013 4:33 PM
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt
>
>
> 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/
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>