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

From: Fatai Zhang <[email-masked]>
Date: Fri, 7 Dec 2012 09:53:04 +0000

Hi Lou,

Please see how the LC comments addressed below.

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2012年10月22日 10:01
收件人: CCAMP; [email-masked]
主题: [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. 

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

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. 

- Please use a consistent decimal representation (sometimes commas are
used other times periods)

[Fatai] OK. Commas are used.

- 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. 
-
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 .  I'm using line
numbers from this url in my subsequent comments.

- Line 2: The document is currently written as if it "Updates" 4328 this
should be identified in the header.

[Fatai] Accepted and updated.

- Line 43: drop "Recent progress in", replace "standardization" with
[G.709-V3]

[Fatai] Accepted and updated.

- Line 45-53.  Drop all starting from "Several..."

[Fatai] Accepted and updated.

- Lines 95-128: Not sure this adds anything.  Should just reference FWK,
INFO, OSPF and drop the rest.

[Fatai] Accepted and updated.

- Section 3.  Perhaps combine with section 1.

[Fatai] Accepted and refined.

- Section 4, lines 208-238.  For future "proofing"/compatibility, I
suggest removing the bandwidths (2.5, 10, 40 Gbps). or changing all the
"i.e."s into "e.g."s.

[Fatai] Accepted and updated.

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

- Lines 285-287: replace all lines with "The valid Signal Type values
defined in [RFC4328] are updated to be:"

[Fatai] Accepted and updated.

- Lines 309-318.  I found this really hard to understand.  Why not just
call it Tolerance?

[Fatai] Accepted to remove NMC because new C-type is introduced.

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

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

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

- Lines 472-482: Suggest replacing all lines with something like:
This section defines the format of the OTN-TDM Generalized Label.

[Fatai] Accepted and updated.

- Line 484: replace "New definition of ODU" with "OTN-TDM"  Switching Type.

[Fatai] Accepted and updated.

- Lines 486-487: Replace lines with "The following is the Generalized
Label format for that MUST be used with the OTN-TDM Switching Type"

[Fatai] Accepted and updated.

- Line 499: "can be figured out locally according to the identifier of"
--> "is identified by"

[Fatai] Accepted and updated.

- Line 562: "number of bit" --> "number of bits". The valid values for
this field are 0, 4 and 8, right?  If so, this should be spelled out.

[Fatai] Accepted and updated.

- Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding",
also bits aren't represented in label format (line 494)., also "behind"
--> "after"

[Fatai] Accepted and updated.

- Lines 580-588: I suspect these lines should be in a procedures
section, as there should be specific processing rules governing the
described usage.

[Fatai] Accepted and modified accordingly.

Section 6.2: I like the examples, but IMO they belong at the end of
section 6, not in the middle of the normative language.

[Fatai] Accepted and updated.

- Line 656: Generally the processing rules are presented in sections
titled "Procedures".  It is true that this wasn't the case in rfc4328
(section 4.2). I'd suggest following one of the two existing precedents
rather coming up with a third variant.

[Fatai] Accepted and modified the text for "Procedures".

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

- Line 682: by "learn" do you mean "identify"?

[Fatai] Accepted and updated.

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

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

- Line 730, Drop "As".

[Fatai] Accepted and updated.

- Section 6.4: Missing conformance language.

[Fatai] Went through and updated.

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

- Line 761: Why not just make this a MUST?

[Fatai] Accepted and updated.

- Line 763: "SHOULD" --> "MUST"

[Fatai] Accepted and updated.

- lines 768-779: Should either contain conformance language or pointers
to existing language.

[Fatai] Accepted and updated the language.

- Line 783: Why not MUST?

[Fatai] Accepted and updated.

- Section 9, should also reference 4328 and cover delta in information
and added risks.

[Fatai] Accepted and updated.

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

[Fatai] Accepted and updated.

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

That's it on this document.

Lou
-

On 10/8/2012 4:47 PM, Lou Berger wrote:
> This mail begins a two week working group last call on:
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-09
> (Informational)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-04
> (Informational)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03
> (Standards Track)
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-04
> (Standards Track)
> 
> This working group last call ends on October 22.  Comments should be
> sent to the CCAMP mailing list.  Please remember to include the
> technical basis for any comments.
> 
> Please note that we're still missing a few IPR statements, and look
> for these to come in during the LC period.  Any forthcoming publication
> request will be delayed by late IPR statements/disclosures.
> 
> Thank you,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Dec 2012 09:12:07 -0500

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.

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

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

Okay.

> [Fatai] Went through and updated. 

thanks.

> [Fatai] OK. Commas are used.

great, although a quick skim finds:
s/1,301.683.217/1,301,683.217

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

great

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

> I'm using line
[...]

> [Fatai] Accepted and refined.

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

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

Formal field definitions are missing and need to be added.

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

> [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?

[...]

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

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

> [Fatai] Accepted and updated.

[...]

> [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] Accepted and updated.

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

> [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
    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] 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] 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] Accepted and updated.

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

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

> [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?

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 25 Dec 2012 08:33:48 +0000

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:[email-masked]]
Sent: Thursday, December 20, 2012 10:12 PM
To: Fatai Zhang
Cc: CCAMP; [email-masked]
Subject: Re: 答复: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Fatai/Authors,

Okay.

thanks.

great

     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

     (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.)

[Fatai] Will update “Copyright Notice” section.

[...]

just a suggestion.

[Fatai] OK.

[...]

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

Also the draft says:

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

[...]

and

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

[Fatai] No. “N” cannot be used for ODUflex(CBR) case. 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.

[...]

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

[...]

For example:

following order

- Ingress

- Generic upstream

- Generic downstream

- Egress

language, follow.

[Fatai] Will refine the text based on your suggestion. Do I need to copy so much text here for review?

[...]

along the lines of:

    by this document.

[Fatai] OK. Accept your proposed text.

    ...

reference> are followed.

[Fatai] OK, I think it is better to say “The procedures MUST follow Section 5 of [RFC6344].”

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

[...]

Better, but you should at least refer to the existing registries, which already includes G-PIDs (see

[Fatai] OK to register “Signal Type”.

   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