[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 12:10 PM 3/4/2003 -0500, Jim Boyle wrote:


It seems to me that there are a few different requirements in this draft,
taking a look at the scenarios in section 4, we have
Not quite so, I am afraid. Application scenarios presented in section 4 reflect some real applicable cases on many SP's networks today where MPLS TE capability is required beyond AS boundaries. In other words, all these scenarios share some or all aspects of requirements summarized as below:
- Transmission resource optimization across inter-AS links
- Resource guarantee so as to maintain performance objectives along the QoS paths across multiple ASes
- Fast local repair upon link/SRLG/node failures across inter-AS links

All of which are clearly difficult to achieve with inter-AS facilities available today. The difficulties are further compounded by lacking of resource and performance visibility and manageability along the QoS paths beyond AS boundaries across which services are offered.

1) Virtual POP - extend network through another's, place your
        edge router (PE) in someone elses POP w/o direct connectivity
        to your network.
Again, bandwidth resource guarantee from the virtual PoP, yet still maintaining transparency to RSP internal network changes in resource capacitation, routing, network events, etc. is the key here.

2) Similar to 4.1, but in this case virtually extend your edge port
        onto another providers router (or all the way to customer).
Indeed similar to Scenario I, but without co-lo GSP's PE routers... Requirements remain the same.

3) CE to CE w/ QOS quarantees from multiple providers
For example, when the propagation delay can be bounded, a QoS path with bandwidth guarantees (inter-AS DS-TE) would provide the performance required for an e2e VoIP connection established along an EF path across multiple ASes...

4) Multi-AS TE within one Provider (e.g. global)
As you indicated below, this is one of the most prominent requirements of inter-AS TE for global SP's networks, e.g. with multi-AS routing architecture.

5) Extend one's network through another

Scenarios 1-3 and 5 to me just seem to be inter-provider VPN requirements
(w/ a little QoS for flavor).  So it seems the bulk of the discussion
should happen elsewhere, right?
That's what SPs are doing now offering services across the AS boundaries (VPN is not the only one) without any sort of QoS guarantees where there are number of difficulties hard to overcome across the inter-AS links:
- SLA boundaries, e.g. 200ms VoIP delay bound is required along a EF path across AS boundaries, but without bandwidth guarantee, how much delay budget should we allocate for each AS segment belonging to different admin domain despite the fact that resource, network condition and routing could change in one of the AS segments over which the originating AS has no control ? Offering SLA on a segmented SLA path is not an acceptable option.
- Reliability with local fast repair does not exist

I think we generally understood quite well on the issues revolving around inter-provider VPN requirements (beyond just connectivity) since there are already a deployment base in number of years now. What we are struggling with is how to offer services (not just limited to VPN) across AS boundaries with the level of predictability and reliability similar to what we can achieve within one's own AS... So it seems that the discussions on issues presented in this draft should remain in the te wg since these are TE issues extended across ASes. I thought this was generally agreed already during Atlanta meeting last Nov. I hope this further clarifies.

Scenario 4 looks right up our alley though.  So I have to ask - what about
current protocol specifications limits you from trying a few different
approaches to Multi-AS TE?
We spent quite sometime when working on the draft and discussing on the list in the past months on a set of detailed requirements documented in section 5 and found that they are indeed beyond current protocol specifications...

By the way, thanks for the comments and they are very helpful in clarifying the understanding on what are the issues this draft is trying to present in terms of requirements...

Regards,
Raymond

thanks,

Jim