Subject: Diff-Serv over MPLS - Poll on "Multi E-LSP per FEC".

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 07 Sep 1999 17:11:50 +0200

Hello,

Support for "multiple E-LSPs per FEC" was identified as an open issue for
Diff-SErv over MPLS in Oslo.
I'd like to have a broad sense on opinions from the mailing list so we can
move ahead.

From recent discussions with Juha, the two main proposals we have on
the table are:

-A- "Single E-LSP per FEC":
For each FEC allow:
	* zero or one E-LSP, AND
	* zero, 1, 2,..any number of L-LSPs.
The E-LSP can support any set of 8 or less PHBs; the "PHSs" (now renamed
"PHB Scheduling Class") are not signalled at E-LSP establishment. LSRs are
locally configured so that all the E-LSPs use the same mapping
EXP-->PHS/Drop_level.
L-LSPs can support a single PHS/PHB Scheduling Class; the PHS is signalled
at L-LSP establishment. The LSR will use a configured mapping
EXP-->Drop_level which is locally configured for each PHS/PHB Scheduling
Class.
An ISP can support AF1x+AF2x+ EF on an E-LSP and support AF3x on a L-LSP.
An ISP can support AF1x+EF on an E-LSP, support AF2x on a L-LSP and support
AF3x on another L-LSP.
An ISP can NOT support AF1x+EF on an E-LSP and support AF2x+AF3x another LSP.

-B- "Multiple E-LSPs per FEC":
For each FEC allow:
	* any number of LSPs.
Each LSP can support one or multiple PHS/PHB Scheduling Class. 
At LSP set-up, one option is that no PHS/PHB Scheduling Class are signaled,
in which case the LSRs will use the Default locally configured mapping
EXP-->PHS/Drop_level (this is equivalent to an E-LSP of Proposal -A-).
At LSP set-up , one option is that a single PHS/PHB Scheduling Class is
signaled, in which case the LSR will use a configured mapping
EXP-->Drop_level which is locally configured for each PHS/PHB Scheduling
Class. (this is equivalent to an L-LSP of Proposal -A-)
At LSP set-up , one option is that multiple PHS/PHB Scheduling Classes are
signaled, in which case the LSR will use a configured mapping
EXP-->Drop_level which is locally configured for each PHS/PHB Scheduling
Class. (there is no equivalent to this is Option -A-).
An ISP can support AF1x+AF2x+ EF on an LSP and support AF3x on another LSP.
An ISP can support AF1x+EF on an LSP, support AF2x on another L-LSP and
support AF3x on yet another L-LSP.
An ISP can support AF1x+EF on an LSP and support AF2x+AF3x another LSP.

Clearly, -B- is a superset of -A- so the question is not whether one option
is functionally richer than the other. The question is whether the extra
bit of functionality is worth the extra bit of complexity.

I am a proponent of proposal -A-. 
In brief, considering that:
	 (i) when Traffic Engineering is not used, the number of PHBs actually
required beyond the 8 that a single E-LSP can support, will be limited and
can be supported via Single PHS L-LSPs 
	(ii) when Traffic Engineering is used, there will be requirements to
perform separate traffic engineering on a per PHS basis (requiring separate
bandwidth signaling and separate route computation) which require
single-PHS L-LSPs (in addition to the 8 PHBs that can be traffic engineered
jointly on the E-LSP),
I feel that option -A- is sufficient and avoids some extra signalling and
some extra corner case handling. 
eg with Proposal -B- say you configure LSRs so that AF1x uses
EXP=000/001/010, AF2x uses EXP=011/100/101, AF3x uses EXP=000/001/010 and
AF4x uses EXP=011/100/101. Then we have to define what happens when we
receive an LSP set-up requesting AF1x and AF3x (error notification). 

Juha is a proponent of -B-.
In very brief, the argument is that the extra flexibility (eg to support
AF1x+AF2x on one LSP and EF+AF3x on another LSP) is worth the extra
complexity.

I could leave with -B- but I've heard other voices leaning also towards -A-
(and a few voices towards -B-) so I'd like to see whether we can sense a
majority on the alias one way or another before deciding.

Curtis indicated in Oslo he would like to make a specific alternative
proposal. We would need to have details on this proposal urgently to assess
it against -A- or -B-.

Do you like -A-?
Do you like -B-?
Do you like ice-cream? (you don't have to answer this one)

Cheers

Francois

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Phone:  +33 4 92 96 75 64
Mobile : +33 6 07 78 69 67
Vmail:   +33 1 69 18 62 66
Fax:      +33 4 92 96 79 08
Email: [email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: "Liam Casey" <[email-masked]>
Date: Tue, 7 Sep 1999 12:13:11 -0400

Francois,

At Oslo I spoke in favour of -A- and I personally support -A- for the same
reasons that you do (viz more than adequate functionality in A, with the
extra functionality of B not worth the complexity). 
The particular complexity that I want to avoid in B relates to sharing a LS
hop between multiple E-LSP's because the different PHB's can all be
accomodated in the  experimental bits for that particular link.

Liam Casey.

	-----Original Message-----
	From:	Francois Le Faucheur [SMTP:[email-masked]]
	Sent:	September 7, 1999 11:12 AM
	To:	[email-masked]
	Cc:	[email-masked]
	Subject:	Diff-Serv over MPLS - Poll on "Multi E-LSP per FEC".

	Hello,

	Support for "multiple E-LSPs per FEC" was identified as an open
issue for
	Diff-SErv over MPLS in Oslo.
	I'd like to have a broad sense on opinions from the mailing list so
we can
	move ahead.

	-A- "Single E-LSP per FEC":
	For each FEC allow:
		* zero or one E-LSP, AND
		* zero, 1, 2,..any number of L-LSPs.
	The E-LSP can support any set of 8 or less PHBs; the "PHSs" (now
renamed
	"PHB Scheduling Class") are not signalled at E-LSP establishment.
LSRs are
	locally configured so that all the E-LSPs use the same mapping
	EXP-->PHS/Drop_level.
	L-LSPs can support a single PHS/PHB Scheduling Class; the PHS is
signalled
	at L-LSP establishment. The LSR will use a configured mapping
	EXP-->Drop_level which is locally configured for each PHS/PHB
Scheduling
	Class.
	An ISP can support AF1x+AF2x+ EF on an E-LSP and support AF3x on a
L-LSP.
	An ISP can support AF1x+EF on an E-LSP, support AF2x on a L-LSP and
support
	AF3x on another L-LSP.
	An ISP can NOT support AF1x+EF on an E-LSP and support AF2x+AF3x
another LSP.

	-B- "Multiple E-LSPs per FEC":
	For each FEC allow:
		* any number of LSPs.
	Each LSP can support one or multiple PHS/PHB Scheduling Class. 
	At LSP set-up, one option is that no PHS/PHB Scheduling Class are
signaled,
	in which case the LSRs will use the Default locally configured
mapping
	EXP-->PHS/Drop_level (this is equivalent to an E-LSP of Proposal
-A-).
	At LSP set-up , one option is that a single PHS/PHB Scheduling Class
is
	signaled, in which case the LSR will use a configured mapping
	EXP-->Drop_level which is locally configured for each PHS/PHB
Scheduling
	Class. (this is equivalent to an L-LSP of Proposal -A-)
	At LSP set-up , one option is that multiple PHS/PHB Scheduling
Classes are
	signaled, in which case the LSR will use a configured mapping
	EXP-->Drop_level which is locally configured for each PHS/PHB
Scheduling
	Class. (there is no equivalent to this is Option -A-).
	An ISP can support AF1x+AF2x+ EF on an LSP and support AF3x on
another LSP.
	An ISP can support AF1x+EF on an LSP, support AF2x on another L-LSP
and
	support AF3x on yet another L-LSP.
	An ISP can support AF1x+EF on an LSP and support AF2x+AF3x another
LSP.

	Clearly, -B- is a superset of -A- so the question is not whether one
option
	is functionally richer than the other. The question is whether the
extra
	bit of functionality is worth the extra bit of complexity.

	I am a proponent of proposal -A-. 
	In brief, considering that:
		 (i) when Traffic Engineering is not used, the number of
PHBs actually
	required beyond the 8 that a single E-LSP can support, will be
limited and
	can be supported via Single PHS L-LSPs 
		(ii) when Traffic Engineering is used, there will be
requirements to
	perform separate traffic engineering on a per PHS basis (requiring
separate
	bandwidth signaling and separate route computation) which require
	single-PHS L-LSPs (in addition to the 8 PHBs that can be traffic
engineered
	jointly on the E-LSP),
	I feel that option -A- is sufficient and avoids some extra
signalling and
	some extra corner case handling. 
	eg with Proposal -B- say you configure LSRs so that AF1x uses
	EXP=000/001/010, AF2x uses EXP=011/100/101, AF3x uses
EXP=000/001/010 and
	AF4x uses EXP=011/100/101. Then we have to define what happens when
we
	receive an LSP set-up requesting AF1x and AF3x (error notification).

	Juha is a proponent of -B-.
	In very brief, the argument is that the extra flexibility (eg to
support
	AF1x+AF2x on one LSP and EF+AF3x on another LSP) is worth the extra
	complexity.

	I could leave with -B- but I've heard other voices leaning also
towards -A-
	(and a few voices towards -B-) so I'd like to see whether we can
sense a
	majority on the alias one way or another before deciding.

	Curtis indicated in Oslo he would like to make a specific
alternative
	proposal. We would need to have details on this proposal urgently to
assess
	it against -A- or -B-.

	Do you like -A-?
	Do you like -B-?

	Cheers

	Francois

	Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
France

---

From: Shahram Davari <[email-masked]>
Date: Tue, 7 Sep 1999 15:46:22 -0700

Hi Francois,

In case B (multiple E-LSP), the last options is mentioned:

"one option is that multiple PHS/PHB Scheduling Classes are signaled, in
which case the LSR will use a configured mapping EXP-->Drop_level which is
locally configured for each PHS/PHB Scheduling Class. (there is no
equivalent to this is Option -A-)."

Didn't you mean EXP--> PHS+Drop_level? Because when you signal multiple
PHSs, they are going to be encoded in the EXP field together with their
Drop_level.

One point regarding the complexity example that you mentioned:

"eg with Proposal -B- say you configure LSRs so that AF1x uses
EXP=000/001/010, AF2x uses EXP=011/100/101, AF3x uses EXP=000/001/010 and
AF4x uses EXP=011/100/101. Then we have to define what happens when we
receive an LSP set-up requesting AF1x and AF3x (error notification)."

It seems that the only reasonable method to resolve this problem in this
case is to use Label+EXP field for LSP identification. Therefore the
multiple E-LSP case is actually L-E-LSP. 

I like the idea of minimum signaling in Diffserv context. After all the WG
effort has always been toward configuration rather than signaling. Besides I
think you can accommodate almost any situation in method "A" and I don't see
any extra benefit in method "B". So I am in favor of method "A".

However, if the majority prefers case "B" I strongly recommend still to have
a non-signaling mode as default.

Regards,

                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
          Shahram Davari
          Systems Engineer, Product Research
          PMC-Sierra Inc. 
          105-8555 Baxter Place
          Burnaby, BC V5A 4V7, Canada
          Phone: +1 (604) 415-6000, Ext. 2428
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 8:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: Diff-Serv over MPLS - Poll on "Multi E-LSP per FEC".

Hello,

An ISP can NOT support AF1x+EF on an E-LSP and support AF2x+AF3x another
LSP.

	 (i) when Traffic Engineering is not used, the number of PHBs
actually

Do you like -A-?
Do you like -B-?

Cheers

Francois