[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?