Re: Multi-AS needs : draft-zhang-mpls-interas-te-req-02.txt
"LE ROUX Jean-Louis FTRD/DAC/LAN" <[email protected]>
| Newsgroups | gmane.ietf.tewg |
|---|---|
| Message-ID | <1FB136FD10CE33409C882630E299F5BED0FA40@lanmhs30.rd.francetelecom.fr> |
>Why can't strict trans-as qos gaurentees be obtained today? Because there is currently no scalable mechanism providing an optimal placement of trans-as flows with QoS constraints. This definitvely requires E2E Constraint Based Routing provided by MPLS-TE. + currently no FRR for inter-AS links and ASBRs Thus the reason is IMHO clearly technical. Regards JL -----Message d'origine----- De : Jim Boyle [mailto:[email protected]] Envoye : jeudi 6 mars 2003 20:48 A : LE ROUX Jean-Louis FTRD/DAC/LAN Cc : [email protected] Objet : RE: Multi-AS needs : draft-zhang-mpls-interas-te-req-02.txt Why can't strict trans-as qos gaurentees be obtained today? Is the reason technical or "other"? On Thu, 6 Mar 2003, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > Hi Jim and all > > > >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? > > One of the various applications of inter-AS MPLS-TE is the provisioning > of L2VPN services with PEs located in two distinct ASs. > Typically such services have strict end-to-end QoS requirements that can > definitively not be ensured with current intra AS TE mechanisms. > Indeed a combination of intra-AS TE deployment cannot provide e2e TE, > e2e QoS, inter-AS link protection, ASBR protection,... > > Regards > > JL > > > > > -----Message d'origine----- > De : Jim Boyle [mailto:[email protected]] > Envoye : mardi 4 mars 2003 18:11 > A : [email protected] > Objet : Multi-AS needs : draft-zhang-mpls-interas-te-req-02.txt > > > > 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 > > 1) Virtual POP - extend network through another's, place your > edge router (PE) in someone elses POP w/o direct connectivity > to your network. > > 2) Similar to 4.1, but in this case virtually extend your edge port > onto another providers router (or all the way to customer). > > 3) CE to CE w/ QOS quarantees from multiple providers > > 4) Multi-AS TE within one Provider (e.g. global) > > 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? > > 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? > > thanks, > > Jim > > >