Inter-domain framework

["Adrian Farrel" <adrian@olddog.co.uk>]

Folks,

We have updated the inter-domain framework after WG last call and
submitted it for publication. The changes, in addition to typos, are
listed below.

Since it is quite a long list of (purely editorial) changes, I will hold a
further, brief WG last call on this I-D once it has been published.
I will ping the MPLS WG as well since they should have an interest
in this I-D.

Thanks,
Adrian

++++

Abstract
Clarify that LSPs we are discussing are TE LSPs.

1. Introduction
Clarify that LSPs we are discussing are TE LSPs.
And that we are interested in all source-based and constraint-based routed
LSPs.

1. Introduction
Clarify the meaning of "wholly or partially overlapping domains".

1. Introduction
Add reference to [GMPLS-AS] for GMPLS-specific issues

1.1. Nested Domains
Remove reference to [MRN] as it is a distraction in this context.

2.1. LSP Nesting
Re-draft to (largely) replace references to FA LSPs with references to
hierarchical LSPs.

2.1. LSP Nesting
Clarify the role of policy in inheritance rules for dynamic LSPs.

2.1. LSP Nesting
Clarify the end-to-end consistency of objects that have end-to-end
significance

2.2 Contiguous LSP
Clarify the definition of contiguous LSPs.

2.3. LSP Stitching
Replace reference to FA with reference to TE link.

2.5. Control of Downstream Choice of Signaling Method
Clarify the dangers of allowing too many implementation options.

3.2.2 Partial Visibility Computation
Clarify that the example EROs are only examples.

3.4.2. Path Computation Use of PCE When Preserving Confidentiality
Clarify how the full path can be computed once, and supplied in pieces at
domain boundaries.

4. Distributing Reachability and TE Information
Final paragraph.
Clarify the conditions for inter-domain TE exchange. Specifically that
requirements and benefits must be established before doing protocol
work.

5.1. LSP Re-Optimization
Clarify the paragraph on end-to-end diversity to show that we are
applying any kind of diversity constraint to a set of end-to-end paths
that cross multiple domains.

5.4. Fast Reroute
Clarify that FRR applies to packet-based technologies only.

5.4. Fast Reroute
Point out that protecting border nodes when they are ingress of egress
of hierarchical LSPs or stitched segments may lead to different
protection behavior.

5.5. Comments on Path Diversity
2nd para
Clarify the "ease" of resolution of path diversity problems.

5.5. Comments on Path Diversity
Final para.
Clarify the scope of SRLG identifiers.

5.10. Applicability to Non-Packet Technologies
Add note that Segment Protection is also applicable to the packet-based
FRR problem.