Hello,
I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose
of the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html
Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.
Document: draft-ietf-rtgwg-cl-requirement-13.txt
Reviewer: Lou Berger
Review Date: 2013-12-11
IETF LC End Date: 2013-12-09
Intended Status: Informational
Summary:
I have some minor concerns about this document that I think
should be resolved before publication.
Comments:
I think the document is greatly improved since the previous last
call. I have some comments and reservations on the document that are
described below. As discussed on the list, I remain concerned about the
value of defining requirements in terms of nebulous "Performance
Objectives", but as this is acceptable to the WG I will not elaborate on
this concern further.
Major Issues:
No major issues found.
Minor Issues:
1. Terminology & consistency: the document coins the term "Advanced
Multipath":
Advanced Multipath is a formalization of multipath techniques
Do you see this term as a new noun, like LSP, or as an adjective? I
expected the latter, i.e. that it be used like "multipath" is used in
the above sentence, but it seems to be used as a new noun. I'm not sure
coining a new noun really makes sense, but if this the intent then the
last paragraph of section 2 needs to be revised as "Advanced Multipath"
will now have a specific definition as opposed to a generic term. Also I
suggest always capitalizing it (or even using the abbreviation "AM")
will clarify this distinction.
2. Editorial: server and client layer vs upper and lower layer.
The document uses server and client layer networks and LSPs and,
sometimes interchangeably or redundantly, upper and lower layer networks
and LSPs. I think this issue can be resolved by avoiding the term
client/server when referring to network layers and just using the
lower/upper terminology. The one exception to this is in the definition
Client LSP which should simply be defined in the context of a multipath,
i.e.:
OLD
A client LSP is an LSP which has been set up over a server layer.
NEW
A client LSP is an LSP which has been set up over Advanced Multipath.
I think this also means that usage of the term "Client" is limited to
"Client LSP".
3. Technical: The document should make it clear that LSPs can provide
paths from an Advanced Multipath. I suggest adding something like the
the following at the end of page 3
d. a lower layer LSP.
and at the end of the Component Link definition:
A component link may be provided via an LSP.
4. Editorial: Unless I'm mistaken, the requirements in this document
apply to the Advanced Multipath solution. In most cases the document
states requirements in the form of "The solution", but in a few cases it
just says "advanced multipath". I think these cases should be changed
to apply to an "Advanced Multipath solution". I think this comment
applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9.
5. Technical: use of "indicate" in FR10-13, FR14, FR15:
In these cases it is unclear if the requirements apply to
(a) a client's ability to indicate a desired service/LSP constraint or
(b) a selected component link's attribute that will be used by a client
LSP,
(c) both, or
(d) something completely different
The requirements should be clear to which entity the requirement applies.
6. The last paragraph in section 3.3. strikes me as both odd and out of
place. There are so many possible decisions that must be considered by
network operators relative to disruption and optimization. Why mention
just "power reduction"? Is there something special about the
interactions of multipath and power reduction? What value / information
does this paragraph add?
7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS?
Nits:
- References should be provided in all cases when referring to
"existing ... techniques"
Using line numbers from
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt
Line 112
s/SHOULD/should
Line 118
s/MAY/may
Line 149, match intro:
s/Advanced Multipath meets/Advanced Multipath is a formalization of
multipath techniques that meet
Lines 251-254, beginning with "The" through the end of the paragraph.
This should be an FR.
That's it,
Lou
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
