[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Neil,
could you check below I got it right:
> > -----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.
Is it correct that what you are describing here is the ability to transport
multiple OAs on a single LSP and have the path for this LSP be computed
based on one "effective Bw" for that LSP , and have one single
survivability policy/attribute (as opposed to one independent survivability
policy/attribute for each OA)?
Thanks
Francois
> 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.
> > >
> > >
> >
> >
_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone: +33 4 97 23 26 19
Mobile : +33 6 89 108 159
Fax: +33 4 97 23 26 26
Email: flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410 Biot - Sophia Antipolis
FRANCE
_________________________________________________________