MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
Note: This ballot was opened for revision 09 and is now closed.
(Bert Wijnen) (was Discuss, Yes) Yes
(Harald Alvestrand) No Objection
Reviewed by Mary Barnes, Gen-ART
(Ted Hardie) No Objection
Comment (2004-08-17 for -** No value found for 'p.get_dochistory.rev' **)
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 184.108.40.206). Some clarification might be in order.
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
Comment (2004-08-19 for -** No value found for 'p.get_dochistory.rev' **)
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 (220.127.116.11) 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.