The MPLS WG Archive

["Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>]

Hi Malick,
the draft pointed by Roberto in the previous mail proposes a more general solution with respect to the one you are referring to.
It introduces the extension of Tspec (FlowSpec) for MPLS scenario. This approach allows preserving the 
functionality of the Sender_Tspec (FlowSpec), without introducing a specific object for E-LSP.
In fact the MPLS Flow-Spec can be used for both E-LSP and L-LSP, and even for QoS over MPLS scenarios other than DiffServ.   
Regards

Paola


-----Original Message-----
From: Abdul Malick [mailto:abdulmk@future.futsoft.com]
Sent: lunedì 19 novembre 2001 15.13
To: Roberto Mameli (ERI); Choudhury, Sanjaya; mpls@UU.NET
Subject: RE: How are the domain administrators are planning to use
E-LSPs?


Hello Roberto,
Thanks for your reply. The following draft released by Nabil Seddigh &
others discusses about signaling BW per OA / PSC for E-LSP. Hope its of some
help to you.

http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt

Regards,
Malick.

-----Original Message-----
From: Roberto Mameli (ERI) [mailto:Roberto.Mameli@eri.ericsson.se]
Sent: Monday, 19 November 2001 6:55 PM
To: 'Abdul Malick'; Choudhury, Sanjaya; 'mpls@UU.NET'
Subject: RE: How are the domain administrators are planning to use
E-LSPs?


Sanjay and Abdul,

in my opinion there are a lot of possible scenarios in which E-LSP are
useful... some of them are described in appendix A of
draft-ietf-mpls-diff-ext-09.txt (see e.g. scenario 3).
Just to add another example consider a provider running only a couple of BAs
(e.g. a premium and a standard class of service) that would like to traffic
engineer its network. He could be simply interested in fair distribution of
traffic at the purpose of avoiding congestion and increase efficiency,
without the additional complexity of per-class routing and per-class
protection/restoration functionality. In this case E-LSP is the right
solution; it provides all the functionality requested in this scenario and
also allows label space saving (as Abdul correctly states).

As far as per-PSC BW requirements signaling concerns, the standard currently
doesn't cover this issue. In my opinion this represents an inconsistency.
Just consider that the Class-Type proposed to reduce IGP flooding is not
compatible with E-LSP (unless you find a way to signal BW per-PSC). A
proposal in the direction of filling this gap is given in:
http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt

Hope it helps

Regards,
Roberto


> -----Original Message-----
> From: Abdul Malick [mailto:abdulmk@future.futsoft.com]
> Sent: Friday, November 16, 2001 3:31 PM
> To: Choudhury, Sanjaya; 'mpls@UU.NET'
> Subject: RE: How are the domain administrators are planning to use
> E-LSPs?
>
> 	Hi! I have some basic questions related to the usage of E-LSPs.
> 	I will appreciate, if you can help me with the
> following questions:
>
> 	Q1. Is any domain administrator/service provider actually using
> 	(planning) to use the E-LSPs in their network ? In which cases,
> 	E-LSPs are more useful than L-LSPs?
>
>
> 	>> One advantage of using E-LSP, i think is the
> conservation of Labels. In
> case we know that the path taken by an LSP is capable of
> supporting all the
> required services. Then we can conserve labels by using one
> E-LSP to support
> more than one PSC (to support the required services). In case
> of L-LSP we
> will have to use one LSP for each PSC and hence waste more
> labels. Is that
> right?
>
> 	Q2. While deploying E-LSPs in the network, is the primary usage
> 	is limited to differentiation via the signaled DiffServ
> classes ?
>
> 	OR is there practical use for reserving (and enforcing)
> bandwidth
> 	for the E-LSP  (per LSP / per PSC bandwidth specification) ?
>
> 	>> I don't know if there is a means to signal the
> distribution of the BW
> among different PSCs carried in an E-LSP. I think the present
> approach is to
> use predefined distribution (configuration). Please correct me if i am
> wrong.
>
>
>
>
> 	Currently, the DS-TE-requirement draft does not address the
> 	E-LSP related requirements very clearly. Should it be updated
> 	with E-LSP related requirements?
>
> 	Thanks,
> 	sanjay