Subject: TE Requirements Draft - ELSP

From: Nabil Seddigh <[email-masked]>
Date: Fri, 16 Nov 2001 10:04:20 -0500

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.

Best
Nabil Seddigh
[email-masked]

---

From: David Charlap <[email-masked]>
Date: Fri, 16 Nov 2001 11:49:08 -0500

>   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

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 16 Nov 2001 18:08:20 +0100

At 10:04 16/11/2001 -0500, Nabil Seddigh wrote:
>of the Requirements draft emerges.

just in time...

>Hopefully the authors will

That's because the requirements indeed assumes that DSTE will be deployed 
using L-LSPs (or E-LSPs but on which traffic from a single OA is carried). 
soon-to-be-released-02 already has text clarifying this.
When deploying DS-TE, the SPs I spoke to wanted not only to do per-class 
admission control but also per-class routing, which normally requires use 
of L-LSPs (or E-LSPs transporting a single OA).

Is allowing operations of DS-TE over E-LSPs which transport a single OA 
what you're after (in which case it's already there)?

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?

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)?
         -  they expect the routers to do fancy things like 
dynamic/on-the-fly mapping of OAs on various LSPs : compute path for 
differnet OAs separately and then if they happen to be the same at one 
point in time push them onto the same LSP? then what happens if later on, 
one OA gets preempted and not the other one: remap one OA on another LSP 
with some other OAs?

Thanks

Francois

>[email-masked]

_________________________________________________________
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: Jim Boyle <[email-masked]>
Date: Fri, 16 Nov 2001 13:10:55 -0500 (EST)

And some packet based equipment would prefer not to use the label for
things like queue selection.

Allowing the solution to be work for E-LSPs or L-LSPs is probably the
right approach.

Jim

---

From: Jim Boyle <[email-masked]>
Date: Fri, 16 Nov 2001 13:38:18 -0500 (EST)

Francois - if your question is:

-----------------------
Would service providers wish to potentially send more than one, OA down an
E-LSP, which makes use of class-type specific routing information?
-----------------------

The answer is yes.

Picking on poor voice, one OA might be signalling traffic, one might be
VoIP data.  They might go into different queues.  They might not need to
be on seperate LSPs.  The LSP might draw upon resources of a non-default
class-type.

Hope that's not too fancy ;)

Jim

---

From: Nabil Seddigh <[email-masked]>
Date: Fri, 16 Nov 2001 14:10:18 -0500

David,

I hope you are not suggesting that the standards not talk about 
E-LSP just because some platforms cannot support it! 

The way the requirements read today, it PRECLUDES folks who
are E-LSP capable from utilizing DS-TE. 

The DS-TE requirement needs to be written in such a way that all 
options are possible:

1. It should allow use with L-LSP only,
2. It should allow use with E-LSP only
3. It should allow use with networks that deploy both L-LSP and E-LSP 

The mpls-diffserv-09 draft has just been approved as a proposed 
standard in the MPLS WG. It would appear to me that DS-TE should
be consistent with this soon-to-be-rfc. It clearly highlights
E-LSP as a viable option.

Best,
Nabil

---

From: David Charlap <[email-masked]>
Date: Fri, 16 Nov 2001 14:31:26 -0500

> E-LSP just because some platforms cannot support it!

No, of course not.

But you can not mandate that every implementation must support both
E-LSP and L-LSP.  There are hardware platforms where one or the other
can never be supported.  You can not force them to do the impossible by
inserting a paragraph into a draft, and you can not tell the vendors
that they will never be standard-compliant without implementing the
impossible.

> are E-LSP capable from utilizing DS-TE.

I haven't gotten this impression.

> 3. It should allow use with networks that deploy both L-LSP and E-LSP

If you want to allow cases 1 and 2, then you can't insert a paragraph
into the standard mandating that every implementation must support both.

-- David

---

From: Nabil Seddigh <[email-masked]>
Date: Fri, 16 Nov 2001 16:39:35 -0500

David,

I am sure my word crafting can be improved. Let me try to restate.
The basic intention is not to mandate that all of the below
must be supported. Rather it is to allow any of the below
combinations at the choice of the vendor and network operator.

Basically, it should be similar to how E-LSP and L-LSP are mandated 
in the mpls-diffserv-09 draft. i.e. if a vendor can only 
support L-LSP, they are compliant with that standard. If a vendor 
can only support E-LSP, they are also compliant. If a vendor can 
support both E-LSP and L-LSP they are also compliant. There are 
three possibilities. The TE WG should ensure that DS-TE allows 
similar possibilities.

Best,
Nabil

---

From: Nabil Seddigh <[email-masked]>
Date: Fri, 16 Nov 2001 17:46:31 -0500

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.

> 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: Francois Le Faucheur <[email-masked]>
Date: Mon, 19 Nov 2001 15:34:43 +0100

Jim,

>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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 19 Nov 2001 16:14:28 +0100

Nabil,

At 17:46 16/11/2001 -0500, Nabil Seddigh wrote:
>if they are willing to indicate their positions on the list.

Hm, how do we write a requirements document for requirements that people 
are not willing to indicate?

The document we are talking about is a "requirements" document. My 
understanding of its role is that it is here precisely to draw the boundary 
between "what seems like a good idea" and "what SPs actually want to do".

It would seem appropriate to establish that someone is actually likely to 
need this before adding this new requirement (which, as we all know, 
entails specific protocol extensions, which have been considered in the 
past during the making of ietf-mpls-diff-ext and deliberately rejected to 
due lack of clear SP requirements).
Remember that we can always add capabilities later on.

So, network administrators who are interested in deploying DS-TE :
         - do you intend to deploy DS-TE over E-LSPs with multiple OAs per 
LSP (rather than on L-LSPs or on E-LSPs with one OA per LSP) ?
         - would you use this to do per-class admission control but not do 
per-class routing (then, 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)?
         - or would you expect the routers to do fancy things like 
dynamic/on-the-fly mapping of OAs on various LSPs : compute path for 
differnet OAs separately and then if they happen to be the same at one 
point in time push them onto the same LSP? then what happens if later on, 
one OA gets preempted and not the other one: remap one OA on another LSP 
with some other OAs?

Thanks in advance for your input

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 19 Nov 2001 16:00:35 +0100

At 13:38 16/11/2001 -0500, Jim Boyle wrote:

>be on seperate LSPs.

I am still struggling to picture a whole deployment scenario:
in this example would you assume that :
         (i) a path has been computed separately for voice sig and voice 
flows (each with a separate bw requirements and potential differnet 
bandwidth constrainta/CT). In that case, I feel that it woudl be simpler to 
just put those on differnet LSPs. no?
         (ii) a path has been computed for one of the two , say voice-flows 
(based on the voice-flow bandwidth requirements and using the voice-flow 
bandwidth constraint/CT). In that case, why woudl you want to send the 
voice sig on that tunnel? why not sent it on its SPF? sending voice-sig on 
the tunnel routed for voice flow will just result in potentially sending on 
a longer-than-SPF path which you have no idea whether it is actually better 
or worse than the SPF-path considreing teh voice-sig resources (which are 
independent from teh voice flow resources). In other words, if I only do 
CSPF for one OA, I woudl personnaly be inclined to send the other OA on an 
SPF-LSP rather than on that CSPF LSP because it has just as many chances of 
making it worse than making it better. no?

Thanks

Francois

>The LSP might draw upon resources of a non-default
>class-type.
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 19 Nov 2001 16:43:24 +0100

>>of the Requirements draft emerges.

Nabil and all,
I posted draft-ietf-tewg-diff-te-reqts-02.txt today so people can start 
looking at it.
It does not reflect the comment you were refering to above, since I don't 
think we have an agreement on it. If we get to some agreement very quickly, 
we could always adjust the draft if necessary and repost.

Cheers

Francois

---

From: Jim Boyle <[email-masked]>
Date: Mon, 19 Nov 2001 11:04:33 -0500 (EST)

Francois,

Let's say I have a decent idea of the mix between Voice-Signalling and
Voice-Encapsulated, say for example that it is 1:4.  Also, say that a
router it can distinguish Voice-Signalling and Voice-Encapsulated and
Other.  I may wish to only use one LSP for Voice-Signalling and
Voice-Encapsulated to a particular destination, and another for Other.
I've reduced the number of LSPs used from 3 to 2.  If there are many
Other, then the reduction can similarly be 2:1.  As for queue
selection, etc..  As I said, the router has the ability to
differentiate the different types of traffic.  On ecapsulation to the
LSP, the appropriate "Experimental" bits are set.  These affect queue
selection along the path.

So - why you ask might one want to use only the number of LSPs absolutely
necessary - I think that's obvious - signalling scalability (yes,
potentially trading off on phb precision - oh well).  So, in this case,
two OAs become one class, which route against one class-type, one cspf.

Hope that answers your question.

Jim

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 20 Nov 2001 12:22:11 -0500

Francois,

This WG has embarked on the process of creating a Requirements doc 
prior to blessing any particular technology solutions. In principle,
this is a sound practice.

However, it appears to me, that the authors of this doc as the 
representatives of the collective views would ensure that this
doc is not just a rubber stamping of any existing technology 
proposals or specific vendor capability.

The Requirements doc must reflect input from not only SPs but
the other folks who form an integral part of the IETF standards
process: e.g vendors, academics - of course all acting as individuals.

I would think that the requirements doc would capture "What people
want to do today as well as what they "may" want to do tomorrow" -
where "tomorrow" is not some indefinite time period but a span
of finite time. e.g. 1 year, 2 years, 5 years - take your pick. 
And "may" is backed up with some reasonable example scenarios.

Thus, having a requirements doc that mandates use of DS-TE to 
L-LSPs and a single OA per E-LSP, appears to be highly restrictive.
There ARE folks who ARE interested in sending multiple OAs on a 
single LSP. Why not put this in the requirements draft!!

Then let us see if folks can come up with creative solutions
that address scalability of IGP route advertisements, can
facilitate either single OA per E-LSP or multiple OAs per E-LSP,
will allow L-LSP and do not introduce unnecessary complexity
in the protocols.

Best,
Nabil 

Francois wrote:
> The document we are talking about is a "requirements" document. 
> My understanding of its role is that it is here precisely to draw 
> the boundary between "what seems like a good idea" and "what SPs 
> actually want to do".
> [.....]
> It would seem appropriate to establish that someone is actually 
> likely to need this before adding this new requirement (which, 
> as we all know, entails specific protocol extensions, which have 
> been considered in the past during the making of 
> ietf-mpls-diff-ext and deliberately rejected to