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

[Jim Boyle <jboyle@pdnets.com>]

I'll infer that the answer to the last question in my email would be yes :)

The reason for my distinction on this is there seems to be a lot 
of VPN permutations in your scenarios.  In fact, section 5.9 talks about 
tying TE tunnels into the right VRFs - so again - seems very VPN focussed.

So as you say, the focus and intent is just on inter-as bandwidth, 
path-control and restoration, an extension of intra-area TE which we 
currently have today.  Great.

I'm wondering, do these requirements stand outside of current protocol 
capabilities?  By that I mean, are current protocols one of the approaches 
that should be considered to meet these needs? 

Or is it assumed that they can not, and this requirements document is an 
attempt to build a foundation upon which to augment existing protocols?

thanks!

Jim

On Fri, 7 Mar 2003, Jean Philippe Vasseur wrote:

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