[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD review of GMPLS SONET documents
hi all,
here below the consolidated list of responses and summary
of the consistency/editorial changes to be provided in the
revisited version of these i-d's (many thanks to bert for
his careful review and suggestions)
see in-line...
"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
done (a dedicated contributor'section has been added for
this purpose, thus only editors are listed in the front
page)
> 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
done (acronyms have been expanded in the abstract and the
introduction of these documents)
> 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.
done (both references have been added in the normative
reference section)
> 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.
any reference to draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
(aka the non-standard i-d) has been removed from this document
further clarification (from bert):
-> I think that you should strive to get to text such that the
-> base document does not have to point to the extensions at all.
-> (After all... such extension could have been developed
-> years later...). There should be NO dependency in the base
-> SDH doc on the SDH-EXT doc.
->
-> In the SDH-EXT doc you can refer to the base SDH doc as much
-> as you want or even specify dependencies.
note: therefore further review of "non-standard extensions" will
be performed in order to achieve consistency
> 3. Last para on page 4.
> I do not understand this. Can you clarify?
this has been clarified as follows:
"When several flags have been set, the upstream node retrieves the
(single) type of contiguous concatenation the downstream node has
selected by looking at the position indicated by the first label and the
number of label(s) as returned by the downstream node (see also Section
3)."
> 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?
clarified (if i well understood the raised issue):
"This field is set to one (default value) to indicate that exactly one
instance of a signal is being requested. Intermediate and egress nodes
MUST verify that the node itself and the interfaces on which the LSP
will be established can support the requested multiplier value. If the
requested values can not be supported, the receiver node MUST generate a
PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively)."
note: requestor also performs a consistency check by mapping
the number and sequence of received labels with the initial
request
> And what needs the receiver do if the "invalid value zero" is
> requested?
clarified (if i well understood the raised issue):
"Zero is an invalid value. If received, the node MUST generate a
PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively)."
> 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/
clarified (if i well understood the raised issue):
"Intermediate and egress nodes MUST verify that the node itself and the
interfaces on which the LSP will be established can support the
requested transparency. If the requested flags can not be supported, the
receiver node MUST generate a PathErr/ NOTIFICATION message (see Section
2.2/2.3, respectively)."
note1: requestor also performs a consistency check by mapping
the number and sequence of received labels with the request
note2: multiple flags may be selected but these are fixed (the
receiver is not allowed to perform a sub-selection, or change
this selection in any case), the underlying idea that if there
is any flag turned on that the received cannot support at least
one of them, then an error is returned back to the requestor;
also here, for transparency, these flags are only significant
for the intermediate nodes
note3: add-on in sections 2.2/2.3 (related to points 4. and 5.)
concerning error processing:
in section 2.2:
"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, RCC, NCC, NVC and Multiplier (as defined in
Section 2.1). If the requested value(s) can not 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]).
Intermediate nodes MUST also verify that the node itself and the
interfaces on which the LSP will be established can support the
requested Transparency (as defined in Section 2.1). If the requested
value(s) can not be supported, the receiver node MUST generate a PathErr
message with a "Traffic Control Error/Service unsupported" indication
(see [RFC2205])."
in section 2.3:
"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, RCC, NCC, NVC and Multiplier (as defined in
Section 2.1). If the requested value(s) can not be supported, the
receiver node MUST generate a NOTIFICATION message with a "Resource
Unavailable" status code (see [RFC3212]).
In addition, if the MT field is received with a zero value, the node
MUST generate a NOTIFICATION message with a "Resource Unavailable"
status code (see [RFC3212]).
Intermediate nodes MUST also verify that the node itself and the
interfaces on which the LSP will be established can support the
requested Transparency (as defined in Section 2.1). If the requested
value(s) can not be supported, the receiver node MUST generate a
NOTIFICATION message with a "Resource Unavailable" status code (see
[RFC3212])."
> 6. I would think that the 1st sentence on page 8 better be
> removed.
done (also the same sentence was included later in third
paragraph of the corresponding section and has also been
removed)
> 7. Middle of page 10, may want to add refrence to G.707
done
> 8. Page 10 talks about "higher ordered LSP" and "lower ordered LSP"
> Where are those terms defined? May want to explain or reference.
the following text has been added in order to clarify these
terms (and further refers to G.803):
"a higher order LSP is established through a SONET/SDH higher order path
layer network and a lower order LSP, through a SONET/SDH lower order
path layer network (see also ITU-T G.803, Section 3 for the
corresponding definitions). In this context,..."
> 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"?
this referes to the lowest lavel *value*, clarification has
been provided within the text
> 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?
further clarification (from bert):
-> I mean that right now, you have defined values in this document
-> For example the Transparencey bits (T field in figure in sect 2.1)
-> - in this doc (page 7) you assign values/meaning for flag1 and flag2
-> - in the extensions doc (sec 5) you assign values/meaning
-> for flags 3,4,5,6,7,8,9,10,11,12,13,14
-> Anotehr example is Signal Type
-> - in this doc you assigne values 1 through 12,
-> - in extensions you assign 13-19
-> - in anex 1 of this doc you assign 20
->
-> So how dow we in the future keep track if people want to assign new
-> more values. It seems they already have to look in these 2 documents,
-> but how does one know if those are the only docs that made
assignments?
->
-> Would it be usefull to ask IANA to register those values, so that we
-> have one place where people can look for free values?
-> Without it I see a risk that somewhere a few years from now, some
-> new technical contributors and some new AD forget something and
-> an overlapping/conflicting value gets assigned?
->
-> Or am I worrying too much?
same approach as for other gmpls signalling documents has been
used, if proposed values are "registered" and "controlled" by
IANA for fields like the LSP EncType, Switching Type, etc. then
i will do the same for the ones defined in this i-d
> 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.
the following text has been added in order to be more explicit:
"Three values have to be defined by IANA for this document:
two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters
and one LDP TLV Type in registry:
http://www.iana.org/assignments/ldp-namespaces";
> less serious, but once you're at it...
>
> 11. sect 2.1 1st sentence
> s/is organized/are organized/
done
> 12. I see various use of Upper/Lower case for
> Elementary Signal/elementary signal.
done (upper case only)
> I think it may beuseful to exlain what Elementary
> Signal and Final Signal are.
done (definitions are embedded within the text)
> 13. Last para page 4
> s/node chosen/node has chosen/
done
> 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?
done (in addition i have aligned all the related acronyms
to SONET/SDH)
question: with all these changes how to proceed further with
the document ?
> I think they are most of a consistency and editorial and admin type.
> I don't think we are doing any semantic/content changes are we?
i agree most of the changes are for consistency/editorial review
> Well, except maybe the piece about registering values?
>
> WG chairs could do a "shortened WG Last Call after you post the
> new I-Ds to the repository and after you post a summary of
> the changes. Don't think it needs to be a full 2 week WG Last Call
> unless anyone CLAIMS to need the time to do serious review.
> (or so I think).
note: revisited draft-ietf-ccamp-gmpls-sonet-sdh-06.txt
version to be submitted during this week
**********************************************************
> for draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
>
> 1. Last para on page 2 seems "marketing" that we do not need.
done (i have removed this paragraph, you are right this
is a "marketing" statement)
> 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.
these references do not exist (either itu-t or ansi)
-> So how can people create interoperable implementations?
-> I can see they can do some interoperable signalling, but I am not
-> sure that that is enough to make it work/interopeate in the dataplane
-> is it?
this question has been already debated (more than lengthy last
year)
-> As AD and IESG we want to know and understand.
-> Do you have a summary of the debate and a result that would make
-> a decent answer to this question?
the result of the answer is the splitting of the documents,
based on the following conclusion "standard sonet/sdh features
can be controlled by gmpls mechanisms described in the standard
track while non-standard sonet/sdh features can be controlled
by gmpls mechanisms described in the info track"
-> It is OK (or so I think) to point to proprietary documentation
-> if such is available.
here i am open to any valid reference (suggestions ?) from
the ccamp community
-> if anyone has a ptr to a doc, that would be a possible acceptable
answer.
i will do a search for such documents/references, if others
have any reference please share them with us
-> If not, then how can anyone create interoperable implementations.
-> And if they cannot do that, then why is this document useful?
-> I assume that some (that is mmore than one) vendors have agreed on
how
-> to implement this in the data-plane, right? Otherwise, why worry
about
-> a public doc about the signalling. So those vendors must have
documented
-> the data-plane implementation somehwere I would assume. Pointing to
that
-> would be fine."
this was more in the scope, if vendors have agreement at the
data plane level these extensions can be used, proposed ext
were not drafted based a wide (data plane) implementation
scale basis
> 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.
done as suggested
> 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?
done (as for draft-ietf-ccamp-gmpls-sonet-sdh-05.txt)
some additional comments received by maarten:
> 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.
done
other comments received from maarten (removed from the contributor
list as requested) were related to yours and thus i refer him to
the above responses
note: revisited draft-ietf-ccamp-gmpls-sonet-sdh-extensions-04.txt
version to be submitted during this week
> Thanks,
> Bert
thanks,
- dimitri.