Subject: [CCAMP] WG Last Call: g709-framework, g709-info-model, ospf-g709v3, signaling-g709v3

From: Lou Berger <[email-masked]>
Date: Mon, 08 Oct 2012 16:47:41 -0400

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)

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Oct 2012 19:05:37 -0400

Authors,
	I have the following LC comments:

General comment:
- I have a comment related to the info document, that I'll cover in a
separate mail on the info-model document .

- I found appendix A to not be very informative and thing there are
better examples in the other documents, suggest either moving one ore
more to this document or drop the appendix.

The remaining comments are editorial in nature

- Please verify that abbreviations are defined before being used .
There are a number of these.

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

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

-
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-g709-framework-09.txt
shows there are unresolved nits that need to resolved .  I'm using line
numbers from this url in my subsequent comments.

- Line 46: How about replace "as consented in October 2009" with "as
published in 2009."

- Line 255: Drop "approved in 2009" the reference is sufficient

- Line 260: suggest the following change:
OLD
                2.5Gb/s     1.25Gb/s           Nominal Bit rate
NEW
                Time Slot Granularity
                2.5Gb/s     1.25Gb/s           Nominal Bit rate

- Lines 272-274: Please add the appropriate reference to G.709 section
or table that points to where one finds the information on determining
actual bit rate.

- Line 307: suggest changing "into the OTUk" --> "into a specific OTUk"

- Line 340/1: need a reference to where this is defined.

- Line 346-347: Need a reference to where this behavior is defined.

- Lines 387/388.  Isn't this sentence OBE and should be dropped?

- Page 11, RWA is used in a few places on this page as is OCh layer,
suggest replacing all instances of RWA with OCH or "OCh layer".

- Line 500: what do you mean by "including OCh layer visibility."? this
isn't really reflected in the solutions documents (other than as MLN).

- Line 589: replace "New label" with "A new label format"

- Line 636: replace "some" with "sufficient"

- Lines 639-641: drop lines (seems redundant with following paragraph)

- Line 686: your usage of "just" is a bit odd, how about replace "be
just switched" with "restricted to switching"

- Line 688: similarly how about replace "just terminated" to "restricted
to termination"

- lines 714-719, probably should have a reference to [rfc4201]

- Line 879: Replace "contrary" with "opposite" or "reverse"

- Line 888. I suggest adding "Although, this is not greater than the
risks presented by the existing OTN control plane as defined by
[RFC4203] and [RFC4328]."

- Lines 888-890, I suggest dropping the sentence starting with "The data
plane technology..." for multiple reasons, not least of which is that
the ITU-T owns the data plane so the comment is completely out of scope.

- Lines 1081/2: The whole document is non-normative, so just drop this
sentence.

That's it on this document.

Lou

On 10/8/2012 4:47 PM, Lou Berger wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Oct 2012 19:05:42 -0400

Authors,

General comments:

- There's a lot of text/concepts that is common to both this document
and the framework document.  The document certainly adds additional
useful detail, but I'm not sure it's really provides an information
model of any kind.  Optimally, I think this document should be merged
with the framework document.  I think this would yield a more
comprehensive and understandable result.  I really don't see this as a
lot of work/time, although it clearly would be a major change.

If this is considered to be to onerous a proposal, then this document
should at least be updated to (a) reduce duplication text with the
framework document and (b) remove any references to "model" and just
talk about providing "Additional Information"

- The document should be reviewed by the authors to ensure it is
consistent with the latest solutions documents and WG discussions.  For
example, there are multiple references to the contentious and much
discussed "penultimate hop" case without any references to the agreed
upon approach.

Editorial comments:

-
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-otn-g709-info-model-04.txt
shows there are unresolved nits that need to resolved .  I'm using line
numbers from this url in my subsequent comments.

Line 18: Suggest dropping "The recent revision of"

Line 20/21: Suggest dropping the marketing phrase "enabling optimized
support for an increasingly abundant service mix."

Lines 93-127 (through "of"): I don't see how this text provides any
value.  I suggest dropping it, or at most just reference the FWK document.

Lines 319-341: Instances of "G.709" should be "[G.709-V3]"

Line 538: Add "(Source: Table 7-10 [G.709-V3])"

Lines 579/80: Does "foundation G.709" mean "[G.709-V1]" If not what does
it mean?

Line 591: Replace/add "[RFC4203]" after "OSPF-TE"

Lines 617-620: While one could certainly implement 4202/3 this way, it
certainly is not required.  I think these lines should be dropped.

Lines 626-630:  These sentences are simply wrong.  What would be correct
is to say something like:

"Per [RFC2328], OSPF messages are directly encapsulated in IP datagrams
and depend on IP fragmentation when transmitting packets larger than the
network MTU.  [RFC2328] recommends that "IP fragmentation should be
avoided whenever possible." This recommendation further constraints
solutions as OSPF does not support any generic mechanism to fragment
OSPF LSAs."

Line 632, probably should add a reference to [RFC4201].

Lines 733, 735, 764: figure numbers are wrong "6"->"9", "7"->"10"

Lines 734/5: "are supposed to" --> "only"

Line 735: "The figure 6 addresses" --> "Figure 9 represents"

Line 738: Assuming I understand your intent, replace "Being D a single
stage capable node" --> "As node D is a single stage capable node"

Section 5, needs to be updated to reference existing relevant signaling
and routing GMPLS RFCs and identify any additional information that is
being conveyed and additional risks, if any.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Oct 2012 19:05:45 -0400

Authors,

General comments:

- Some comments made just about a year ago still remain unaddressed:

On 10/28/2011 6:18 AM, Daniele Ceccarelli wrote:
> Hi Lou,
>
> Thanks for the careful review, please find comment/replies in line [DSP]
>
> Daniele, Sergio, Pietro
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lou Berger
> Sent: mercoledì 26 ottobre 2011 0.37
> To: [email-masked]
> Cc: CCAMP
> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00
...
> 2) SCSI TLV formatting
>
> The field descriptions are missing format related conformance
> (RFC2119) language.
>
> [DSP] - Ok, will be fixed.
>
> 3) SCSI TLV procedures
>
> You have defined the formats of the TLVs in Section 4.1, but not
> explicitly how they are to be used. Some RFC2119 language really is 
> needed to cover how the SCSI is to be encoded and parsed. At a
> minimum, any TLV inclusion, ordering requirements, and exception
> handling should be covered. (For example, your examples always show a
> particular ordering relative to Stage#, is this required,
> recommended, or just a possibility. You have some informative
> language, which is great, but you also need some RFC2119 language.)
> [DSP] - Ok
...
> 6) Finally, some nits:
> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list of them/list
s/Priority :8 bits/Priority (8 bits):
> s/infer/imply
> [DSP] - Ok

- You have some very nice examples, but are inconsistent in filling in
field values.  I think all values that can possibly be filled in in the
examples should be.

Detailed editorial and technical comments:

-
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt
shows there are unresolved nits that need to resolved .  I'm using line
numbers from this url in my subsequent comments.

- Line 24: drop "The recent revision of "

- Line 138: "ODUk an higher order" --> "ODUk to indicate a higher order"

- Line 145: "iterated" --> "repeated"

- Line 181/2: Drop "Some of the prominent representations are captured
below."

- Line 202: perhaps "termed" --> "referred to"?

- Line 226: I'd suggest 110, but don't feel too strongly about it.

- Line 228: Start with "When supporting the extensions defined in this
document, the"

- Lines 236-261: Replace all lines with "MUST be interpreted as defined
in [RFC4203]".  No need to repeat what's already specified.

- Lines 265-272: Additional information is fine, but don't repeat 4203
unless directly quoting.

- Line 300: Need to specify what "differing characteristics" means using
RFC2119 language.

- Section 4.1.

I think the combine presentation of the two types is confusing.  I
suggest adding a section 4.1.1 right after line 311 covering "Switch
Capability Specific Information for fixed containers" followed by a
section 4.1.2 covering "Switch Capability Specific Information for
flexible containers".  Field definitions will need to be reorganized as
appropriate.

Also the common format and rules related to the OTN-TDM SCSI container
should be defined before going into the type specific definitions. (at
the 4.1) level.

- Lines 405-417: How about replace all with:
  "Signal Type: Indicates the ODU type being advertised. Values are
defined in [OTN-SIG]"

- Line 428: after "level" suggest adding something like "below the
indicated signal type"

- Line 442: "00" --> "0"

- Lines 447, 454, 463, 464: I find the "don't care" case a bit odd.  How
about make 0 "unused" or "ignored" and use it instead of 4?

- Lines 472/3: Replace "stage of the muxing hierarchy" --> "of the
indicated Number of stages"

- Line 476: "then no Stage fields MUST be included." --> "then the Stage
and Padding fields MUST be omitted."

- Lines 484/5: "Only Unreserved/MAX LSP BW fields for supported" -->
"Unreserved/MAX LSP BW fields for each identified"

- Line 486: After "to 7)" add ", and Unreserved/MAX LSP BW fields for
other priority values MUST be omitted."

- Line 497: Drop "Only", "for supported" --> "for each supported"

- As mentioned above need processing rules/procedures, for multiple
ISCDs, SCSI information, e.g., use and ordering of multiple containers.

- Line 503: "infer" -> "imply"

- Fill in all example field values

- Section 7 -- update to reference 4203 and 5920.  Discuss implications
/ added risk of additional information provided in this document.

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

- Switching types are assigned in
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml#gmpls-sig-parameters-3
 (Again I suggest 110, not 101, but this isn't a big deal)

- I think you are actually asking for IANA to establish a new registry.
 Perhaps something like "OTN-TDM Container Registry" under a new "GMPLS
Routing Parameters" with two new types.

Lou

---

From: Lou Berger <[email-masked]>
Date: Sun, 21 Oct 2012 22:00:32 -0400

Authors,

General comments:

- This document also needs some addition work on conformance language.
I'll try to point out cases in the detailed comments 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?

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

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

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

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

- Section 3.  Perhaps combine with section 1.

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

- Section 5: assuming this is now a new c-type need text for that, as
well as to formally defined the fields/field sizes.

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

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

- Lines 320-336,338-346 are essentially repeated in sections 5.1 and
5.2, why not move this text into their respective sections?

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

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

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

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

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

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

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

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

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.

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

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

- Lines 662-667: what about generating upstream, suggested, label set,
etc.  Perhaps you should rephrase much into more general rules.

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

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

- Lines 703-704: If this is the normative section defining requirement
processing, the procedures need to be spelled out for all required cases.

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

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

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

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

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

- Line 730, Drop "As".

- Section 6.4: Missing conformance language.

- Lines 758-759: This reads like an informative statement, but includes
conformance language.  How does a node conform?  I suggest rephrasing to
be clear.

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

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

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

- Line 783: Why not MUST?

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

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

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

Lou
-

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 22 Oct 2012 02:57:42 +0000

Hi Lou, 

Thanks very much for so careful review.

For Appendix A, I am fine to drop it. Any more comments from WG?

For the others, I will update them after a while to collect more comments from WG.

Thanks

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2012年10月20日 7:06
收件人: CCAMP; [email-masked]
主题: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-g709-framework-09

Authors,

General comment:

-

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Oct 2012 16:40:28 -0400

The last call on these documents have ended.

Authors,
	Please complete the discussion(s) needed to address all
issues raised during the LC (both on-list and privately) and update
the drafts accordingly.  Once each update is submitted, please
summarize all changes to the list (per document/submission).

Much thanks,
Lou (and Deborah)

PS We're still missing some IPR statements from contributors.  If you're
listed in one of the documents *even as a contributor* you'll need to
respond to my message on IPR, even if missed you in the request e-mail!