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