Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

[Fatai Zhang <[e-mail]>]

Hi Lou,



Sorry for late response because of my vacation.



Please see in-line below.









Best Regards



Fatai



-----Original Message-----
From: Lou Berger [mailto:[e-mail]]
Sent: Friday, January 04, 2013 5:51 AM
To: Fatai Zhang
Cc: CCAMP; [e-mail]
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04





Hi Fatai,

         Happy new year.  Please see below for responses.



On 12/25/2012 3:33 AM, Fatai Zhang wrote:

>

> Hi Lou,

>

> Please see in-line below.

>

> A new version will be issued after all open issues are resolved.

>

>

>

>

>

> Best Regards

>

> Fatai

>

>

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

>> From: Lou Berger [mailto:[e-mail]]

>> Sent: Thursday, December 20, 2012 10:12 PM

>> To: Fatai Zhang

>> Cc: CCAMP; [e-mail]

>> Subject: Re: 答复: [CCAMP] WG Last Call comments on

draft-ietf-ccamp-gmpls-signaling-g709v3-04

>>

>> Fatai/Authors,

>>          Thank you for the mail, and sorry about my delayed response. BTW

>> please feel free to continue discussing the remaining open issues on the

>> list and reaching closure on the list (on specific text/resolutions)

>> prior to publishing the next rev.

>>

>> Please see below for inline responses.

>>

>> On 12/7/2012 4:53 AM, Fatai Zhang wrote:

>>> Hi Lou,

>>>

>>> Please see how the LC comments addressed below.

>>>

>>> Best Regards

>>>

>>> Fatai

>>>

>>>

>>> -----邮件原件-----

>>> 发件人: [e-mail] [mailto:[e-mail]] 代表

Lou Berger

>>> 发送时间: 2012年10月22日 10:01

>>> 收件人: CCAMP; [e-mail]

>>> 主题: [CCAMP] WG Last Call comments on

draft-ietf-ccamp-gmpls-signaling-g709v3-04

>>>

>>> Authors,

>>>     I have the following LC comments:

>>>

>>> General comments:

>>>

>>> - This document also needs some addition work on conformance language.

>>> I'll try to point out cases in the detailed comments below.

>>>

>> [Fatai] OK. Checked and refined based on your detailed comments.

>>>

>>

>> I think this rev is an improvement, but there's still more work needed.

>> I have made some specific comments/suggestions below.

>>

>>> - Section 5 essentially defines a new set of traffic parameters.  Given

>>> the changes, why not ask for a new C-TYPE and not worry about [RFC4328]

>>> compatibility/description?

>>>

>> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly.

>>>

>>

>> Okay.

>>

>>> Detailed editorial and technical comments:

>>>

>>> - Please verify that abbreviations are defined before being used .

>>> There are a number of these.

>>>

>> [Fatai] Went through and updated.

>>

>> thanks.

>>

>>>

>>> - Please use a consistent decimal representation (sometimes commas are

>>> used other times periods)

>>>

>> [Fatai] OK. Commas are used.

>>

>> great, although a quick skim finds:

>> s/1,301.683.217/1,301,683.217

>>

>>

>>

>>>

>>> - the references [G709-v1] and [G709-v3] each actually refer to multiple

>>> documents, each documented needs to have it's own (correct) reference,

>>> i.g., [G709-v1] and [G709-v1a1]. The document text will need to be

>>> revisited to ensure the proper reference is made.

>>>

>> [Fatai] Accepted and used the same approach for framework draft.

>>

>> great

>>

>>

>>> -

>>>

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt

>>> shows there are unresolved nits that need to resolved .

>>

>>

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-05.txt

>> still shows a warning, notably:

>>

>>      (Using the creation date from RFC4328, updated by this document, for

>>      RFC5378 checks: 2005-01-17)

>>

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

>>

> [Fatai] Will update “Copyright Notice” section.



okay



>>

>>> I'm using line

>>> numbers from this url in my subsequent comments.

>>>

>> [...]

>>

>>> - Section 3.  Perhaps combine with section 1.

>>>

>> [Fatai] Accepted and refined.

>>>

>>

>> I don't see where this suggestion was followed, but that's okay, it was

>> just a suggestion.

>>

> [Fatai] OK.

>>

>> [...]

>>> - Section 5: assuming this is now a new c-type need text for that, as

>>> well as to formally defined the fields/field sizes.

>>>

>> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly.

>>

>> Formal field definitions are missing and need to be added.

>>



> [Fatai] The format is the same as RFC4328. Did you mean that it

> needs “Length”, “Class-Num” and “C-Type”? If yes, I will add

> them. If you mean that it needs text to define all the fields, I

> think the text is already there (then this comment may be related

> to your other comments below).



Its important to differentiate the syntax (i.e., format) from the

semantics (i.e., usage).  How about:



Signal Type: 8 bits

   As defined in [RFC4328] Section 3.2.1, with the following additional

values:

  (insert lines 266-285)



Reserved: 8 bits

   As defined in [RFC4328] Section 3.2.5.



Tolerance: 16 bits

   (insert lines 296-298)



NVC: 16 bits

   As defined in [RFC4328] Section 3.2.3.



Multiplier (MT): 16 bits

   As defined in [RFC4328] Section 3.2.4.



Bit_Rate: 32 bits

   (insert lines 290-294)



The other parts, lines 287-288, 300-319 should be merged into section 5.1.



[Fatai] Got it. OK to accept your suggestion and try to update the text in this way.



>>

>> Also the draft says:

>>

>>    Note that the error process on the traffic parameters MUST follow the

>>    rules defined in Section 6 of [RFC4328].

>>

>> Given the different fields, shouldn't any OTN-TDM related traffic

parameter processing now be defined in this document?

>>

> [Fatai] I just wanted to avoid the overlapped text (almost the same

text as RFC4328). Will accept your suggestion to expand the text as follows:

>

> There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either

> the Adspec is omitted or an Int-serv Adspec with the Default General

> Characterization Parameters and Guaranteed Service fragment is used,

> see [RFC2210].

>

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

>

> Intermediate and egress nodes MUST verify that the node itself, and

> the interfaces on which the LSP will be established, can support the

> requested Signal Type, NVC, Tolerance and Bit_Rate values. If the

> requested value(s) cannot be supported, the receiver node MUST

> generate a PathErr message with a "Traffic Control Error/Service

> unsupported" indication (see [RFC2205]).

>

> In addition, if the MT field is received with a zero value, the node

> MUST generate a PathErr message with a "Traffic Control Error/Bad

> Tspec value" indication (see [RFC2205]).

>



Is this a new section, perhaps 5.3?



[Fatai] Yes. Try to add a new section to describe what you want.



>>

>>>

>> [...]

>>>

>>> - Lines 320-336,338-346 are essentially repeated in sections 5.1 and

>>> 5.2, why not move this text into their respective sections?

>>>

>> [Fatai] Accepted and refined the text.

>>

>>

>> I don't see where this suggestion was followed. For example:

>>

>> 287  In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be

>> 288  used together to represent the actual bandwidth of ODUflex, where:

>>

>> and

>>

>> 323  In case of ODUflex(CBR), the information of Bit_Rate and

Tolerance in

>> 324  the ODUflex traffic parameters MUST be used to determine the total

>> 325 number of tributary slots N in the HO ODUk link to be reserved. Here:

>>

> [Fatai] Sorry I should not say “Accepted and refined the text.”

> last time. They are not repeated. here, the text just describes the

> meaning of the corresponding fields (as we always do), so the above

> text should be there irrespectively. Section 5.1 & section 5.2

> describe “how” with more detail information including formulation,

> Table information and example.

>

If the text in the early part of 5 is revised as I suggest above (and

the other lines are merged as suggested above) then this comment will be

resolved.



[Fatai] OK.



>>

>>>

>>> - lines 445-468: Why not just carry "n" directly?

>>>

>> [Fatai] to make it consistent with ODUflex(CBR).

>>

>> Given that the recent decision to have an OTN-TDM specific set of

>> traffic parameters, doesn't it now make sense to just carry N directly?

>>

> [Fatai] No. “N” cannot be used for ODUflex(CBR) case.



Do you really mean "cannot"?  I may be missing something, but it would

seem less ambiguous/prone to interop issues if N was directly carried.



[Fatai] My misunderstanding here. I thought you proposed to replace “bit rate” with “N”.



> It is better

> to have consistent format and the same meaning of one field for both

> ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to

> describe the complex stuff.

>



I actually wasn't suggesting that N be carried in the bit rate field.

The bit rate field can either be set as described or to zero (i.e.,

ignored).  At the time, I was thinking about carrying N in the reserved

field. But perhaps the right place is MT, if my understanding is right

(would always be 1 otherwise). I'm open to either...



[Fatai] Why not just use “bit rate” field to carry “N” because “N” implies bit rate? I am OK if you like to use a new filed (like “TS Number”) to occupy the reserved field even though that I prefer the original approach (ie., use “bit rate” field to carry “N”).

BTW, I don’t think MT is the right place (it will cause ambiguity if MT is used to indicate “TS Number”).





>>

>> [...]

>>

>>>

>>> - Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding",

>>

>> Again, how about "Pad bits" or "Padding"?

>>

> [Fatai] OK. Should use “Pad bits” instead of “Padding bits”



“Pad bits” it is...



>>

>>> also bits aren't represented in label format (line 494)., also "behind"

>>> --> "after"

>>>

>> [Fatai] Accepted and updated.

>>>

>>

>> [...]

>>

>>>

>>> - Lines 658-660.  The normative language in 4328 isn't actually

>>> presented in the section titled "label distribution procedures" (or

>>> "rules" as section 4.2 is actually titled), so this paragraph doesn't

>>> make sense.  I suggest either (a) defining the full set of required

>>> procedures in this document, or (b) referring to the "required

>>> processing defined in [RFC4328]" and other rfcs as appropriate.

>>>

>> [Fatai] Accepted and updated accordingly.

>>>

>>> - Lines 662-667: what about generating upstream, suggested, label set,

>>> etc.  Perhaps you should rephrase much into more general rules.

>>>

>> [Fatai] Accepted and updated accordingly.

>>>

>>

>> I think section 6.2 still needs a bit of work.

>>

>> So are there procedures that an ingress must follow?

>> For example:

>> - Setting of fields in the label request object, such as the OTN-TDM

>> Switching Type defined in [OTN-OSPF].

>>

>> What about the egress, are there any special procedures?

>>

>> The final three paragraphs of the section introduce upstream behaviors

>> *after* you've described the downstream behavior without specifics of

>> the new upstream behavior. As a general rule and in this case in

>> particular, I really think it would be better to cover procedures in the

>> following order

>> - Ingress

>> - Generic upstream

>> - Generic downstream

>> - Egress

>>

>> Also, generic statements should not use conformance language,

>> particularly when more detailed rules/procedures, which include such

>> language, follow.

>>

>> If you'd like we can discuss/review details on the list once you have a

>> proposed revision. (I see a bunch of more minor comments on this

>> section, but don't think it makes sense to focus on these until the more

>> major comments are addressed.)

>>

> [Fatai] Will refine the text based on your suggestion. Do I need to

> copy so much text here for review?



It's up to you, but personally, I think it's better to discuss the text

on the list first rather than publishing and then discuss/wordsmith.

But this is just a personal preference.  Either way works. (draft

revision numbers are cheap after all.)



[Fatai] OK, I will issue a new version to capture all the updates and make it easy for people to converge.



>>

>>

>> [...]

>>>

>>> - Lines 682-685: Who is this learning/identification accomplished?

>>>

>> [Fatai] Accepted and updated.

>>>

>>> - Lines 703-704: If this is the normative section defining requirement

>>> processing, the procedures need to be spelled out for all required

cases.

>>>

>> [Fatai] Accepted and updated accordingly.

>>>

>>> - Lines 706-707: I think this needs to be rephrased to be clear what

>>> behavior is required for a node to be conformant with this sentence.

>>>

>> [Fatai] Accepted and refined accordingly.

>>>

>>> - Lines 711-714: why "SHOULD" vs "MUST"?

>>>

>> [Fatai] Accepted and updated.

>>>

>>

>> I'll defer responses to the discussion on prior comment.

>>

>>> - Line 712: By "integrity of the label" do you mean "if the label is

>>> acceptable"?

>>>

>> [Fatai] Yes, and updated.

>>>

>>>

>>> - Line 725: By "reserved resource" do you mean "indicated resource"?

>>>

>> [Fatai] Yes, and updated.

>>>

>>> - Line 726: Does "do not match" mean "inconsistent"?

>>>

>> [Fatai] Yes, and updated.

>>

>> WRT lines 624-627, I think you still need additional specificity

>> differentiate upstream/downstream required behavior. Perhaps something

>> along the lines of:

>>

>>     When an upstream node receives a Resv message containing an



s/an/a



>>     LABEL object with an OTN-TDM label, the node MUST verify that

>>     the label is acceptable. If the label is not acceptable, the

>>     node MUST generate a ResvErr message with a "Routing

>>     problem/Unacceptable label value" indication.  Per [RFC3473],

>>     the generated ResvErr message MAY include an

>>     ACCEPTABLE_LABEL_SET object.  With the exception of label

>>     semantics, Downstream node processing a received ResvErr

>>     messages and of ACCEPTABLE_LABEL_SET objects is not modified

>>     by this document.

>>

>>     Similarly, when a downstream node receives a Path message

>>     containing an UPSTREAM_LABEL object with an OTN-TDM label,

>>     the node MUST verify that the label is acceptable. If the

>>     label is not acceptable, the node MUST generate a PathErr

>>     message with a "Routing problem/Unacceptable label value"

>>     indication.  Per [RFC3473], the generated ResvErr message MAY

>>     include an ACCEPTABLE_LABEL_SET object.  With the exception

>>     of label semantics, Downstream node processing received

>>     PathErr messages and of ACCEPTABLE_LABEL_SET objects is not

>>     modified by this document.

>>

>>     A received label SHALL be considered unacceptable when one of

>>     the following cases occurs:

>>

>>     - The received label doesn't conform with local policy.

>>

> [Fatai] OK. Accept your proposed text.

>>     ...

>>

>>>

>>> - Line 730, Drop "As".

>>>

>> [Fatai] Accepted and updated.

>>>

>>> - Section 6.4: Missing conformance language.

>>>

>> [Fatai] Went through and updated.

>>

>> New line 660:   The procedures are similar to section 6 of [RFC6344].

>>

>> Hereto,  If this is the normative section defining required processing,

>> the procedures need to be spelled out for all required cases or refer to

>> specific (and unmodified) procedures to follow in a reference document.

>> So either define the processing or say procures defined in <appropriate

>> reference> are followed.

>>

> [Fatai] OK, I think it is better to say “The procedures MUST follow

> Section 5 of [RFC6344].”



Are there any procedures defined in section6.3 that differ/add to 6344?

If I'm not mistaken, the only thing is that ODUflex signal types cannot

use "multiplication". (Please confirm.)



Assuming I'm correct, how about replacing the contents of the section

with something along the lines of:



   Support for Virtual Concatenation, as defined by [RFC6344], is not

   modified by this document. With the exception of ODUflex signal

   types, signal multiplication as defined in [RFC6344] and [RFC4328].



[Fatai] Right. Will accept your proposed text.



>>

>>>

>>> - Lines 758-759: This reads like an informative statement, but includes

>>> conformance language.  How does a node conform?  I suggest rephrasing to

>>> be clear.

>>>

>> [Fatai] Accepted and updated.

>>>

>>

>> I think this section should be revised to ensure that the

>> responsibilities of each type of processing node (ingress, upstream,

>> downstream, egress) is clear.

>>

>> I guess, we'll have a thread on this section too...

>>

> [Fatai] Will refine the text based on your suggestion.



great.



>>

>> [...]

>>

>>>

>>> - Section 9, should also reference 4328 and cover delta in information

>>> and added risks.

>>>

>> [Fatai] Accepted and updated.

>>

>> We'll see if this is enough to keep the security reviewers happy...

>>

>>>

>>> - Section 10: This section needs some work.  (I'm assuming your familiar

>>> with rfc5226).

>>>

>> [Fatai] Accepted and updated.

>>>

>>

>> Better, but you should at least refer to the existing registries,

which already includes G-PIDs (see

>>

http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)

>>

>>> - Is it time to create a "Signal Type" registry?

>>>

>> [Fatai] We are not sure, because no "Signal Types" have been

registered in the existing RFCs (like RFC3473, RFC4328..).

>>>

>>

>> I think including a request to establish such a registry in this

>> document would be useful.  Is anyone up to proposing the requisite text?

>>

> [Fatai] OK to register “Signal Type”.



Is this a question or statement?



[Fatai] A statement. I am planning to register “Signal Type”. If anyone has any opinion on this point, please share your comments before I update.



Thanks,

Lou



>>

>>    Value    Signal Type                           Reference

>>    -----    -----------                                ---------

>>    0        Not significant                      [this document]

>>    1        ODU1 (i.e., 2.5 Gbps)                 [this document]

>>    2        ODU2 (i.e., 10 Gbps)                  [this document]

>>    3        ODU3 (i.e., 40 Gbps)                  [this document]

>>    4        ODU4 (i.e., 100 Gbps)                 [this document]

>>    5        Reserved (for future use)              [this document]

>>    6        Optical Channel (Och) at 2.5 Gbps       [this document]

>>    7        OCh at 10 Gbps                      [this document]

>>    8        OCh at 40 Gbps                      [this document]

>>    9        OCh at 100 Gbps                     [this document]

>>    10       ODU0 (i.e., 1.25 Gbps)                [this document]

>>    11       ODU2e (i.e., 10Gbps for FC1200        [this document]

>>             and GE LAN)

>>    12~19    Reserved (for future use)             [this document]

>>    20       ODUflex(CBR) (i.e., 1.25*N Gbps)      [this document]

>>    21       ODUflex(Generic Framing            [this document]

>>             Procedure-Framed (GFP-F)),

>>             resizable (i.e., 1.25*N Gbps)

>>    22       ODUflex(GFP-F), non resizable        [this document]

>>             (i.e., 1.25*N Gbps)

>>       23~255   Reserved (for future use)             [this document]

>>

>>

>> Thanks,

>> Lou

>>

>>

>>> That's it on this document.

>>>

>>> Lou

>>> -

>>