Re: Multi-AS needs : draft-zhang-mpls-interas-te-req-02.txt

[Jim Boyle <jboyle@pdnets.com>]

Let me try this another way.

In scenarios 1-3, there are several aspects to consider.

o) how to secure bandwidth (prevent congestion)
o) how to deal with topology changes
o) how to extend one's routing through another AS
o) how to provide connectivity to a remote element of your network

The last two are significant and are definitely not topics for TEWG.

Personally, with most of these VPN scenarios, I'd suggest something IP
like a GRE or IPSEC tunnel.  If you have a special relationship with
the other provider (e.g. the RSP) then maybe you can agree on some
diffserv to aid if there is congestion.  In your draft there is a
presumption of MPLS to provide the connectivity.  While using
something like RSVP/MPLS might appear to help with bandwidth and
restoration *and* you could likely pass VPN traffic over this LSP - I
would think this would be more hypothetical than practically
applicable when the RSP and the GSP don't share owners.  But that's
just my $.02 on the VPN connectivity and I consider it irrelevant to
TEWG.

That leaves us with the first two, securing bandwidth across AS
boundaries and dealing with topology changes.  This sounds right
up our alley in terms of extending RFC3386 (e.g. section 4.3)
and even reviewing RFC2702 in this context. These first two are 
basically the essence of your Scenario 4.

Is the scope of your intent limited as I have outlined here?