[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IESG EValuation: draft-ietf-tewg-interas-mpls-te-req-08.txt
As agreed earlier on, this document is
Participant in PROTO Team pilot:
Workgroup Chair Followup of AD Evaluation Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt
So I have just collected all comments and am passing it to the WG chairs
to further shepherd composition of answers and possible updates to the document
based on the IESG review comments.
I personally believe it is probably best to do one more rev,
and pay special attention to comments from Allison, Ted and Harald.
Bert
--------------------- IESG review:
Discusses and Comments
Harald Alvestrand:
Comment:
[2004-08-19] Reviewed by Mary Barnes, Gen-ART
The abstract & title does not say that the document contains scenarios.
Perhaps it should.
Ted Hardie:
Comment:
[2004-08-17] There are a number of non-ASCII characters in section 4.
I personally found the use of the term "Application Scenarios" in section 4
confusing. These really don't relate to inter-AS traffic engineering requirements
for specific applications, the mention of voice over ip and video over IP
as a driver for 4.1.3 notwithstanding. These are deployment strategies that
inter-AS traffic engineering enables (or improves), not application scenarios.
In 5.1.2., the draft says:
One can conceive that an inter-AS MPLS TE tunnel path signaled
across inter-AS links consists of a sequence of intra-AS segments.
Do they mean that this is modeled as sequence of intra-AS segments?
In the same section, the draft says:
In addition, the proposed solution SHOULD provide the ability
to specify and signal that certain loose or explicit nodes (e.g. AS
numbers, etc.) and resources are to be explicitly excluded in the
inter-AS TE LSP path establishment, such as one defined in
[EXCLUDE-ROUTE] for instance.
This makes it looks like an AS number is a node, where I think
they mean the AS number is part of the tuple (as in 5.1.10.1).
Some clarification might be in order.
Allison Mankin:
Comment:
[2004-08-19] The document speaks of the OSPF-based TE:
However, because
these means offer coarser control of traffic paths and do not
readily offer bandwidth guarantees or fast restoration, they will
not be discussed further in this document.
It does not give citations of the work, or provide analysis of this negative
statement. There are claims to the contrary on these points, so it isn't really a
reasonable point to just throw in here, without analysis. Better to just say that this
document just chooses to explore the fine-grained approach using MPLS, rather than
pursuing the more aggregated approach using OSPF.
What is a "mechanism", which the document refers to these requirements as leading to?
Operational guidelines for the inter-AS usage?
The document has a list (5.2.2.1) of Inter-AS TE Enforcement Agreement Policies,
that "could be" enforced at the boundaries. The preemption object is under this
not very strong list. It would be very advisable to suggest it be not enforced,
because of the complex issues that arise composing preemption rules that have
been set by non-coordinated endpoints in the ASs and by the authorization issues.
----------- Further comments/nits from General Area Review Team:
This review was done at the request of GEN AD Harald.
---------- Forwarded Message ----------
Date: 18. august 2004 15:27 -0400
From: Mary Barnes <mary.barnes@nortelnetworks.com>
To: 'Harald Tveit Alvestrand' <harald@alvestrand.no>
Cc: gen-art@alvestrand.no
Subject: Review of draft-ietf-tewg-interas-mpls-te-req-08.txt
Assignment:
-----------
o draft-ietf-tewg-interas-mpls-te-req-08.txt
MPLS Inter-AS Traffic Engineering requirements (Informational) - 4 of 6
Note: NOTE WELL: revision 08 should arrive on August 12.. That is the
one
to be reviewed/approved.. . Participant in PROTO Team pilot:. Workgroup
Chair Followup of AD Evaluation Comments.
http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.t
xt
Token: Bert Wijnen
REVIEWER: Mary Barnes (mary.barnes@nortelnetworks.com)
Summary:
--------
The draft should be ready for publication as Informational with the
corrections noted below and perhaps some WG discussion (or chair feedback
at a minimum) on the comments identified below. I did find the document
difficult to read, but it could be entirely because I am neither an MPLS
nor traffic engineering expert. However, I have made some suggestions for
rewording for the areas that I found most difficult to read. Given that
it's a requirements document and has been approved by the WG, I don't think
any substantive editing effort beyond that is particularly worthwhile.
Comments:
---------
1. Given that this document also contains a substantive section on
application scenarios, it might be worthwhile to consider a change in name
to: "MPLS Inter-AS Traffic Engineering Requirements and Scenarios". In
which case, I would also suggest changing the second sentence in the
abstract from:
"Its main objective is to
present a set of requirements which would result in general
guidelines for the definition, selection and
specification development for any technical solution(s) meeting
these requirements."
to:
"Its main objective is to
present a set of requirements and scenarios which would result in
general
guidelines for the definition, selection and
specification development for any technical solution(s) meeting
these requirements and supporting the scenarios."
At a minimum, the abstract should include at least a mention of the
document also containing scenarios.
2. Page 8, section 3.3, 1st paragraph. Is this really supposed to be
dealing with "QoS guarantees"? Shouldn't this just be "bandwidth
guarantees"(per the general Objectives and Requirements in 3.2)?
3. Page 12, section 4.2.1, 2nd paragraph, last sentence. There's another
reference to "QOS services", but it seems that this should also be
"bandwidth guarantees". Or, this document needs to define what they mean by
QOS services.
4. Page 13, section 4.2.1, 7th paragraph, another "QoS" reference. Propose
to change "QoS requirement" to "bandwidth requirements".
Nits:
-----
1. Page 1. Status of this memo. Needs updating to the new template, per
the new guidelines.
2. Page 3, section 1, 1st sentence, the abbreviation for Service Providers
"(SPs)" should be added here as the term "SP" is used in a subsequent
paragraph.
3. Page 5, section 3.1, definition of Intra-AS TE, correct the extra
whitespace between "an" and "AS".
4. Page 5, section 3.1, definition of Inter-AS TE. Suggest to add the
following to this definition to clarify that this term is used specifically
to refer to IP/MPLS networks for the scope of this document (as clarified
later in the document in section 3.3):
"Since this document only addresses IP/MPLS networks, any reference to
Inter-AS TE in this document refers only to IP/MPLS networks and is not
intended to address IP-only TE requirements."
5. Page 7, section 3.2.2, 4th paragraph, 2nd sentence. For readability (and
per Webster's), change "Un-deterministic" to "Nondeterministic" and
"un-coordinated" to "uncoordinated".
6. Page 9, section 4.1.1, 4th paragraph, last sentence. For readability,
change: "beyond the scope of this document and will therefore not be
discussed here" to:
"beyond the scope of this document and are not discussed further."
7. Starting on Page 9, 5th paragraph, there are funky characters due to
using the wrong format for the single quote spread throughout the remainder
of sections in 4.1. (e.g. SP1Æs).
8. Page 12, section 4.2.1, 4th paragraph, 1st sentence. Change "Continent"
to "continent".
9. Page 12, section 4.2.1, 5th paragraph, 1st paragraph. For readability,
remove "(not partially)" OR add ", rather than partially" to the end of
that sentence.
10. Page 16, section 5.1.6, 1st sentence. Change "pair" to "pairs".
11. Page 16, section 5.1.6, 1st paragraph, last sentence. Add a "SHOULD"
prior to "interoperate" in the last sentence to highlight this 2nd
requirement (provided SHOULD is the appropriate strength for that
requirement).
12. Page 17, setion 5.1.7, 1st paragraph, last sentence. Ditto comment 10.
13. Page 19, section 5.1.13. Remove "on" from the phrase "SHOULD NOT impact
on existing".
14. Page 25, section 11. Copyright date should be 2004.