MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
draft-ietf-tewg-interas-mpls-te-req-09

Doc is now approved with this RFC-Editor note:

Please change in section 5.2.2.1
OLD:
  The following provides a set of TE-LSP parameters in the inter-AS TE
  Requests (RSVP Path Message) that SHOULD be enforced at the AS
  boundaries:

NEW:
  The following provides a set of TE-LSP parameters in the inter-AS TE
  Requests (RSVP Path Message) that could be enforced at the AS
  boundaries:

Checking yet one more time with Allsion.
Specifically I suspect that the change in sect 5.2.2.1 from "could be"
to "SHOULD be" is NOT addressing Allisons comment.

Received from General Area Review Team

---------- Forwarded Message ----------
Date: 18. august 2004 15:27 -0400
From: Mary Barnes
To: 'Harald Tveit Alvestrand'
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.

[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.txt' added by Bert Wijnen

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[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.txt' added by Bert Wijnen

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: dinsdag 11 mei 2004 15:52
To: Ed Kern (E-mail); Jim Boyle (E-mail)
Cc: Alex Zinin (E-mail)
Subject: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt


WG chairs, as you probably have seen, we are processing this
as an experiment with new process:

  Participant in PROTO Team pilot:
  Workgroup Chair Followup of AD Evaluation Comments
  http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-01.txt

Supposedly you had been informed/consulted about this by the proto team,
and I assume you are OK with that. If not... pls do speak up (preferably
to the message from proto-team announcing us being part of the experiment).

So here we go with an initial set of comments. I am reading more and I am
asking OPS and RTG directorates for review.

1. ID-nits check:
  $ idnits-v1.24    network.  This allows SP1Æs customers connected to SP2 PE router to
                                  ^
  Line 488 contains non-ascii character in position 41.
  -->    TE LSP tail-end router located in SP1Æs network, as shown in the
                                              ^
2. Pls remove section: draft-ietf-tewg-interas-mpls-te-req-06.txt
  This makes no sense once it gets to "Publication requested" stage.

3. The use of RFC2119 language requires a normative ref to that doc.

4. Section 5.1.10.1 seems to require a writable MIB so that inter-AS TE
  tunnels can be configured (created. modified, deleted) via SNMP.
  It is OK with me... but are you sure that that is a hard requirement
  (MUST language is used) ?

5. Sect 5.1.12 and 5.1.13 use "SHOULD not" while I think "SHOULD NOT"
  is intended?

6. Lots of acronyms are used without being expanded the first time thye
  are used.

7. Sect 6.1 .... MMM.... what does it really mean?
  It is so flexible, that ... oh well ...

8. End of sect 6.2 says:
      Other criteria might be added as this draft will evolve.
  while this draft is now "complete", no?

9. I worry about several normative references to pretty old I-Ds.
  Any outlook that those will indeed be approved at some point in
  time. Maybe several references are pretty old and need updating? 

10. I understand that the doc is written by people for which English
    is probably a second language. But that results in it being tough
    reading. Is there a way to have someone check it for proper
    english and readable sentences?

Thanks,
Bert