Subject: RE: TE Requirements Draft - ELSP

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Mon, 19 Nov 2001 14:18:07 +0100

Hi all,

I agree with Nabil when it states that current requirements PRECLUDE folks who are E-LSP capable from utilizing DS-TE. In fact consider the following example, where the network supports 3 Class Types:
 - CT2=EF
 - CT1=AF1+AF2
 - CT3=BE
Also imagine that on a given link the bw constraints are P1=20Mb/s, P2=60Mb/s, P3=100Mb/s, and that at a given moment in time the link is occupied only by 18Mb/s of EF traffic. A new E-LSP carrying an EF+BE flow of 10Mb/s total traffic, divided into 5Mb/s of EF traffic and 5 Mb/s of BE traffic should be refused by the link (in fact it cannot accept more than 20Mb/s CT2=EF traffic).

My question is: how can the network realize that the flow must be refused (or routed elsewhere) if there is no way to signal that the EF bw is 5Mb/s? Since the current signaling only allow to signal the total bw (i.e. 10Mb/s), how can we decide to admit or to reject the incoming E-LSP?

There are two possible answers:

(1) use L-LSP and set up two different 5Mb/s LSPs, one for EF and one for BE. Right, but if I'm not interested in the added value of L-LSP (i.e. the possibility to perform per-class routing and per-class protection/restoration) why should I use it? I see no advantages and at least one drawback (i.e. an increased number of LSPs to manage and longer tables in the LSRs).

(2) add the standards with the possibility to signal per-PSC BW requirements. A possible proposal in this direction is given in:
http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt

Best regards
Roberto

> -----Original Message-----
> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Friday, November 16, 2001 11:47 PM
> To: Francois Le Faucheur
> Cc: TE WG
> Subject: Re: TE Requirements Draft - ELSP
> 
> 
> Francois,
> 
> > Or are you suggesting operations of DS-TE over E-LSPs which 
> > transport multiple OAs? In that case, what are the Service 
> > Provider requesting this?
> 
> Yes to the former. You already heard from Jim Boyle wrt the latter.
> There are other service providers interested in this. I am not sure
> if they are willing to indicate their positions on the list. Jim gave
> an example application. There are other reasons folks are interested
> in using E-LSP with DS-TE. e.g. protection, l2vpns etc.
> 
> > Could these SPs clarify whether:
> > -  they would use this to do per-class admission control but not
> > do per-class routing (would it not be a pity to deploy all this
> > sophistication and have voice not being able to take its shortest 
> > path simply because there is no more resources for data on a link)?
> 
> We should be careful not to pre-suppose a solution in the 
> requirements.
> In some networks and service solutions it makes sense to route
> each class (or OA) on a different LSP while in others may want
> to route on the same LSP. In your statement above, you mentioned 
> that it would be a shame if voice cannot take the shortest path
> due to lack of resources for data. I would rephrase this to say
> that as long as constrained based routing algorithms (which are
> vendor specific) can select paths to meet the voice constraint,
> this should not be an issue. 
> 
> Best,
> Nabil Seddigh
>

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Mon, 19 Nov 2001 11:07:24 -0500

Hi Francois! Are you suggesting that we should restrict
the PHBs being carried on a single E-LSP to a single OA??

Thanks,
sanjay

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 9:35 AM
> To: Jim Boyle
> Cc: David Charlap; TE WG
> Jim,
> At 13:10 16/11/2001 -0500, Jim Boyle wrote:
> 
> >And some packet based equipment would prefer not to use the label for
> >things like queue selection.
> 
> This is exactly why the current "Requirements" document 
> already allows 
> DS-TE operations over E-LSPs (with a single OA per E-LSP). We 
> do not need 
> to change anything for this in the requirements document. Upcoming 
> Requirements draft clarifies this already.
> 
> Cheers
> 
> Francois
> 
> >Allowing the solution to be work for E-LSPs or L-LSPs is probably the
> >right approach.
> >
> >Jim
> >
> >
> >On Fri, 16 Nov 2001, David Charlap wrote:
> >
> > > Nabil Seddigh wrote:
> > > >
> > > > I thought I should get this comment in before the -02 version
> > > > of the Requirements draft emerges. Hopefully the authors will
> > > > consider the following suggestion:
> > > >
> > > > - I think it is useful to put an explicit requirement 
> that the TE
> > > >   solutions need to support both E-LSP and L-LSP. The way the
> > > >   draft reads at the moment, it does not come through clearly.
> > > >   Most of the examples and wording would lead one to 
> believe that
> > > >   the DS-TE solutions should only focus on L-LSP.
> > >
> > > You can't insert this requirement.
> > >
> > > Some hardware platforms (especially those using ATM-style 
> backplanes)
> > > are incapable of implementing E-LSPs.  These platforms 
> can only support
> > > L-LSPs.  It would be wrong to define DS-TE such that 
> these platforms can
> > > never be compliant.
> > >
> > > -- David
> > >
> 
> _________________________________________________________
> 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:                 [email-masked]
> _________________________________________________________
> Cisco Systems
> Domaine Green Side
> 400, Avenue de Roumanille
> 06 410  Biot - Sophia Antipolis
> FRANCE
> _________________________________________________________ 
> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 19 Nov 2001 17:48:42 +0100

>the PHBs being carried on a single E-LSP to a single OA??

Sanjay,

I'm saying:
         - if I don't want to do TE in my network, then I would use E-LSPs 
with as many OAs as I can fit on them.
         - if I want to do aggregate TE in my network, then I would use 
E-LSPs with as many OAs as I can fit on them. Then I am doing aggregate 
CSPF and aggregate CAC.
         - if I want to do per-class TE in my network, then I would use 
L-LSPs (or use E-LSPs with a single OA per E-LSP, ie transport only the BAs 
of one OA ). Then I am doing per-OA CSPF and per-OA CAC.

Cheers

Francois

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Mon, 19 Nov 2001 18:53:14 +0100

Hi Francois and all,

I do not completely agree with you. Please see my comments below.

> Sent: Monday, November 19, 2001 5:49 PM
> To: Choudhury, Sanjaya
> Cc: 'Francois Le Faucheur'; Jim Boyle; TE WG
> Subject: RE: TE Requirements Draft - ELSP
> 
>          - if I want to do aggregate TE in my network, then I 
> would use E-LSPs with as many OAs as I can fit on them. Then I am doing 
> aggregate CSPF and aggregate CAC.

In my opinion there are scenarios in which I want to do aggregate TE in my network, and at the same time I want to perform per-class CSPF and per-class CAC. Let me illustrate this concept through an example. Imagine 4 nodes A, B, C and D:

                +---+
    +-----------+ C +-----------+
    |           +---+           |
  +-+-+                       +-+-+
--+ A |                       | B +--
  +-+-+                       +-+-+
    |           +---+           |
    +-----------+ D +-----------+
                +---+

Each of the four links (AC, AD, CB, DB) can support a total traffic of 100Mb/s (up to 50 Mb/s of EF traffic and the remaining amount for BE). Now imagine that at a given moment in time the link occupancy is the following:

	Link AC: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 30Mb/s of which available for EF)
	Link CB: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 30Mb/s of which available for EF)
	Link AD: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 5Mb/s of which available for EF)
	Link DB: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 5Mb/s of which available for EF)

Now imagine that you want to set up an E-LSP from A to B requesting 20Mb/s of total bandwidth (10Mb/s for EF and 10Mb/s for BE). You can route it through C, but you can't do the same through D. This is a case in which I think that per-class CSPF and per-class CAC are useful even in the case of E-LSP.
In my opinion the service provider should be free to choose between setting up 2 L-LSPs (or two E-LSP carrying a single OA) or setting up just one carrying both classes. In the latter case the standard shouldn't artificialy limit its traffic engineering capabilities. As a pointed in my previous mail, the only piece we have to add in order to support this scenario is the possibility to signal per-PSC bandwidth requirements.

Regards
Roberto

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Tue, 20 Nov 2001 10:25:05 +0100

Hi Joel,

what do you exactly mean by "engineering the EF traffic separately from the BE traffic"? If you mean that I have to route/protect/restore etc. EF flows separately from BE flows I agree with you: L-LSP is the best choice. I'm not denying this.

What I state is that even in the case of aggregate TE (i.e. same route and same protection/restoration options for all the classes) it would be useful to have per-class CSPF and per-class CAC. Referring to the example in my previous mail, what do you decide when you have to set up a 10Mb/s E-LSP (50%EF and 50%BE)? Since both available paths (A-C-B and A-D-B) have 40Mb/s of available bandwidth and you don't signal per-PSC bw requirements of the E-LSP, they are equivalent for you. However, as stated in that example, the path through D is not good. Since the ingress LER A hasn't got enough information to realize this, it could choose the path A-D-B; the result would be a total amount of EF traffic equal to 45+10=55Mb/s against the 50Mb/s available, hence either EF traffic dropped in the core or LSP rejected. You can avoid this simply by choosing the path through C, but to do so you have to know the BW requirements per-PSC.

Of course you can also set up two L-LSPs and to admit/route them separately... right, but this means that you double states and ILM in the LSR and signaling for setup/teardown and soft state refresh (in the case of RSVP-TE) across the network. A small service provider with a simple network topology (i.e. quite unmeshed) and a limited set of service classes could be interested in limited Traffic Engineering capabilities (i.e. simple aggregate load balancing). So E-LSP is the best choice for him, why should it be forced to adopt L-LSP? If he uses a very simple CSPF algorithm that routes all classes together (e.g. a shortest path applied on the pruned network), what is the added value of doubling the number of LSPs? This is the point I was trying to outline in my example.

I agree with you and Francois... L-LSP is the best choice in most of the cases, but in my opinion we shouldn't forget that E-LSP exists and could be used in some scenarios. Otherwise, if we limit the E-LSP to those cases in which I do not perform TE at all, my question is: why do I use MPLS in those cases? Without TE and using only SPF, what do I gain by MPLS? A pure diffserv network should be enough, I think. What is the opinion of other people on the list?

Regards
Roberto

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 3:42 AM
> To: TE WG
> [Reformatted to convince the mailer to accept it...]
> 
> We already have a way (with two sub-cases) to meet the 
> requirement.  Fundamentally, if you want to engineer the EF traffic 
> separately from the BE traffic (which seems a sensible thing 
> to do) then do 
> so.  Insisting on using shared LSPs but separate advertisements and 
> engineering does not seem a noticeable improvement.  To quote 
> (or mangle a 
> quote from) several good people:
> Perfection is achieved when there is nothing left to remove.
> 
> To put this differently, if you really are trying to engineer 
> the paths 
> separately, it seems equally likely that you will get cases where the 
> composite LSPs do not take the right path, and you need separate 
> ones.  Forcing them together strikes me as bad advice to the 
> service provider.
> 
> IETF experience is that options (particularly very similar but not 
> identical options that meet the same goals) are dangerous and 
> counter-productive.  If we really need this option, there 
> ought to be a 
> clear reason that is not met by the existing tools.
> 
> Thank you,
> Joel M. Halpern
> 
> At 06:53 PM 11/19/01 +0100, Roberto Mameli (ERI) wrote:
> >Hi Francois and all,
> >
> >In my opinion there are scenarios in which I want to do 
> aggregate TE in my 
> >network, and at the same time I want to perform per-class CSPF and 
> >per-class CAC. Let me illustrate this concept through an 
> example. Imagine 
> >4 nodes A, B, C and D:
> >
> >                 +---+
> >Each of the four links (AC, AD, CB, DB) can support a total 
> traffic of 
> >100Mb/s (up to 50 Mb/s of EF traffic and the remaining 
> amount for BE). Now 
> >imagine that at a given moment in time the link occupancy is 
> the following:
> >
> >Now imagine that you want to set up an E-LSP from A to B 
> requesting 20Mb/s 
> >of total bandwidth (10Mb/s for EF and 10Mb/s for BE). You 
> can route it 
> >through C, but you can't do the same through D. This is a 
> case in which I 
> >think that per-class CSPF and per-class CAC are useful even 
> in the case of 
> >E-LSP.
> >In my opinion the service provider should be free to choose between 
> >setting up 2 L-LSPs (or two E-LSP carrying a single OA) or 
> setting up just 
> >one carrying both classes. In the latter case the standard shouldn't 
> >artificialy limit its traffic engineering capabilities. As a 
> pointed in my 
> >previous mail, the only piece we have to add in order to 
> support this 
> >scenario is the possibility to signal per-PSC bandwidth requirements.
> >
> >Regards
> >Roberto
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Nov 2001 07:32:22 -0500

Let me try to describe what I think your after, and how it can work with 
the current tools.
You are saying that you want to be able to do per-class CAC (probably 
necessary), and aggregated E-LSPs (desirable).  You then conclude that you 
need per link per class resource information.

If you want to be able to do per-link allocation between EF and BE, of 
course you need per-link per-class resource information.  In that case, it 
makes sense to do per-class LSPs.

If you are trying to do aggregate reservation, it must be because 
aggregation makes some sense.  In your example, not only do you have 
varying link utilization per class (a requirement to get the problem you 
suggest), but the links somehow know this.  In order for the links to know 
the EF and BE distributions, the reservations on the links must be per 
class.  But you just said that you are doing TE in aggregate!  Where did 
the link per class resource information come from?  Did the TE LSP 
reservation carry the individual resource requirements?  THen it was really 
two LSP setups, not one.

The usual assumption that allows aggregate TE and per-class CAC is where 
the allocation of intra-LSP resources is up to the LSP ingress.  In that 
case, for each LSP that it sets up, the ingree reserves a total 
bandwidth.  As a simple case, if EVERY ingress allows only 15% of EACH LSP 
to be used for EF, then by definition (assuming no overbooking) no router 
will see more than 15% EF anywhere.  If 15% is the supportable level of EF 
traffic with the guarantees you want to make, then you have achieved your 
goal.  At ingress, you make sure that the EF traffic you deliver into the 
network is less than 15% of each LSP you send it over.  (Do this by 
policing, CAC< or some other mechanism as you choose.)

Yours,
Joel M. Halpern

PS: Sorry I wandered a bit.  I am trying to find different views to 
exaplain what you might be after, since just there is presumably some real 
world problem you are trying to address.

At 10:25 AM 11/20/01 +0100, Roberto Mameli (ERI) wrote:
>Hi Joel,
>
>what do you exactly mean by "engineering the EF traffic separately from 
>the BE traffic"? If you mean that I have to route/protect/restore etc. EF 
>flows separately from BE flows I agree with you: L-LSP is the best choice. 
>I'm not denying this.
>
>What I state is that even in the case of aggregate TE (i.e. same route and 
>same protection/restoration options for all the classes) it would be 
>useful to have per-class CSPF and per-class CAC. Referring to the example 
>in my previous mail, what do you decide when you have to set up a 10Mb/s 
>E-LSP (50%EF and 50%BE)? Since both available paths (A-C-B and A-D-B) have 
>40Mb/s of available bandwidth and you don't signal per-PSC bw requirements 
>of the E-LSP, they are equivalent for you. However, as stated in that 
>example, the path through D is not good. Since the ingress LER A hasn't 
>got enough information to realize this, it could choose the path A-D-B; 
>the result would be a total amount of EF traffic equal to 45+10=55Mb/s 
>against the 50Mb/s available, hence either EF traffic dropped in the core 
>or LSP rejected. You can avoid this simply by choosing the path through C, 
>but to do so you have to know the BW requirements per-PSC.
>
>Of course you can also set up two L-LSPs and to admit/route them 
>separately... right, but this means that you double states and ILM in the 
>LSR and signaling for setup/teardown and soft state refresh (in the case 
>of RSVP-TE) across the network. A small service provider with a simple 
>network topology (i.e. quite unmeshed) and a limited set of service 
>classes could be interested in limited Traffic Engineering capabilities 
>(i.e. simple aggregate load balancing). So E-LSP is the best choice for 
>him, why should it be forced to adopt L-LSP? If he uses a very simple CSPF 
>algorithm that routes all classes together (e.g. a shortest path applied 
>on the pruned network), what is the added value of doubling the number of 
>LSPs? This is the point I was trying to outline in my example.
>
>I agree with you and Francois... L-LSP is the best choice in most of the 
>cases, but in my opinion we shouldn't forget that E-LSP exists and could 
>be used in some scenarios. Otherwise, if we limit the E-LSP to those cases 
>in which I do not perform TE at all, my question is: why do I use MPLS in 
>those cases? Without TE and using only SPF, what do I gain by MPLS? A pure 
>diffserv network should be enough, I think. What is the opinion of other 
>people on the list?
>
>Regards
>Roberto
>
>

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Tue, 20 Nov 2001 19:45:55 +0100

Hi Joel and all,

let me try again to explain my point of view. I have no reasons to prefer E-LSP with respect to L-LSP (and vice versa). I just observe that both exist and, probably, there is some reason justifying them.

It is very clear to me that in most scenarios L-LSP (or E-LSP carrying a single OA) are the best solution, since they offer advanced per-class TE capabilities and finer granularity per class control. I'm not discussing this. However my question is again: in which situation E-LSP (carrying several OAs) is preferable? Quoting Francois' previous mail:

>> - if I don't want to do TE in my network, then I would use E-LSPs with as many OAs as I can fit on >>   them.
>> - if I want to do aggregate TE in my network, then I would use E-LSPs with as many OAs as I can fit >>   on them. Then I am doing aggregate CSPF and aggregate CAC.

So, again, if I don't want to do TE in my network, I have probably no reasons to use MPLS at all. A pure DiffServ network is good in that case (please correct me if I'm wrong).

However, if I want to do aggregate TE in my network, I wonder what is the exact meaning of aggregate TE. You say that the "usual assumptions that allows aggregate TE and per class CAC is where the allocation of intra-LSP resources is up to the LSP ingress". I think this is very limiting and I wouldn't call it aggregate TE... it's quite similar to the situation of a pre-configured DiffServ network. Instead appendix A3 of draft-ietf-mpls-diff-ext-09.txt says:

   A Service Provider running 8 (or fewer) BAs over MPLS, performing
   aggregate Traffic Engineering (i.e. performing a single common path
   selection for all BAs), using aggregate MPLS protection   (i.e.
   restoring service to all PSCs jointly) and ..... etc.

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.

Hope this clarify my view.

Best regards
Roberto

> Sent: Tuesday, November 20, 2001 1:32 PM
> To: Roberto Mameli (ERI); TE WG
> > > >         Link AC: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 
> 30Mb/s of which
> > > > available for EF)
> > > >         Link CB: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 
> 30Mb/s of which
> > > > available for EF)
> > > >         Link AD: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 
> 5Mb/s of which
> > > > available for EF)
> > > >         Link DB: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 
> 5Mb/s of which
> > > > available for EF)
> > > >

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Tue, 20 Nov 2001 19:48:39 +0100

Nabil,

please see my comment inline.

> Sent: Tuesday, November 20, 2001 7:13 PM
> To: Joel M. Halpern
> Cc: TE WG
> You've made a valid point. However, there is no intention to FORCE 
> the SP to ALWAYS put the 2 classes on the same LSP. The point is
> that in certain cases (refer Jim's & Roberto's emails), an SP may 
> CHOOSE to do this. By restricting the standard, you ensure this 
> option is NOT at the disposal of the SP. 

Good point. I'm exactly trying to state this.

> > IETF experience is that options (particularly very similar 
> > but not identical options that meet the same goals) are 
> > dangerous and counter-productive.  If we really need this option, 
> > there ought to be a clear reason that is not met by the 
> > existing tools.
> 
> Point taken! I think this example is commonly given for RSVP-TE
> vs CR-LDP. 
> 
> However, you appear to have already pre-supposed that we must 
> have 2 different technology solutions (protocol extension) to 
> satisfy the requirements for single-OA E-LSP and multiple-OA 
> E-LSP. What if a single technology solution can satisfy both 
> requirements without undue complexity?
> 

I perfectly agree.

> Best,
> Nabil Seddigh
> [email-masked]

Regards
Roberto

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Nov 2001 14:17:54 -0500

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.

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Wed, 21 Nov 2001 11:09:35 +0100

Hi Joel,

please see below.

> Sent: Tuesday, November 20, 2001 8:18 PM

Yes, I completely agree.

> requirements in your request.

I don't understand why CSPF is the problem. I mean that including all the N individual bandwidth requirements in the LSP set up request does not represent a huge obstacle. In principle there are several approaches to do so. A possible one is based on the definition of a new Ctype for the Sender_Tspec and Flowspec objects in RSVP-TE, and is described in details in:
http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt
So, only a slight addition to the protocol, with minor impact and preserving backward compatibility. Why not?

> bookkeeping has to look at these as separate LSPs.

I do not agree. If you signal one LSP supporting N classes you have just one entry in each LSR forwarding table, one message for set up, one message for tear down and, in the case of RSVP, one refresh message every 30 seconds. If you signal N LSP you get N entries in the forwarding tables, N set up messages, N tear down messages and, in the case of RSVP, N refresh messages every 30 seconds. And what about IGP flooding? If a single LSP set up triggers a change in the network status and the corresponding flooding, maybe it is better to set up just one LSP instead of N. Thus some impact on the scalability exists. Maybe it is not dramatic, I agree! But I think that we should anyway consider it.

Again, I'm not saying that E-LSP is better than L-LSP. I'm not able to say it, since I am not a Service Provider. However I have no reasons to reject a priori E-LSP. If you give two options to a service provider, then let him choose without pushing towards a specific solution. Otherwise, don't give him two options... one is enough!

Best regards
Roberto

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Wed, 21 Nov 2001 14:34:26 +0100

Joel,

> what it does.  What I still don't understand is what problem it 
> solves.  Label utlization?  Recovery time?

we are probably approaching this issue from two different point of views. I'm not pushing E-LSP against L-LSP in order to solve a specific problem. As Nabil correctly told in his mail, the same debate could be done for RSVP-TE against CR-LDP. From a functional perspective they are equivalent, so why should we define two protocols when just one is enough? What kind of problem can be solved by CR-LDP that RSVP-TE is not able to cope with (or vice versa)? No one... there are no problems to solve; simply an operator could prefer CR-LDP, while another could choose RSVP-TE.

I perfectly agree with you when you say that is better to avoid unnecessary features... from my point of view, if a SP hasn't got at least some limited TE capabilities by using DiffServ over MPLS with E-LSP, then E-LSP is an unnecessary feature. You can do almost everything with L-LSP, no doubt on that, so why do we keep E-LSP?
The point is that if you don't allow some limited aggregate TE functionality when using E-LSP and use it as in a pure DiffServ scenario (as the example in one of your mails seems to suggest), then which is the added value of having E-LSP? If you give the operator the possibility to choose, you should give him two real alternatives, not just one.

So, there are two possible choices:
(1) keep using E-LSP with some aggregate TE functionality and give the provider the possibility to choose it (if it is suitable for its purposes). In this case there is a gap in the standard and the draft pointed in my previous mail is just an attempt to fill it (probably not the best solution possible, and we can discuss about that, but at least tries to address the problem).
(2) discard E-LSP since it is not a necessary feature.

The draft suggested in my previous mail is REALLY a slight addition: it is NOT a new object, but simply an extension of the existing FlowSpec object; it is completely backward compatible and can be incrementally deployed and finally, requires about 100 lines of code, that inserted in a software of more than 10000 lines, represent a minor change.

Regards
Roberto

> 
> Yours,
> Joel M. Halpern
> 
> At 11:09 AM 11/21/01 +0100, Roberto Mameli (ERI) wrote:
> >So, only a slight addition to the protocol, with minor impact and 
> >preserving backward compatibility. Why not?
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 21 Nov 2001 15:08:09 +0100

Hello,

Here's my analysis of the thread:

There are (at least) three "ways" E-LSPs may potentially be used for DS-TE 
and I suggest dealing with them separately:

1) using E-LSPs with traffic from a single OA:
==============================================
This is already explicitely allowed in the recently posted REQTS draft.
As pointed out already, one application for this to allow LSRs to pick 
queues based on EXP rather than Label.
I think everyone agrees this is all fine.

2) using E-LSPs with traffic from multiple OAs but using single CSPF
=====================================================================
Jim Boyle provided a convincing example of how this could be used in his 19 
Sept message (ie in the case where ratio between voice-sig and 
voice-payload is known and stable so both traffic can be treated together 
as a whole from CSPF viewpoint).
The important point is that although we have traffic from multiple OAs, 
those are really treated as a single "traffic trunk" from the DSTE perspective.
However, this is currently not allowed in the recently posted REQTS draft.
I agree that REQTS draft should be modified to allow this case. This does 
not create any significant changes to the current DS-TE model and does not 
entail any protocol extensions (ie it comes for free), so it would indeed 
be an artificial unnecessary restriction to rule it out.

3) using E-LSPs with traffic from multiple OAs each with their own SPF
======================================================================
In that case, EF and AF1 may be transported on a single E-LSP and would 
each have their own CSPF (ie own bandwidth, and being constrained by 
different bandwidth constraints, and then presumably with different 
restoration requirements, most probably different preemption priorities,...).
To me, Joel perfectly captured the implications of doing this in his 
message below. I'll still expand a little.

This would be a departure from the current TE/DS-TE model: so far all 
properties are associated with a tunnel (bandwidth, bandwidth pools, 
affinity, preemption, restoration) while this new model would require 
associating multiple sets of these attributes on every tunnel (eg. one set 
per transported OA). It would also require defining/implementing rules for 
dynamically mapping multiple OAs on a given LSP (like what do you do when 
you have put EF and AF1 on a given E-LSP and now there is a more optimum 
path for EF but which is not optimal for AF1: do you clear the existing 
E-LSP and try to find existing LSPs which can carry OA and EF on their new 
paths, do you resignal the existing LSP with a zero bandwidth for AF1,...).
Some may say this is a small departure, some say it is a significant departure.

This would also require protocol changes (eg. signaling multiple bandwidth 
on E-LSP; and I would presume also signal multiple preemption and also 
signal multiple affinity requirements...).
Some say these are small changes, some say we already have too many options 
and changes in the works.

Regardless of whether one thinks the departure from the model is small or 
significant, I think it is a fact that there is a departure which would 
need to be explicitely addressed with all its ramification (preemption, 
reoptimisation, ...); regardless of whether one thinks the protocol changes 
are small or significant, it is a fact that there would be protocol 
changes. Interesting engineering work, for sure. But I will repeat myself : 
I think we should only commit the TEWG to do such work if SPs require this 
in the foreseeable future. So let's hear what SPs say about this.
Otherwise, let's first focus on specifying a simpler solution that 
addresses what SPs want to do in the foreseable future so we can get it out 
the door fast. Then we can always expand if/when requirements expand.

Cheers

Francois

At 14:17 20/11/2001 -0500, Joel M. Halpern wrote:
>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 
>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
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 21 Nov 2001 15:21:04 +0100

At 14:34 21/11/2001 +0100, Roberto Mameli (ERI) wrote:

>As Nabil correctly told in his mail, the same debate could be done for 
>RSVP-TE against CR-LDP. From a functional perspective they are equivalent, 
>so why should we define two protocols when just one is enough? What kind 
>of problem can be solved by CR-LDP that RSVP-TE is not able to cope with 
>(or vice versa)? No one... there are no problems to solve; simply an 
>operator could prefer CR-LDP, while another could choose RSVP-TE.

Interesting. Do you think the IETF should have specified a third TE 
protocol, in case some SP might have prefered the 3rd one?

---

From: "Giovanna Piantanida (ERI)" <[email-masked]>
Date: Wed, 21 Nov 2001 16:36:48 +0100

Dear Francois,

>protocol, in case some SP might have prefered the 3rd one?

I don't get the spirit of this last remark: no one was suggesting to specify 
something just because SP could like to have it. in my opinion
the goal of discussion was, oppositely, 
not to persist in specifying something no SP on earth would ever actually
need to use.

best regards,
giovanna

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 21 Nov 2001 17:54:32 +0100

At 16:36 21/11/2001 +0100, Giovanna Piantanida (ERI) wrote:
>I don't get the spirit of this last remark:

Since the above was stated in response to the question of "what problem 
does it solve", this appear to me to be saying "well, it doesn't solve any 
problem but we should still do it because some SPs may end up using it". I 
didn't find this a compelling argument. I am glad if this was arguing 
something else (even if I don't quite get the argument).

>no one was suggesting to specify

Great. So I guess you would then agree we should first get SPs to express 
the need for something before including it in the requirements document and 
specifying the correponding extensions.
Wonderful.

Thanks for the clarification

Francois

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Thu, 22 Nov 2001 09:45:15 +0100

Hi Francois,

> > >protocol, in case some SP might have prefered the 3rd one?

of course I didn't ever said this. Let me try again to explain better, since I think it is always better to clarify in order to avoid possible misunderstandings.

> something else (even if I don't quite get the argument).

My example was NOT meant in the sense: "SPs MUST be able to choose" THEN "we HAVE TO define two (or more???) protocols to let them choose".
I stated exactly the opposite: "As a matter of fact two protocols exist" THEN "a SP COULD choose either one or the other".

Similarly: "As a matter of fact two different LSP for MPLS support of Diffserv exist" THEN "a SP COULD choose either one or the other".

I think that if you provide two solutions to a problem you can expect that some people will choose one of them and some others will choose the other. This is quite different from saying that you have to provide two solutions in order to allow the possibility to choose.

Anyway it was just an example to introduce the analogy... sorry if I was not able to make it clear. Maybe it just added confusion, so please forget it. Moreover it is a little bit off topic and we risk to detour from the real issue of the thread.

Regards
Roberto

---

From: "Giovanna Piantanida (ERI)" <[email-masked]>
Date: Thu, 22 Nov 2001 10:36:37 +0100

Hi Francois,

>specifying the correponding extensions.

not only I agree, but also I notice that you come exactly to the point ( to my point at
least) originating this discussion. 
What I think I was misled about , and beg for clarification, is , in fact, not purpose and motivation for E-LSP
themselves , but for extension of a 
DIFFSERV object for an E-LSP (Ref. section 5.2.1 of draft-ietf-mpls-diff-ext-09), even if
only optional, in the framework we all agree about. 

>1) using E-LSPs with traffic from a single OA:

A SP using DIFFSERV object would need LSRs to pick up queues based on (EXP , label)
couples, and this cancels, in my opinion, advantages of this first point.

>2) using E-LSPs with traffic from multiple OAs but using single CSPF

At first sight, and here is probably where I am missing something, I would
have said that having a dynamic establishment of EXP <-> PHB mapping could
complicate things in this case also.

this is why i was induced to think that reason for having DIFFSERV object 
in current extensions was that somebody exists who really wants to follow point #3

>3) using E-LSPs with traffic from multiple OAs each with their own SPF

and assuming  therefore as hypothesis, not as consequence, that such SPs exists,
per-OA signaling of bandwidth in E-LSP could be aimed to them, and this is why
it could be worth considering solutions for that,

regards,
giovanna

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Thu, 22 Nov 2001 10:49:54 +0100

Hi Francois,

your analysis helps me in explaining my concerns. I try to summarize, please see my comments in line.

> 1) using E-LSPs with traffic from a single OA:

I completely agree.

> I agree that REQTS draft should be modified to allow this 
> case. 

I agree up to this point.

> This does 

I do not agree on the last observation, but maybe there is something that I'm missing.
Referring to Jim's example (where ratio between voice-sig and voice-payload is known and stable so both traffic can be treated together as a whole from CSPF viewpoint) my concern is the following. I understand that the ratio voice-sig/voice-payload is known, but I guess that it is known only to the user originating these flows. Since there is no way to signal this ratio to network elements I guess that those elements don't know the exact proportion of the two types of traffic carried within the E-LSP.

Here comes up my question: do network elements along the path need to know this ratio of traffic? I think they do, and this is what the protocol doesn't allow at the moment. But maybe this is not an issue and I have just misunderstood the problem. In that case, I guess that all the issues related to the allocation of intra-LSP resources are up to the LSP ingress. So again, I don't see a great difference with the standard DiffServ model, and this is the reason that leads me to the conclusion that probably this is not what is commonly known as "aggregate TE".

> 3) using E-LSPs with traffic from multiple OAs each with their own SPF

I completely agree with you that this is a departure from the current model. In fact I haven't ever considered a scenario like this. This is not what I am proposing. If you need different CSPF, different bandwidth constraints, different restoration requirements, different preemption priorities, etc. you're not really doing aggregate TE. Just set up different LSP and the whole thing will become simple. We don't need complex extension to include this scenario, I perfectly agree. The real point was the one stated above.

Hope it helps

Best regards
Roberto

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Nov 2001 07:10:54 -0500

If the ratio is different for each LSP, then the elements need to know it.
However, if the ratio is fixed across the service provider, then there are 
ways to engineer traffic (that is what we are doing here, right?) that 
avoid needing to know internally the component weights.  (And yes, you 
don't lose capacity in doing so.)

If there are two types of LSPs which mix traffic classes in two different 
proportions, then you probably start having trouble, although I have not 
analysed that as carefully.

Yours,
Joel M. Halpern

At 10:49 AM 11/22/01 +0100, Roberto Mameli (ERI) wrote:
>Referring to Jim's example (where ratio between voice-sig and 
>as a whole from CSPF viewpoint) my concern is the following. I understand 
>that the ratio voice-sig/voice-payload is known, but I guess that it is 
>known only to the user originating these flows. Since there is no way to 
>signal this ratio to network elements I guess that those elements don't 
>know the exact proportion of the two types of traffic carried within the E-LSP.
>
>Here comes up my question: do network elements along the path need to know 
>this ratio of traffic? I think they do, and this is what the protocol 
>doesn't allow at the moment. But maybe this is not an issue and I have 
>just misunderstood the problem. In that case, I guess that all the issues 
>related to the allocation of intra-LSP resources are up to the LSP 
>ingress. So again, I don't see a great difference with the standard 
>DiffServ model, and this is the reason that leads me to the conclusion 
>that probably this is not what is commonly known as "aggregate TE".

---

From: [email-masked]
Date: Thu, 22 Nov 2001 12:51:36 -0000

Hi Francois...see below, regards, Neil
> > > 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)?
NH=> Effectively yes.  As I tried to point out previously, there is no
relationship between an applications up-state QoS requirements (ie in DS
class X) and its need to survive vis-a-vis like pkts also of DS class X or
indeed other pkts of DS class Y (from the same or other VPNs).  To me that
is the fundamental problem.  Now whilst in a 'public' service case one can
of course aggregate like-DS classes and treat the whole population according
to some same-treatment-applies-to-all rules, I am not sure this would be
acceptable to all VPN customers.  If I bought a VPN off a SP I don't care
about other VPNs, I only care about the survivability/QoS performance of my
VPN.  And my priorities in using DS codepoints may be completely different
to someone else's.  So what does the SP do?  The only solution to me is to
be able to decouple whatever I do for my 'public' services from what I do
for my VPN customers......and the only way I can see to do this in MPLS (ie
so I have a chance of offering robust availability and QoS SLAs) is to
manage the VPN service on an 'LSP-basis' rather than on a 'per pkt-basis'.
Hence, I am suggesting that E-LSPs look like a potential method to do this
in MPLS (as I simply can't see how to do it with LDP and like-DS-class
merging across all VPNs....since defaults back to the per pkt-basis)......an
alternative of course is to continue to service these customers using FR and
ATM.

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 22 Nov 2001 13:13:15 +0100

Giovana,

>couples, and this cancels, in my opinion, advantages of this first point.

But the SP can use "normal" E-LSPs (ie the "E-LSP with default EXP<-->PHB 
mapping as per diff-ext-09). So there is no need to signal the DIFFSERV 
object in that case and the queue can be picked directly from EXP; just 
like SPs actually do today in real life networks.

>complicate things in this case also.

Again, the SP can use "normal" E-LSPs (ie the "E-LSP with default 
EXP<-->PHB mapping as per diff-ext-09). So there is no need for dynamic 
establishment of EXP<-->PHB mapping in that case either.

>and assuming  therefore as hypothesis, not as consequence, that such SPs 

We certainly agree that IF there are such SPs, THEN corresponding protocol 
extensions should be specified (BTW I think it would actually require more 
than just per-OA bandwidth eg. also per-OA affinity and per-OA preemption; 
basically per-OA everything; otherwise it would just be halfway there and 
you couldn't really do proper per-OA CSPF).

Based on the top of this message I think we also agree that IF such SPs do 
NOT cleary exist today, THEN we should NOT specify those extensions today.

Cheers

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 22 Nov 2001 12:52:35 +0100

Roberto,

> > I think everyone agrees this is all fine.

super.

>I agree up to this point.

super.

>doesn't allow at the moment.

I agree they do have to know the "ratio".
But they don't have to be told via signaling. They are effectively told 
through the Diff-Serv config anyway. In Jim's example, the SP just has to 
configure the voice-sig queue 4 times smaller than the voice-payload queue.

>But maybe this is not an issue and I have just misunderstood the problem. 
>In that case, I guess that all the issues related to the allocation of 
>intra-LSP resources are up to the LSP ingress. So again, I don't see a 
>great difference with the standard DiffServ model, and this is the reason 
>that leads me to the conclusion that probably this is not what is commonly 
>known as "aggregate TE".
>
>
>I completely agree with you that this is a departure from the current 
>model. In fact I haven't ever considered a scenario like this. This is not 
>what I am proposing. If you need different CSPF, different bandwidth 
>constraints, different restoration requirements, different preemption 
>priorities, etc. you're not really doing aggregate TE. Just set up 
>different LSP and the whole thing will become simple. We don't need 
>complex extension to include this scenario, I perfectly agree. The real 
>point was the one stated above.

Super.

>Hope it helps

Certainly does. My perception is that we now have the same view on what we 
should handle each of the 3 cases above (ie keep -1- in Reqts draft; add 
-2- to Reqts draft; don't include -3- in Reqts draft until we have explicit 
requirements from SPs). Is that right?

Thanks

Francois

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Nov 2001 10:38:36 -0800

Francois,

I think what Neil was asking is none of these. He was asking for multiple OA over E-LSP, each with their own BW, but all of them with the same preemption, affinity, etc. Basically this is what is required for VPN support. The 3rd option that you mentioned is practically very complicated, since it requires dynamic aggregation and splitting of OAs.

Yours,
-Shahram

> Sent: Tuesday, November 27, 2001 11:51 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Hi,
> At 12:51 22/11/2001 +0000, [email-masked] wrote:
> > >
> ><clip>
> In the hope of progressing towards some agreement, here's an updated 
> analysis of the thread + corresponding proposal:
> 
> There are (at least) three "ways" E-LSPs may potentially be 
> used for DS-TE :
> 
> This option is already explicitely allowed in the recently 
> posted REQTS draft.
> I suggest that this stays so, since everybody's happy with that.
> 
> This option is not allowed in recently posted REQTS draft.
> This option is necessary to:
>          - address Jim's scenario
>          - address Roberto's scenario
>          - address Neil's scenario
> This option would not create any real changes to the current 
> DS-TE model 
> and entails NO protocol extensions (ie it comes for free 
> complexity-wise)
> I suggest that the REQTS draft be changed to allow this option.
> 
> This is not allowed in recently posted REQTS draft.
> As Nabil/Sudhakar indicated, it is conceivable that some 
> Service Providers 
> might want to do that one day.
> But this require departure from the current DS-TE model and entails 
> protocol extensions.
> I suggest we keep this option on the table for discussion for 
> now but don't 
> include it in the REQTS draft until we have established that 
> a body of SPs 
> actually want to do this and how it would actually be used 
> (would we need 
> just multiple bandwidth or also multiple affinity, multiple 
> preemption,...).
> This would allow us to develop a faster simpler DSTE solution that 
> addresses what we know SPs want to do today.
> We can always add this option at any time later when deemed 
> useful and do 
> the corresponding work then.
> 
> Looking forward to hearing thoughts on this analysis/suggestion.
> 
> Francois
>

---

From: [email-masked]
Date: Tue, 27 Nov 2001 19:55:44 -0000

Thanks Shahram,

That is exactly correct.  I am postulating a potential requirement to
emulate what can be done on today's L2 VPN solutions, ie for those customers
who demand measurable and disjoint availability/QoS SLAs and/or who might
perhaps want to run their own DS regime over some leased 'LSP BW pipe'.  In
the orginal mail (snipped here) I gave an example of the difficulties one
faces if using LDP with like-DS-class merging across VPNs, ie the fact that
there is no relationship between survivability and up-state QoS treatment at
the packet level (both within the same and across different DS classes).  To
put this a different way, what I am saying is that it might be useful if we
could provide a network service at the 'LSP' level and not the 'packet'
level.  It is not clear to me yet how such VPN solutions can be provided
with MPLS....and maybe they can't, though doing XoverMPLS (eg X = FR,
ethernet, ATM) is a very similar requirement and maybe the (only possible)
answer lies within the work of the PWE3 group?

My concern is if we can't offer this type of network service on MPLS then it
seems we may well be forced to continue running parallel FR/ATM/TDM
platforms.  And I was therefore suggesting that maybe E-LSPs could possibly
offer some form of trad L2 emulation.....but maybe they can't if the focus
is purely on trying to get some unified view, and 'treatment', only at the
(DS) packet level?

regards, Neil

> From: Shahram Davari [mailto:[email-masked]]
> Sent: 27 November 2001 18:39
> To: 'Francois Le Faucheur'; [email-masked]
> Cc: [email-masked]
> I think what Neil was asking is none of these. He was asking 
> for multiple OA over E-LSP, each with their own BW, but all 
> of them with the same preemption, affinity, etc. Basically 
> this is what is required for VPN support. The 3rd option that 
> you mentioned is practically very complicated, since it 
> requires dynamic aggregation and splitting of OAs.
> 
> Yours,
> -Shahram
>

---

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Wed, 28 Nov 2001 10:42:32 +0100

Hi Francois,

please see below...

> requires dynamic aggregation and splitting of OAs.

I think that Shahram has captured the point... the possibility of having several OAs over a single E-LSP, each with their own bandwidth, but with the same preemption, affinity, etc... is something that is currently missing. I think that this option requires some (minor) protocol extension, as I tried to explain in my previous mails.

Best regards
Roberto