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=20
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
>=20
>http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.t=
xt
>
>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=20
>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=20
requirements and scenarios are only there to help the understanding of=20
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=20
>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=20
>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=20
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=20
subobject during signaling in section 4.3.2, RFC 3209.  This was clarified=
=20
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=20
mentioning "AS numbers" as an example for the exclude-route requirement in=
=20
this paragraph.  Similarly, "AS2" was used by itself as a ERO subobject as=
=20
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=
=20
>really a
>reasonable point to just throw in here, without analysis.  Better to just=
=20
>say that this
>document just chooses to explore the fine-grained approach using MPLS,=20
>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=20
requirements
for a MPLS based, fine-grained approach for inter-AS TE.


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

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

"The document will also present a set of application scenarios where the=20
inter-AS traffic engineering mechanism may be required. This mechanism=20
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=20
>Policies,
>that "could be" enforced at the boundaries.  The preemption object is=20
>under this
>not very strong list.  It would be very advisable to suggest it be not=20
>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=
=20
>issues.

Good point, thanks...  In our thinking, weather to enforce on the=20
preemption or not is optional between the SPs, e.g. SP1 with preemption=20
implemented in their TE plane will want to enforce what preemption is=20
requested from SP2 when the inter-AS TE LSP endpoitns are coordinated=20
between SP1 and SP2.  So to this point, would it be acceptable if I change=
=20
"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 protected]>
>To: 'Harald Tveit Alvestrand' <[email protected]>
>Cc: [email protected]
>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 protected])
>
>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=20
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=C6s).

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=
=20
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