[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD review of GMPLS SONET documents
1) An additional editorial mistake to be corrected in
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt is the following:
"AU/STS SPE" should be "AU/STS"; e.g. in section 2 "AU-3s/STS-1 SPEs"
should be "AU-3s/STS-1s".
The indication "SPE" is associated with the VC-n/STS-m SPE; e.g.
VC-4/STS-3c SPE.
2) section 5 includes the following text:
"When the signaling is used between intermediate nodes it is up to
a data plane profile or specification to indicate how transparency
is effectively achieved in the data plane. When the signaling is
used at the interfaces with the initiating and terminating LSRs it
is up to the data plane specification to guarantee compliant
behavior to G.707/T1.105 under fault free and fault conditions."
Given that there is no standardised "data plane specification", to
which specification is this a reference?
Regards,
Maarten
"Wijnen, Bert (Bert)" wrote:
>
> As AD I reviewed these documents:
>
> draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
> for Proposed Standard
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
> for Informational.
>
> Below are my findings that I would like to see addressed
> before I request an IETF Last Call.
>
> For both documents:
>
> 1. Need to reduce the number of authors/people on front page.
> The docs will not be considered again unless you comply
> with the guidelines in section "Author overload" in
> http://www.rfc-editor.org/policy.html
>
> 2. I expect that RFC-Editor will reject the Acronyms in the
> title and abstract. See also the "Choosing titles" and
> "abstract" sections in
> http://www.rfc-editor.org/policy.html
> I believe that the RFC-Editor wants these acronyms expanded:
> SONET, SDH, SONET/SDH
>
> for draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
>
> 1. I think that normative references are needed to documents
> ANSI T1.105 and ITU-T G.707 as I think one cannot understand
> much of this doc if you ignore those ANSI/ITU-T documents.
>
> 2. It seems to me that this document should not reference another
> doc that specifies non-standard extensions. At least, if it
> does so, then maybe once in the iuntroduction is enough.
>
> 3. Last para on page 4.
> I do not understand this. Can you clarify?
>
> 4. On page 6 in the middle I read:
>
> This field is set to one (default value) to indicate that
> exactly one instance of a signal is being requested. Zero is an
> invalid value.
>
> So how does the requestor know requested value has been accepted?
> And what needs the receiver do if the "invalid value zero" is
> requested?
>
> 5. Page 7 in the middle:
>
> Where bit 1 is the low order bit. Others flags are reserved,
> they should be set to zero when sent, and should be ignored
> when received. A flag is set to one to indicate that the
> corresponding transparency is requested.
>
> So how does requestor find out which values have been accepted?
> By the way s/Others flags/Other flags/
>
> 6. I would think that the 1st sentence on page 8 better be
> removed.
>
> 7. Middle of page 10, may want to add refrence to G.707
>
> 8. Page 10 talks about "higher ordered LSP" and "lower ordered LSP"
> Where are those terms defined? May want to explain or reference.
>
> 9. Page 13 talks about "highest part" and "lower part" of a label.
> Might be good to define what you mean by that.
> How about "lowest label"?
>
> 10. You have quite a set of values that you assign in this document.
> For various fields in the SONET/SDH paramters data structure
> and also for various parts of the labels for SONET/SDH.
> The extensions document adds additional (optional) values
> to those fields. You also suggest that other documents could
> add values fro G.832 or G.708.
> How do we keep control over such value assignments/usage?
> Is that something that IANA should control?
>
> 11. In the IANA considerations section you may want to be
> more explicit as to the name-space in which IANA
> needs to make new assignments.
>
> less serious, but once you're at it...
>
> 11. sect 2.1 1st sentence
> s/is organized/are organized/
>
> 12. I see various use of Upper/Lower case for
> Elementary Signal/elementary signal.
> I think it may beuseful to exlain what Elementary
> Signal and Final Signal are.
>
> 13. Last para page 4
> s/node chosen/node has chosen/
>
> 14. I see the use of SONET/SDH and SDH/SONET used arbitrarily
> Would it not be better to choose one form? And let that
> be the same as in the other GMPLS documents?
>
> for draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
>
> 1. Last para on page 2 seems "marketing" that we do not need.
>
> 2. Top of page 3.
> This document doesn't specify how to implement these features in
> the transmission plane but how to control their usage with a GMPLS
> control plane.
> My question is: Is there any document anywhere that explains
> how to implement in the transmission plane. If yes, then a
> reference to such document would be usefull.
> If not, then how can anyone create interoperable implementations.
> And if they cannot do that, then why is this document useful?
>
> 3. Security considerations.
> I think I would add a ptr to the doc(s) where the security
> mechanisms are described, just as you did for base sonet/sdh doc.
>
> less serious:
>
> 4. I see the use of SONET/SDH and SDH/SONET used arbitrarily
> Would it not be better to choose one form? And let that
> be the same as in the other GMPLS documents?
>
> Thanks,
> Bert
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies;NA&CPSE
adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
fn:Maarten Vissers
end:vcard