[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Post-AD markups review of draft-ietf-ccamp-sdhsonet-control-03.txt
Hi,
Thanks for making the changes to this draft as requested by the AD.
I think this is a really useful draft that goes a long way to explain how the simple
concepts of GMPLS in WDM are extended to GMPLS in TDM. Thanks for persevering with it.
I have re-reviewed the draft to:
- check that the changes made will address the AD's points
- ensure that the draft is ready to progress to the IESG.
Herewith a few comments. Can you please give me a schedule for making these minor changes
(recalling that submission of drafts is embargoed until 9th August). I would really like
to move this draft on now, so if you are short of bandwidth to make the changes, please
say and I will get them done some other way.
Cheers,
Adrian
= = = = = = = = = = = =
AD comments
==========
Technical
Figure 1 - OK
Section 3.4.3 - (Now 2.4.3) Slight improvement by use of parenthesis
Section 3.5 New simplified encapsulation - (Now 2.5) Text struck. OK
Section 3.5 Encapsulation of IP over WDM - (Now 2.5) OK
Section 6 - (Now 5) Some new text added to help the issue, but no
specific resolution of the question. Probably OK.
Section 6.1 - (Now 5.1) The text has been expanded to explain
why the text is present for data transport, but fails to
address the two issues raised.
a. In what way is this relevant to the control plane
framework?
b. How is the statement true when vcat is provided by
services terminated on separate line cards?
Section 6.3 - (Now 5.3) This section is still a problem.
The issue has been resolved through a reference to two
external sources neither of which is freely available.
Since the authors are stating an opinion that the current
GMPLS routing architecture/solution is deficient, it is
important that this be clearly explained.
Section 7.3 - (Now 6.3) Good new text added.
Unfortunately a couple of editorial SNAFUs with
cut and paste, and the references are still mixed up.
Editorial:
Section 3 - (Now 2) Improved, but still largely focused on MPLS not
GMPLS (See my nits, below)
Section 3.1 - (Now 2.1) OK
Section 3.2 G.707 - (Now 2.2) OK
Section 3.2 SDH->STS - (Now 2.2) OK
Section 4.1 - (Now 3.1) OK
Section 6 - (Now 5) OK
Section 6.1 STS-3c - (Now 5.1) OK
Section 6.1 "recently approved) - (Now 5.1) OK
Section 6.1 STS-1-2v - (Now 5.1) OK
Section 6.1 modify overhead bits - (Now 5.1) OK
Section 6.1 multiplexing - (Now 5.1) OK
Section 6.2 - (Now 5.2) OK
Section 7 MPLS-HIER - (Now 6) OK
Section 7 mixed SDH/SONET - (Now 6) Looks good to me
Further Changes Needed
==============
In summary of the above, further work is needed to address the following technical issues
- Section 6.1 second issue
- Section 6.3
- Section 7.3
and the editorial issue in
- Section 3
Nits
===
Further nits from my review.
Abstract.
The suite of protocols that defines Multi-Protocol Label Switching
(MPLS) is in the process of enhancement to generalize its
applicability to the control of non-packet based switching, that is,
optical switching.
etc.
Can you please re-cast this as a done deal and talk about GMPLS. I know this simply shows
how old the draft is, but we need to look at the current position and that the RFC will
(hopefully) be read for a few years to come.
Index
Please indent.
Section 1
I am not sure what the purpose of this RFC2119 text is. I can't find any examples of
uppercase terms used in the draft and this notation is normally used in requirements
drafts or protocol specs.
Section 2.
As per abstract, the use of "is currently working on" does not future-proof the text as
part of an RFC.
Section 2.1
There is no need to talk about the advantages of the MPLS architecture and refer to [3].
We now have GMPLS and the GMPLS architecture document. In this context, this section is
not very relevant to the discussion.
Figure 1
It would be helpful to preserve this on one page.
Add some blank lines (and maybe a note to the RFC Ed.)
Table 1
Formatting
Section 5.3
This is a WG document so MUST NOT contain phrases such as "the authors are of the
opinion". It is either WG opinion (about which I'm not sure) or it should not be in the
draft.
Section 6
It is now appropriate to remove references to CR-LDP.
Section 6.1
Reference to section 4 should be to section 3, I think.
Please check all cross-references as you have renumbered the sections.
Section 8
The wording here is a bit strange. Does it raise new security issues somewhere else?
I think some more standardised text along the lines of "As an informational framework
document, this document introduces no new security issues."
However, as a framework document, I would expect to see an examination of the security
issues that form part of GMPLS control of SDH/SONET. Are those issues identical to the
security issues for GMPLS, are there additional issues specific to SDH/SONET, and are
there GMPLS security issues that do not apply in this case?
It is incumbent on us to expose security issues in this sort of document.
Reference [9]
Is this reference really normative? I believe it may give the RFC Ed a problem if it is,
but the problem is not insurmountable.
Reference to T1.105
Is this document publicly available? If it is available for cost-free down load, can you
please give a *stable* URL (probably just the ANSI home page). If it is not publicly
available, please move it to the informational references section.
References to G.707 and G.841.
Please move these to the informational references section and prefix with some text such
as...
For information on the availability of the following documents,
please see http://www.itu.int.
Please catch the reference to G.7715.1 in this, too.
Section 13
Formatting
Unprintable characters.
Can you check for these and remove them. E.g. section 2.4 para 2.
Also in the references section.
References to "this draft"
Please replace with (e.g.) "this document". E.g. sections 8 and 9.