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

From: Jim Boyle <[email-masked]>
Date: Tue, 4 Mar 2003 12:10:46 -0500 (EST)

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

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 04 Mar 2003 18:56:05 -0500

Hi Jim,

>It seems to me that there are a few different requirements in this draft,

well I think there are a set of common requirements applying to different 
scenarios.

>(w/ a little QoS for flavor).

I'll let SPs speak up on this but in short the answer is "no", the main 
requirement is indeed about bandwidth guaranty (among some other 
requirements), not just connectivity, that's the point.

>So it seems the bulk of the discussion

I'm not sure to follow you there ... I thought there was an agreement on 
the fact that inter-AS TE requirements fit in the TE WG and so the 
remaining question was: "Is this draft representative of inter-AS TE 
requirements and so should be adopted as a TE WG requirements ?"

>approaches to Multi-AS TE?

Section 5 of the draft is dedicated to the list of requirements, it seems 
pretty straightforward that current intra-AS TE solution cannot address 
those requirements. Do you have a different view ?

Thanks.

JP.

---

From: Jim Boyle <[email-masked]>
Date: Wed, 5 Mar 2003 00:41:30 -0500 (EST)

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.

Personally, with most of these VPN scenarios, I'd suggest something IP
like a GRE or IPSEC tunnel.  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 - I
would think this would be more hypothetical than practically
applicable when the RSP and the GSP don't share owners.  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?

---

From: raymond zhang <[email-masked]>
Date: Wed, 05 Mar 2003 00:52:04 -0800

Hi Jim,

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

>         edge router (PE) in someone elses POP w/o direct connectivity

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.

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

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

>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

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 07 Mar 2003 11:56:28 -0500

Hi Jim,

>The last two are significant and are definitely not topics for TEWG.

Indeed, (MP)BGP do that perfectly well today

>like a GRE or IPSEC tunnel.

Sure, can be Inter-AS MPLS VPN also.

>If you have a special relationship with
>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
>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

---

From: Jim Boyle <[email-masked]>
Date: Fri, 7 Mar 2003 21:14:06 -0500 (EST)

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

---

From: Kenji Kumaki <[email-masked]>
Date: Mon, 10 Mar 2003 15:51:04 +0900

Hi Jim,

I think the latter is correct.
We need to extend a existing protocol(e.g. RSVP-TE) because a current
RSVP-TE can't cover an inter-AS TE.

We try to extend a current RSVP-TE in our draft.

Regards,
Kenji 

-- 
Kenji Kumaki <[email-masked]>

---

From: David Charlap <[email-masked]>
Date: Mon, 10 Mar 2003 10:01:59 -0500

> RSVP-TE can't cover an inter-AS TE.

What makes you say that?

I don't think current implementations can support this.  But RFC 3209 
includes inter-AS provisions.

See section 7.4.

One of the EXPLICIT_ROUTE subtypes is an AS number.  If one of these is 
present in an EXPLICIT_ROUTE object, then the abstract node represented 
is the entirity of the specified ASN.

Implementations should treat this in a similar fashion to how they treat 
an IP subnet ERO subobejct.  If it's the first subobject, then the 
router must be in that ASN.  If it's the subobject corresponding to the 
next-hop, then it should use that ASN to determine the next hop along 
the path to that ASN.  If the node is strict, then the next-hop address 
should be a part of that ASN.

I'm not sure if BGP provides sufficient information for generating a 
topology of ASNs (needed for generating an AS-hop-path).  An extension 
of some form might be necessary for this to work.  But that would be a 
routing extension, not an RSVP extension.  And it would only be 
necessary if you want to dynamically generate inter-AS explicit routes - 
a feature of dubious utility to begin with.

-- David

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 10 Mar 2003 21:15:23 +0100

David,
> includes inter-AS provisions.

The support of AS hops in the ERO is one part of the answer, but if
you want to support fast restoration of the interdomain links while preserving
the privacy requirement of ASes (i.e. not reveal detailed path inside an AS),
then RSVP-TE extensions are required.

You can find one proposal to extend RSVP-TE in

http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-09.html
also available as an internet draft but without nice figures

another draft focussed on interdomain protection is
http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protection-00.txt

Olivier

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 10 Mar 2003 17:54:12 -0500

Hi Jim,

>tying TE tunnels into the right VRFs - so again - seems very VPN focussed.

This draft is definitely not MPLS VPN specific. MPLS VPN is just one of the 
deployment scenarios.

As mentioned in the draft:
    Please note that terms of CE and PE used in the following diagrams
    are generic where it does not necessarily mean that CE is
    connected in a VRF (MPLS VPN) environment.

But we will further clarify this in the next revision of the draft, thanks 
for your comment.

>path-control and restoration,

Right.

>an extension of intra-area TE which we
>currently have today.

Not sure to see your point here.

>Great.

The set of requirements are listed in this draft.

Then the next steps will be to discuss how one can address those 
requirements and the set of required protocols extensions.

Up to now, I did not get the AD's answer on where (which mailing list) this 
discussion should take place but for the sake of illustration:

- Computation of an optimal inter-AS TE LSP path (* the term "optimal" 
needs to be defined of course): this requires some protocol extensions. Two 
scenarios have been proposed in: (1) 
http://www.ietf.org/internet-drafts/draft-vasseur-inter-as-te-00.txt
- Fast recovery upon ASBR node failure: the current FRR draft requires 
extension to be applicable to ASBR/SBR protection. See a proposal: (2) 
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject-00.txt 
+ the draft above.
- Reoptimization of loosely routed TE LSPs: I proposed (3) 
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-loose-path-reopt-01.txt

I'll present (2) and (3) in the MPLS WG, not sure yet about (1).

Thanks.

JP.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 10 Mar 2003 18:02:20 -0500

Hi David,

At 10:01 10/03/2003 -0500, David Charlap wrote:
>present in an EXPLICIT_ROUTE object, then the abstract node represented is 
>the entirity of the specified ASN.
>
>an IP subnet ERO subobejct.  If it's the first subobject, then the router 
>must be in that ASN.  If it's the subobject corresponding to the next-hop, 
>then it should use that ASN to determine the next hop along the path to 
>that ASN.  If the node is strict, then the next-hop address should be a 
>part of that ASN.

This is just one of the aspects of inter-AS, there are many others listed 
in the inter-AS requirements drafts. The point that Kenji wanted to make 
was that the current set of protocols for intra-AS TE does not allow to 
address all the requirements listed in the requirements drafts. I just 
dropped on the TE WG mailing list another email mentioning some of the 
required protocol extensions.

>topology of ASNs (needed for generating an AS-hop-path).  An extension of 
>some form might be necessary for this to work.  But that would be a 
>routing extension, not an RSVP extension.  And it would only be necessary 
>if you want to dynamically generate inter-AS explicit routes - a feature 
>of dubious utility to begin with.

Similarly to the inter-area TE case, there are several possible solutions 
there: we proposed some two of them in the following 
drat:draft-vasseur-inter-as-te-00.txt

Thanks.

JP.