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

From: raymond zhang <[email-masked]>
Date: Wed, 08 Sep 2004 14:57:15 -0700

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 <[email-masked]>
>To: 'Harald Tveit Alvestrand' <[email-masked]>
>Cc: [email-masked]
>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 ([email-masked])
>
>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