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

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 13 Sep 1999 17:46:19 +0200

Sharham,

At 15:46 07/09/1999 -0700, Shahram Davari wrote:
>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.
>

You're correct: it is a EXP-->PHS/Drop mapping. But it is configured on a
per (signaled) PHS basis.
In other words, it is not a fixed mapping like an E-LSP: there is one such
mapping configured for each signaled PHS: for instance you may configure:
	- "EXP=000/001/010 --> AF1x and Drop1/drop2/drop3" to be used when AF1x is
signaled on the LSP, and 
	- "EXP=000/001/010 --> AF3x and Drop1/drop2/drop3" to be used when AF3x is
signaled on the LSP.
Thanks for the clarification.

Francois

>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,
>
>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
>_________________________________________________________________
> 

_________________________________________________________________
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: "Scott W Brim" <[email-masked]>
Date: Fri, 24 Sep 1999 23:20:54 -0500

One thing which made me lean toward -B-, which you didn't mention in your 
comparison, was that in your model there is "implicit signaling", i.e. if 
some kind of signaling is absent that implies the non-signaler will 
behave in a certain way.  I think that only came out in the discussion at 
the last meeting.  Do you remember what that issue was?  I still don't 
like making anything implicit in a system as complex as this, but since I 
don't remember what it was you were making implicit I don't know how 
strongly I feel.  What was that issue?

Thanks .. Scott
--
Scott Brim  <[email-masked]>  +1.607.273.5472  +1.607.280.4000

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 27 Sep 1999 11:30:07 +0200

Scott,

>behave in a certain way.  I think that only came out in the discussion at 

I am not sure if this is what you are refering to, but what we are
proposing is that if "PHB Scheduling Class" (PSC) information is absent
from LSP set-up signaling, this LSP is to be estabished as an E-LSP. This
was described in the Internet Draft.

>like making anything implicit in a system as complex as this, but since I 

Again, with E-LSPs, the idea is to operate as closely as possible to the
Diff-Serv model in non-MPLS: 
	- in non-MPLS, you configure Diff-Serv boxes to apply a given PHB to a
given DSCP. You don't signal anything about DSCP/PHB mapping before data
transfer.
	- in MPLS with E-LSP, you configure Diff-SErv MPLS boxes to apply a given
PHB to a given EXP. You don't signal anything about EXP/PHB mapping before
data transfer.

>strongly I feel.  What was that issue?

Let us know if the above is what you had in mind, and how strongly you feel
now.

Cheers

Francois