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

From: "dave.mcdysan" <[email-masked]>
Date: Mon, 28 Jul 2008 13:43:23 -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
> 
> 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: <[email-masked]>
Date: Mon, 28 Jul 2008 20:41:58 +0100

Dave,

I agree with you...for performance inheritance reasons, which is sort-of
one of your observations on QoS below:

A link connection (ie 1-hop) in a layer N network is provided by a path
connection (ie end-end multi-hop) in a layer N-1 network.....although we
are considering nested LSPs in MPLS here (which are not true layer
network but let's ignore that aspect of MPLS) this principle is
completely general and it's how we construct (client layer) topology.
This principle (ie layer N link connection = layer N-1 path connection)
recurses to the duct.

Now the key point about this is that the end-end performance of a path
at layer N is the sum (to a very good 1st ~) of (i) the impairments
created in the layer N nodes plus (ii) the performance inherited in the
layer N link connections from the layer N-1 path connections....so we
get recursive impairment inheritance to the duct.

I assume many folks are familiar with ITU HRXs (hypothetical reference
connections, usually order 27500km) over which various network
performance (NP) metrics get allocated long-term objectives (eg monthly
errored periods, delay, etc) with subdivisions to smaller length
entities, eg per national operator (it's not linear, esp in access
networks).  However, I only mention this for one key reason:  All these
HRXs for ANY technology assume (and never state) that there is virtually
no performance inheritance issues to take into account from layer
networks below the one of interest.  This assumption can be valid IFF
the following conditions hold:
-	in the assumed transparent client_layer_N/server_layer_N-1
relationship, the server layer path connections are supplied by a co-cs
mode technology
-	and that, in turn, any lower (than N-1) layer network is also
co-cs right to the duct

The key point about this is that when using a co-cs mode server layer
for layer N-1 the traffic behaviour of any layer N client X CANNOT
impact the performance experienced by layer N client Y.  One does not
have to use the co-cs mode, the co-ps mode can closely approximate this
IFF:
-	it is based on proper connections (ie p2p or p2mp constructs
only)...a necessary condition 
-	there is no overbooking of the server layer resources...a full
sufficiency condition
.....these requirements are forced by the physics of the the co-cs mode
but have to be consciously architected in the co-ps mode.

A cl-ps server layer (eg IP or Ethernet) or a co-ps mode server layer
that violates these rules (eg LDP or PHP (last hop) merging in MPLS)
cannot meet these requirements.

So you are quite right to question the point in providing RSVP-TE LSPs
over LDP LSPs.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of dave.mcdysan
> Sent: 28 July 2008 18:43
> To: [email-masked]
> Subject: FW: I-D ACTION:draft-ietf-l3vpn-e2e-rsvp-te-reqts-01.txt
> 
>  
> 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:
> 
> (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 
> 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
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf