[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IESG EValuation: draft-ietf-tewg-interas-mpls-te-req-08.txt

Hi Bert,

Thanks very much for forwarding on IESG's comments. Please find our further comments in lines below:


At 02:22 PM 8/19/2004, Wijnen, Bert (Bert) wrote: 
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.


Ok, thanks.

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.

Will update the abstract... Since this document is really about requirements and scenarios are only there to help the understanding of requirement discussions, I would like to leave the title as it is now.

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. 

Right, I will remove the wording on the voip and viip...

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?

This was a mistake. It should be "AS segments". Thanks for pointing out. The following is the proposed wording:

"...a sequence of ASes, ASBRs and Inter-AS links."

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.

An AS may be considered as an abstract node which could be used as a subobject during signaling in section 4.3.2, RFC 3209. This was clarified at the beginning of this section:
"... when signaling the inter-AS TE LSP path:

      - a set of AS numbers as loose HoPs and/or
..."

That's why we did not provide any additional wording to elaborate when mentioning "AS numbers" as an example for the exclude-route requirement in this paragraph. Similarly, "AS2" was used by itself as a ERO subobject as well In 5.1.10.1.

Hope this clarifies.

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. 

Good point...  The following is the proposed wording for this paragraph:

"Please note that there are other means of traffic engineering
including Interior Gateway Protocol (IGP); metrics based (for use
within an AS); and Border Gateway Protocol (BGP) attribute based
(for use across ASes, as described in Appendix A), which provide
coarser control of traffic paths. However, this document addresses requirements
for a MPLS based, fine-grained approach for inter-AS TE.


What is a "mechanism", which the document refers to these requirements as leading to?
Operational guidelines for the inter-AS usage?

Here "mechanism" represents the protocol specifications based upon the requirements discussed here and their deployable implementations... if this needs further clarification, I could add a sentence at the end of paragraph 4 in section 1:

"The document will also present a set of application scenarios where the inter-AS traffic engineering mechanism may be required. This mechanism could be implemented based upon the requirements presented in this document."

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.

Good point, thanks... In our thinking, weather to enforce on the preemption or not is optional between the SPs, e.g. SP1 with preemption implemented in their TE plane will want to enforce what preemption is requested from SP2 when the inter-AS TE LSP endpoitns are coordinated between SP1 and SP2. So to this point, would it be acceptable if I change "could be" to "SHOULD be" ?

----------- 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".


Sure. will add it...

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."


Thanks for the wording.   Will incorporate....

At a minimum, the abstract should include at least a mention of the
document also containing scenarios.


As will do by incorporating the above wording.

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)?


Right... Will correct.  Thanks.

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.


Will correct also... Thanks.

4. Page 13, section 4.2.1, 7th paragraph, another "QoS" reference.  Propose
to change "QoS requirement" to "bandwidth requirements".


Yes... will update.  thanks...


Nits:
-----
1. Page 1. Status of this memo.  Needs updating to the new template, per
the new guidelines.

I am not aware of the new template. Would you please point me to the RFC documenting the new template ? thanks...


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.


Right.  Thanks.


3. Page 5, section 3.1, definition of Intra-AS TE, correct the extra
whitespace between "an" and "AS".


Yes, thanks.

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."


Will incorporate.  Thanks for the proposed wording.

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".


Thanks..  will correct.

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." 

Sure... thanks for the wording.

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).


Right... will correct them thanks.

8. Page 12, section 4.2.1, 4th paragraph, 1st sentence. Change "Continent"
to "continent".


will correct. thanks...

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.


Will use ",rather than partially"... thanks.

10. Page 16, section 5.1.6, 1st sentence. Change "pair" to "pairs". 

Right. Will correct. Thanks.

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).


Good point. will add. thanks.

12. Page 17, setion 5.1.7, 1st paragraph, last sentence. Ditto comment 10.

Will remove " ...and interoperate seamlessly with the current intra-AS MPLS DS-TE mechanism [DSTE-PROT]."...

13. Page 19, section 5.1.13. Remove "on" from the phrase "SHOULD NOT impact
on existing".


Will do. thanks.

14. Page 25, section 11. Copyright date should be 2004. 

Right.  Thanks...


Many thanks once again for your comments.

Regards,
Raymond and JP