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

[Lou Berger <[e-mail]>]

Fatai,
	See below.

On 2/25/2013 5:48 PM, Fatai Zhang wrote:
> 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 [[e-mail]]
> 发送时间: 2013年2月26日 3:51
> 到: Fatai Zhang
> Cc: [e-mail]; [e-mail]
> 主题: 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.
> 
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.)


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


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

okay.

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

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

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

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

Thanks for the quick response!

Lou
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
>> Sent: Thursday, February 21, 2013 4:33 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
>