RE: Issues in draft-ietf-tewg-diff-te-reqts-02.txt

[Jim Boyle <jboyle@pdnets.com>]

In your many to many, yes, in Francois' previous solutions, it did end up
being CTxPreemption values in syntax, but they were "orthogonal", so you
still only had 8 preemption levels.

By removing the explicit syntax to of {CT,P} and going to {CT} where P is
not externally explicit, you have different syntax, but semantically you
can associate a CT to multiple priorities, and cross-CT entries can have
the same preemption level.  Semantically it would be the same as only
using 8 cells in the CTxPreemption matrix, you just lose some external
visibility.

My approach had this completely arbitrary, the new protocol draft is not
so arbitrary, and has a fixed bandwidth model.  I'm interested in
scenarios which don't work with the model (russian doll model) in the
proto document.

Jim

On Thu, 29 Nov 2001, Lai, Wai S (Waisum), ALSVC wrote:

>   Here is some more discussion on the relationship between preemption and
> CT.  This started out as a response to the two emails sent by Shahram Davari
> (see Attachment 1 and Attachment 2 below).  However, I want to discuss it in
> a general setting, to trace a little bit on its development, and to explain
> the rationale for the proposal for the one-to-one correspondence for
> preemption/CT ("Issue 5: Relationship between preemption and CT" in the list
> of issues for the DS-TE Requirement <draft-ietf-tewg-diff-te-reqts-02.txt>).
>   All comments are welcome.
> Thanks, Wai Sum.
>
> ----------------
>
>   Preemption and CT may be "orthogonal" or "independent" for protocol
> design.  From a service provider's operational perspective, they are
> actually closely coupled, as network performance will be affected by the way
> they are related.  Consider the relationship between preemption (P) and
> class type (CT) as a form of P -> CT mapping.  Then, there are four
> possibilities: many-to-many, many-to-one, one-to-many, and one-to-one.
>
> Many-to-many
> ------------
>   Each CT can have many preemption levels, and each preemption level can be
> associated with more than one CT.  This is the mapping originally specified
> in the old 01 version of the DS-TE Requirements
> <draft-ietf-tewg-diff-te-reqts-01.txt> (June 2001) and the old 00 version of
> Solution <draft-lefaucheur-diff-te-proto-00.txt> (July 2001).  It leads to a
> rigid matrix structure of 4 class types x 8 preemption levels = 32
> combinations, with both within-CT preemption and cross-CT preemption.  It
> also requires complex IGP extensions for advertisement.  The problem in this
> regard is discussed in <draft-ash-mpls-diffserv-te-alternative-02.txt> (July
> 2001).
>
> Many-to-one
> -----------
>   In this case, there can be several preemption levels assigned to a single
> CT.  But each preemption level is only used by a single CT.  This is the
> approach now adopted in the new 01 version of Solution
> <draft-lefaucheur-diff-te-proto-01.txt> (November 2001).  For example, a CT
> can have a high-priority OA and a normal-priority OA combined.  To offer
> service protection, e.g., to avoid starvation of the normal-priority OA when
> preemption is allowed, different bandwidth constraints need to be specified
> for different OAs in the CT.  My feeling is that this kind of defeats the
> original purpose of CT, which is to use a single bandwidth constraint per CT
> through aggregation to improve the scalability of IGP advertisement.  (Side
> note:  This is also the case described in the "Overview and Principles of
> TE" document.)
>
> One-to-many
> -----------
>   Here, more than one CT can occupy the same preemption level.  But each CT
> is only assigned one preemption level.  This case is not really necessary,
> as it can be achieved by the one-to-one case below.
>
> One-to-one
> ----------
>   Each preemption level is assigned to one CT, and vice-versa.  By using the
> proposal in <draft-boyle-tewg-ds-nop-00.txt>, i.e., by generalizing the
> semantics of "priority" in current protocol extensions for TE, I think this
> case can achieve much of what the other cases are intended to do.  For
> example, CTs can be combined to allow better bandwidth sharing (the intent
> of the many-to-one case) within a router, as a local implementation, without
> resorting to IGP advertisement.  For the one-to-many case, it's a matter of
> defining two different priorities to be the same preemption level.  Similar
> considerations apply in the case preemption is not used.
>   Note that, because of one-to-one correspondence, each combination of {P,
> CT} effectively becomes a distinct CT.  Since there are 8 preemption levels,
> there are 8 {P, CT} combinations.
>   By using one-to-one mapping, the combination {P, CT} allows a more natural
> correspondence with the services to be provided.  For example, {P=0, CT=EF}
> corresponds to {high priority, voice}, {P=1, CT=EF} corresponds to {normal
> priority, voice}, {P=2, CT=AF} corresponds to {high priority, data}, {P=3,
> CT=AF} corresponds to {normal priority, data}.  Depending on whether {P=0}
> and {P=2} are defined by a service provider as the same preemption level or
> not, {P=0, CT=EF} and {P=2, CT=AF} may or not have higher priority over each
> other.
>
> ATTACHEMENT 1
> =============
>
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Tuesday, November 27, 2001 6:26 PM
> To: Lai, Wai S (Waisum), ALSVC; te-wg@ops.ietf.org
> Subject: RE: Issues in draft-ietf-tewg-diff-te-reqts-02.txt
>
> Hi,
>
>  -----------------------------------------------
> > In Section 3.4 it says:
> >
> > "In other words, DS-TE must offer eight(8) preemption
> > priority levels to be
> > used by an LSP, that are completely orthogonal to that any other LSP's
> > attributes (eg LSP's OA, LSP's Class Type, etc.)."
> >
> > The utility of the concept of preemption being orthogonal to CT is not
> > clear.  If each CT is assigned one preemption level only, it
> > appears that
> > such concept is no longer necessary.  A one-to-one mapping
> > between CT and
> > preemption level does not preclude the possibility that some
> > related CTs may
> > be grouped together, as discussed in Issue 3.  We propose
> > that the statement
> > of orthogonality be removed.
>
> Could you please point out to where, in this draft, it is stated that "each
> CT is assigned one preemption level only"? I think this is stated in the
> te-proto draft, which should actually follow the requirement draft not vice
> versa.
>
> Since the Orthogonality is not that clear to some people, I suggest changing
> it to "independence" as following:
>
> "In other words, DS-TE must offer eight(8) preemption priority levels
>  to be used by an LSP, that are completely independent to any
>  other  attributes of that LSP(eg LSP's OA, LSP's Class Type, etc.)"
>
> Yours,
> -Shahram
>
> ATTACHMENT 2
> ============
>
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Tuesday, 27 November 2001 5:55 PM
> To: 'Francois Le Faucheur'; te-wg@ops.ietf.org
> Subject: RE: Closer to a 'unified' ds-te approach ?
>
> Hi Francois,
>
> I think it is clear that the preemption priority of an LSP is independent of
> the CT or CTs that it is carrying. And this fact is acknowledged at the
> beginning of this document (section  2.2.1), when it states that CT and
> preemption are orthogonal. But section 2.2.2 tries to tie them together
> using a configurable mapping. This is contrary to all the previous
> assumptions and I see no reason to do so. The draft states that:
>
> "Each preemption priority is only used by a single CT".
>
> Why should we have this restriction? I think an example might make it clear:
>
> Assume that customer A is a Fortune 500 company and wants that its voice and
> data be transmitted without interruption. He wants low delay/loss for voice,
> and low loss and medium delay for data. Assume customer B, however, has a
> tight budget and is willing to accept interruption and call drops, but due
> to the nature of voice he wants low delay/loss for his voice connection,
> however he is willing to accept long delay and may be loss in his data
> connection. In summary
>
> Customer A: Voice => CT1, Preepmtion 0
>             Data  => CT2, preemption 0
> Customer B: Voice => CT1, preemption 1
>             Data  => CT3, preemption 1
>
> As you can see preemption 0 could be used by both CT1 and CT2.
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > Sent: Tuesday, November 27, 2001 10:16 AM
> > To: te-wg@ops.ietf.org
> > Subject: RE: Closer to a 'unified' ds-te approach ?
> >
> > >PS: If it doesn't get announced today I will put it on a
> > public ftp server
> > >tommorow morning European time.
> >
> > While it is percolating its way to the official IETF server,
> > draft-lefaucheur-diff-te-proto-01.txt is available from
> > ftp-eng.cisco.com/ftp/flefauch
> >
> > Cheers
> >
> > Francois
>