Subject: Re: could we agree on this ? Fwd: RE: TE Requirements Draft - ELSP

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 03 Dec 2001 15:16:37 +0100

At 11:26 30/11/2001 -0500, Nabil Seddigh wrote:
>Francois,
>
>One key item of note. In an earlier email, you had stated that
>Nabil/Sudhakar asked for option (3). This is not quite accurate.

that's why I updated the breakdown in 4 options.

>We had argued for the ability to signal BW for multiple OAs on
>a single LSP. In addition, we argued for the ability to advertise
>BW for multiple OAs (classes) in the IGP. How the CSPF is done
>is a proprietary matter. It is not governed by the standards!

We're not talking about standardising CSPF.

Cheers
Francois

>Best,
>Nabil
>
>
>
> >
> > 3) using E-LSPs with traffic from multiple OAs each with their own SPF
> > ======================================================================
> > This is the option I proposed to keep out of the Reqts draft for now. This
> > is also the option you described above as "practically very complicated,
> > since it requires dynamic aggregation and splitting of OAs."  Can we agree
> > to keep this out of REQTS draft?
> >
> > 2) using E-LSPs with traffic from multiple OAs but using single CSPF
> > =====================================================================
> > I think we actually need to break this up in 2 cases:
> >
> > 2a) using E-LSPs with traffic from multiple OAs but using single CSPF and
> > SINGLE bandwidth
> > =============================================

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 03 Dec 2001 15:14:24 +0100

Nabil and all,

>In this regard, I would suggest that your options are actually:
>
>   i) Using E-LSPs with traffic from a single OA
>  ii) Using E-LSPs with traffic from multiple OAs with single BW
>  iii) Using E-LSPs with traffic from multiple OAs with multiple BW
>   iv) Using L-LSP
>
>There seems to be prior agreement that options (i) and (iv) are
>required.

So let's record that we can agree on the proposal to update REQTS draft to 
allow support for (i), unless we hear other views.
(iv) is already there.

>The open questions seem to be whether or not (ii)

We need to be more specific on (ii). I believe we have established that:
         - (ii) can be supported without any protocol extensions. Whether 
we put it in the REQTS document or not, it will not affect the DSTE 
protocol extensions and it can be implemented in a head-end LSR. As I said 
earlier, it comes for free from a "protocol" viewpoint
         - a valid scenario has been described that would make use of (ii).
Excluding it would be a useless restrictions. Would it not?
Can you agree to the proposal of updating REQTS to allow support of (ii).

>and (iii) are required.

Your breakdown misses part of the discussion we've had which is precisely 
while I splitted that case earlier. Bandwidth is just one of the Traffic 
Trunk attributes. Based on the thread I think it is useful to split (iii) into:
         (iiia) Using E-LSPs with traffic from multiple OAs with multiple 
BW and single value for all other attributes (preemption, CT, affinity...)
         (iiib) Using E-LSPs with traffic from multiple OAs with multiple 
BW and multiple values for all other attributes (preemption, CT,...)

Those two cases do require different protocol extensions (eg signal 
multiple preemtion/CT/affinity).

I thought we may be able to agree on (iiib). For example , I understand 
that while Sharham felt (iiia) should be added he agreed (iiib) should not.
So again, leaving aside (iiia) for now, can you agree that (iiib) shoudl 
not specifically be added to REQTS draft for now until SPs have expressed 
the requirement for it?

Cheers

Francois

>Kind Regards

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 03 Dec 2001 11:00:18 -0500

Francois,

> Can you agree to the proposal of updating REQTS to allow support of (ii). 

Agreed. The DS-TE solutions should allow for option (ii).

> while I splitted that case earlier. 

The reason I had issues with your earlier breakdown was that it 
got into the CSPF mechanism employed and that is proprietary.
IMHO, the lines below capture the two sub-choices better.

> BW and multiple values for all other attributes (preemption, CT,...)

Yes, indeed, I believe we have been arguing for inclusion of 
(iiia) all along. 

Best,
Nabil

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 03 Dec 2001 11:03:35 -0500

> We're not talking about standardising CSPF.

Not in so many words. 

However, the options you listed had implicit
assumptions about how the constrained path computation was 
carried out. e.g. multiple CSPF, single CSPF, SPF etc. I think 
the way you have restated the options in your previous email
(without mention of CSPF scheme) is better.

Regards
Nabil Seddigh

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 03 Dec 2001 17:28:15 +0100

Nabil,

>Agreed. The DS-TE solutions should allow for option (ii).

great.

>Yes, indeed, I believe we have been arguing for inclusion of

We understand you're after (iiia). My question was about (iiib). I think 
your words above implyi you're agreeing with the proposal for (iiib), but 
can you be explicit about it. Let me repeat the question:
"So again, leaving aside (iiia) for now, can you agree that (iiib) should 
not specifically be added to REQTS draft for now until SPs have expressed 
the requirement for it?"

thanks

Francois

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 03 Dec 2001 12:13:13 -0500

Sorry, I guess I wasn't explicit enough.

Yes, (iiib) should not be specifically added until someone expresses
an interest in it. 

Best,
Nabil Seddigh

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Mon, 3 Dec 2001 12:52:22 -0500

Francois,

I am not sure where the requirement for (iii b) came from.
It is been always (iii a). Definitely (iii b) should be out.

-Sudhakar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Francois Le Faucheur
> Sent: Monday, December 03, 2001 9:14 AM
> To: Nabil Seddigh
> Cc: Francois Le Faucheur; [email-masked];
> [email-masked]
> Subject: Re: could we agree on this ? Fwd: RE: TE Requirements Draft -
> ELSP
>
>
> Nabil and all,
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 04 Dec 2001 16:10:17 +0100

Nabil and Shahram,

The one option we disagree on is:
(iiia): Using E-LSPs with traffic from multiple OAs with multiple BW and 
single value for all other attributes (preemption, CT, affinity...).

I recommend we do NOT add support for (iiia) in DSTE-REQTs at this stage. 
Here is why:
         1) (iiia) brings absolutely no new functionality
         2) (iiia) may only be used in limited situations
         3) the only benefit is debatable in practical networks
         4) it requires protocol extensions and options , which we already 
have a lot of
         5) these protocol extensions have been explicitely discussed and 
rejected earlier
         6) we still don't know whether there are SPs which may really 
benefit from this

More details on each point:

1) this brings absolutely NO new functionality: absolutely anything you can 
do with (iiia) can be done with L-LSPs already. There has been some 
statements along the lines of "(iiia) gives you better restoration this and 
that"; this is absolutely incorrect since you can achieve anything you can 
do with (iiia) (and more) using L-LSPs. So I'd like to make it 100% clear 
that (iiia) is purely about doing in a different way something which can 
already be done .

2) (iiia) may only be used in few cases. (iiia) could only be used to group 
OAs which have different bandwidth requirements BUT have the same affinity 
requirement, have the same preemption requirement, have the same protection 
requirement and have the same Class-Type requirements.
As an interesting example, let's use our Voice_signaling and voice_payload 
example which Nabil also mentions in his draft. Because Voice_payload and 
Voice_signaling have very differnet QoS requirements, I would expect those 
to be typically configured by SP under different Class-Types. This means 
that (iiia) could actually not be used to transport them on a single E-LSP. 
They may also have different preemption priorities because SP may want to 
make sure voice_payload is routed as close as possible to its SPF (because 
of its delay/jitter requirements) while voice_sig may afford to be routed a 
little further away from its SPF. Again, this would mean (iiia) could not 
be used.
So the bottom line is that the SP would sometimes happen to be able to 
group some OAs together with (iiia) but often won't be able to.

3) The only arguable benefit is debatable in practical networks. First, as 
Joel pointed out, it must be made clear that most of the scalability 
aspects are actually equivalent between (iiia) and using L-LSPs. In 
particular on the operational front, they both require the SP to manage 
things at the granularity of the OA (ie monitor/compute/configure bandwidth 
requirements on a per OA basis). I believe this is often the dominant 
scalability burden.
So the only arguable benefit is you may have less LSPs.
But considering the previous point you might be able to group some OAs and 
probably won't  be able to group others so the ballpark maybe that, if 
you're lucky, (iiia) will result in twice less LSPs. I am not sure a factor 
2 in pure number of LSPs (when you have to manage thing at the OA level 
anyway) is a make or break element.

4) (iiia) requires protocol extensions. Although we've tried to resist 
adding options in the "Diff-Serv over MPLS" spec, there are already (too?) 
many options. In my opinion, adding yet another option (to do differently 
what we can already do) is simply going one little step further towards 
making MPLS too complicated. Not a big step, but a step in the wrong direction.

5) Signaling multiple bandwidth is an option that has been considered in 
the making of "Diff-Serv over MPLS" and explicitely excluded as offering 
too little gain over the other options which can already cover the 
requirement and not having clear SP requirements behind. This has been 
validated and revalidated and rerevalidated through the multiple last calls 
on the spec in the MPLS WG and Diff-Serv WG, I don't see any significant 
information justifying reversing that decision.

6) We still don't know whether there are life SPs which expect to be in the 
precise situation where (iiia) would help i.e:
         - OAs have differnet bandwidth constraints but same 
preemption/affinity/CT/restoration
         - a factor of about 2 in number of LSPs makes a significant 
difference (when operations is done on a per-OA basis anyway).

Cheers

Francois

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Wed, 5 Dec 2001 22:53:28 -0500

Francois,

>          1) (iiia) brings absolutely no new functionality

No, (iii a) brings absolute new functionality of transporting
together traffic belonging to different classes of a service
of a customer on the same LSP that is not defined in the DS-TE
requirements documents. It is definitely not the same way that
you can do with other things.

> used to group OAs which have different bandwidth requirements
> BUT have the same affinity requirement, have the same preemption
> requirement, have the same protection requirement and have the
> same Class-Type requirements.
>

Class type should not be in this picture. No one ever said
all of the OAs will be mapped to the same CT. That would be
wrong. We were only saying about same pre-emption attributes.
CT is not brought into this picture as this is outside the
scope of mechanism and not a necessary means to do DS-TE.
SPs may want to do classes instead of CT. If it is a absolute
must, then along with OA bandwidth parameters, you would also
indicate it's class type, in a very simple way by adding two
bits. This would complete the CT functionality.

>          3) the only benefit is debatable in practical networks

I don't think so. Path protection is one of the important
aspects of MPLS. One would want to guarantee faster restoration
times at the path level on an end-to-end basis (and to provide
availability SLAs). Carrying all OAs of a customer on a single
E-LSP would bring such faster restoration times besides reducing
the LSP scalability issue for the whole customer traffic.
Therefore the benefit is not just LSP scalability issue but
is also tied to provide better availability SLAs in a
multi-OA case.

>          4) it requires protocol extensions and options , which
> we already have a lot of

You need protocol extensions that are useful and this one is such.
This is a completely missed out functionality. In order to do
E-LSP and L-LSP co-existence meaningfully, these "minor" protocol
extensions are needed.

>          5) these protocol extensions have been explicitely discussed and

May be the MPLS application aspects might have changed from
when you considered last. Even the group of people who are looking
at this problem now could be different.

>          6) we still don't know whether there are SPs which may really

I thought some of the other posts are from SPs who are arguing the
benefits of this.

-Sudhakar

> Sent: Tuesday, December 04, 2001 10:10 AM
> To: [email-masked]
> Subject: What we disagree on RE: TE Requirements Draft-ELSP
>
>
> Nabil and Shahram,
>

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 06 Dec 2001 11:42:59 -0500

Francois,

What is being proposed regarding multiple OAs on an E-LSP are
protocol extensions that are OPTIONAL. If certain folks religiously
believe that L-LSPs or E-LSPs with a single class are the way
to go, they do not have to do this nor do the protocols have
to signal or advertise any extra information beyond what is 
mandated in the DS-TE REQ today. 

However, you shouldn't prevent others who wish to use this feature
from doing so - assuming there are enough folks who express interest.
The protocol extensions are OPTIONAL. The IETF has words like
SHOULD and MUST for precisely this purpose.

In the most recent discussion on this list, I think you have heard
from a number of people. Seems to me that of the people who have
emailed the list, there are more in favour than against. 

Best,
Nabil

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 06 Dec 2001 12:04:08 -0500

Francois,

> 1) this brings absolutely NO new functionality: absolutely anything 
> you can do with (iiia) can be done with L-LSPs already. 

So should we mandate that the SPs use only L-LSPs?

> 2) (iiia) may only be used in few cases. (iiia) could only be used 
> to group OAs which have different bandwidth requirements BUT have 
> the same affinity requirement, have the same preemption requirement, 
> have the same protection requirement 

IS this really only a few cases?
I wonder how many SPs today have a network where LSPs keep getting 
bumped and rerouted due to pre-emption when new LSPs are setup?

I suspect most network operators would rather have a more stable
network - one where most LSPs are not continually pre-empted due
to a large number of pre-emption priorities. Thus, the argument
for using a single pre-emption attribute for the E-LSP with 
multiple BW.

I understand that there are various folks interested in using
the pre-emption attributes primarily for the case where links go
down etc.

> 3) In particular on the operational front, they both require 
> the SP to manage things at the granularity of the OA 
> (ie monitor/compute/configure bandwidth requirements on a 
> per OA basis). I believe this is often the dominant scalability 
> burden.

It would be a shame to limit the protocol extensions and DS-TE
framework because of limitations in vendor equipment path 
computation schemes. If this argument was used, OSPF would never
have been deployed.
 
Best,
Nabil

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 11 Dec 2001 07:20:17 +0100

Nabil,

>So should we mandate that the SPs use only L-LSPs?

I thought my recommendation was clear by now:
         - allow (i)
         - allow (ii)
         - allow (iv) aka L-LSP

You can achieve all teh functional goals with this set of options.

>for using a single pre-emption attribute for the E-LSP with

You have made similar claims about somehow (iiia) bringing some stability 
benefits which make no technical sense to me.
Is it clear to you that if you put the two OAs on differnet L-LSPs you can 
give them the same preemption priority which results in NO preemption among 
them.

>computation schemes. If this argument was used, OSPF would never

Who talked about any vendor equipment limitations?
I don't see the connection between my statement above and your response.
The only valid technical argument in favor of (iiia) is that it reduces the 
number of LSPs. This has been initially presented as an improvement in 
scalability . Above, I am clarifying that it helps only in one aspects of 
scalability which is pure number of LSPs but that from an SP point of view 
a big part of the DSTE scalability burden is to do measurement on a per OA 
basis and decide per-OA bandwidth based on that, configure those on a 
per-OA basis etc ... this is the more important aspect of scalability , and 
option (iiia) makes no difference on that aspects compared to option (iv) 
[aka L-LSPs].
So in brief, I am saying that (iiia) woudl only help on the less important 
aspect of operational scalability (from an SP perspective). BTW, in a 
separate point, I was also explaining why I think that it woudln't help 
that much anyway , even on that less important point because it couldn't be 
used for most OAs (eg because they may have different CTs)

cheers

Nabil.

>Nabil

My Mobile Phone number has changed to +33 (0)6 19 98 50 90
_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 19 98 50 90
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
_________________________________________________________