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

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.

Reviewed by Mary Barnes, Gen-ART

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.