Subject: I-D ACTION:draft-ietf-l3vpn-e2e-rsvp-te-reqts-01.txt

From: [email-masked]
Date: Mon, 14 Jul 2008 13:45:05 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title		: Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN
	Author(s)	: K. Kumaki, Y. Kamite, R. Zhang
	Filename	: draft-ietf-l3vpn-e2e-rsvp-te-reqts-01.txt
	Pages		: 22
	Date		: 2008-7-14
	
Some service providers want to build a service which guarantees QoS 
   or bandwidth from a local CE to a remote CE through the network. 
   Today, customers expect to run triple play services through BGP/MPLS 
   IP-VPNs. As a result, their requirements for end-to-end QoS of 
   applications are increasing. Depending on the application (e.g., 
   voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end 
   native RSVP path and/or an end-to-end MPLS TE LSP are required, and 
   they need to meet some constraints. 
   This document describes service provider requirements for supporting 
   customer RSVP and RSVP-TE over a BGP/MPLS VPN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-e2e-rsvp-te-reqts-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "dave.mcdysan" <[email-masked]>
Date: Mon, 28 Jul 2008 13:05:11 -0400

As I mentioned in the meeting, I question whether section 5.6 RSVP-TE over
LDP tunnels is something that should be added as a requirement. It seems
inconsistent with a number of points at the end of section 3, problem
statement:

   - C-RSVP path QoS guarantees. 
   - Fast recovery over BGP/MPLS IP-VPN to protect traffic for C-TE LSP 
   against CE-PE link failure and PE node failure. 
   - Strict C-TE LSP bandwidth and QoS guarantees. 

(Editorially, I suggest it would be helpful to separate specific
requirements from other text in section 3).

Also, is there any experience of operators doing RSVP-TE LSPs over
LDP-established LSPs? In general, I think the objective of this requirements
document is to make capabilities supported in provider networks available on
a virtualized, per-VRF basis. If no one is implementing this case in a
single provider network, then making this a requirement in a virtualized
network would not meet this objective.

Finally, as mentioned in the meeting, the assumption in sections 5.5 as well
as section 5.6 of "Please note that there is always enough bandwidth
available in service provider backbone." will be difficult to achieve
operationally, because there can always be a set of failures under which
there is insufficient bandwidth.

I thought I heard in the meeting that this case was added to address
scalability concerns expressed by Yakov in Philadelhia. RSVP-TE LSPs over
LDP-established LSPs does improve scalability in the sense that a full mesh
of TE-LSPs is not required between the PEs, but makes it difficult to
achieve other objectives in the problem statement.

I would recommend that the text proposing RSVP-TE over LDP tunnels and
specifically sections 5.5 and 5.6 be removed from the draft, unless the
authors can provide further rationalization of how this approach would meet
the generic requirements stated at the end of section 3.

Regards,

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> Sent: Monday, July 14, 2008 4:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-l3vpn-e2e-rsvp-te-reqts-01.txt
>

---

From: "dave.mcdysan" <[email-masked]>
Date: Mon, 28 Jul 2008 13:35:07 -0400

Regards,

Dave