RE: TE Requirements Draft - ELSP

["Sudhakar Ganti" <sganti@tropicnetworks.com>]

Thanks Neil for your comments. per-OA SLAs within
an E-LSP and protection were one of the motivations in
seeking the per-OA signaling requirements for E-LSPs.
Specially I see the usefulness of this in L2VPN deployment.
With L2VPNs, one may want to provide end-to-end services
with single E-LSP (easy for maintenance, protection and
restoration) and yet guarantee SLAs for multiple classes
within that E-LSP. I don't think this can be achived
easily with exisitng solutions.

-Sudhakar

> -----Original Message-----
> From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
> Behalf Of neil.2.harrison@bt.com
> Sent: Wednesday, November 21, 2001 3:15 AM
> To: joel@stevecrocker.com; Roberto.Mameli@eri.ericsson.se;
> te-wg@ops.ietf.org
> Cc: sganti@tropicnetworks.com
> Subject: RE: TE Requirements Draft - ELSP
>
>
> Joel/Roberto.....One reason why E-LSPs might of interest to
> operators in the
> context of VPNs noting that:
> -	DS classes only provide information on the up-state QoS forwarding
> treatment......they cannot distinguish between one pkt's
> survivability needs
> over another pkt of the same or different DS class.  However, I can easily
> imagine many cases where voice/data applications may or may not be mission
> critical both within the same, and across different, VPNs....and only the
> customer really knows this;
> -	if we have LDP deployed with like-DS-class aggregation across all
> VPNs then it will not be easy (impossible?) to offer robust and measurable
> separate availability and QoS SLAs to such VPN customers;
> -	I would also argue that VPNs customers don't care about other
> VPNs.....they only care about their VPN and expect the operator to be able
> to look after the VPN as an entity (ie a whole) rather than a set of pkts
> treated in isolation;
> -	the current solution (sic) is to over-engineer networks, at least
> for certain classes.
>
> So one possible use of E-LSPs therefore might be to provide VPNs where per
> VPN SLAs are required on availability and QoS.  To do this ER E-LSPs would
> need some 'effective BW' and 'survivability' attribute.  L-LSPs
> can also be
> used, but these simply increase the label/LSP requirements and one still
> needs some overall encapsulation of the constituent L-LSPs (on a per VPN
> basis).
>
> I know this is not exactly what you guys are discussing wrt DS/TE for
> E/L-LSPs, however it is something I think operators should be
> interested in
> wrt E-LSPs and their potential usefulness.
>
> regards, Neil
>
>
>
> > -----Original Message-----
> > From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> > Sent: 20 November 2001 19:18
> > To: Roberto Mameli (ERI); TE WG
> > Subject: RE: TE Requirements Draft - ELSP
> >
> >
> > The CAC is not the problem.
> > The CSPF, and the source of the information for the CSPF, is the
> > problem.  Not only do you have to give the requirements to the CSPF
> > algorithm (a local process, or a central one, or ... but
> > anyway not what we
> > are discussing), but you also must include all N individual bandwidth
> > requirements in your request.  That is, when you signal the
> > LSP you must
> > tell the network how much bandwidth you will use for each
> > class within the
> > LSP.  This is necessary for two reasons:
> > 1) The CSPF information may have been out of date, and
> > therefore must be
> > checked per link per class
> > 2) Each link needs to update its per class utilization
> > information, and it
> > can only do so if you provide sufficient information.
> >
> > Therefore, what you have done is NOT signal one TE LSP, but rather to
> > signal N LSP with the requirement that they be routed, protected, and
> > re-routed together.  You got no effective scaling benefit
> > because all the
> > bookkeeping has to look at these as separate LSPs.
> >
> > Hence, the capability you are asking for is the capability to
> > signal an LSP
> > bundle that is to be treated together.  That is an
> > interesting feature, but
> > not a trivial extension to what we have if it is to be done right.
> >
> > Yours,
> > Joel M. Halpern
> >
> > At 07:45 PM 11/20/01 +0100, Roberto Mameli (ERI) wrote:
> > >So, it seems to me that aggregate TE simply means that I
> > choose a single
> > >path supporting all BAs, with the same
> > protection/restoration options.
> > >This does not automatically preclude that CSPF and CAC
> > require  per-PSC
> > >bandwidth information as an input. I simply give N bandwidth
> > requirements
> > >(one for each of the N classes) to the CSPF algorithm, and
> > it gives me
> > >back a SINGLE path capable of carrying all the BAs. If my
> > CSPF would run
> > >based only on the E-LSP aggregate bandwidth I would not be
> > able to choose
> > >between two different paths with the same total occupancy...
> > see again my
> > >previous example, where each link is preconfigured to 50% in all the
> > >routers (not reserved, simply preconfigured). In that
> > example I do NOT
> > >make aggregate reservation... I have preconfigured BW in
> > every node and
> > >simply need some additional information to choose the best
> > way to route
> > >the new LSP.
> > >
> > >However, my point is that I don't want to force the SP to
> > use E-LSP. I
> > >just want to say that, since E-LSP exists, a provider could
> > be interested
> > >to use it (for whatever reason). If E-LSP cannot be used for
> > nothing more
> > >than pure DiffServ, than there is no reason to have E-LSP.
> > Just set up N
> > >L-LSP instead of a single one carrying N OAs. But if we
> > think that E-LSP
> > >are really useful we cannot bias the standards towards a
> > specific solution.
> >
> >
>
>