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

Hi Jim,

At 00:41 05/03/2003 -0500, Jim Boyle wrote:

>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.

Indeed, (MP)BGP do that perfectly well today

>Personally, with most of these VPN scenarios, I'd suggest something IP
>like a GRE or IPSEC tunnel.

Sure, can be Inter-AS MPLS VPN also.

>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 -


Regarding the bandwidth guarantee aspect, although some scenarios could 
certainly be deployed by peering SPs with Differserv only, there are some 
SPs that prefer to rely on control admission with TE (with or without 
Diffserv enabled backbones) to provide such bandwidth guaranties, end to 
end, across AS boundaries. Those SPs expressed their opinion on the list 
(Infonet, FT, KDDI, ...), they are co-authoring this draft.
Moreover, the need for fast restoration in case of link / node (ASBR) 
failure (with or without QOS guaranties during failure) is also a MUST for 
them.

>I
>would think this would be more hypothetical than practically
>applicable when the RSP and the GSP don't share owners.

The draft covers the two scenarios and each of them corresponds to an 
existing need as mentioned by those SPs on the list.

Note that interconnection of multiple administrative domains is not new 
(see X75).

Thanks.

JP.

>  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?