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

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Tue, 27 Nov 2001 15:10:39 -0500

During the preparation of DS-TE Requirements
<draft-ietf-tewg-diff-te-reqts-02.txt>, some issues needed further
discussion and hence were not incorporated into the text.  To facilitate
more discussion, they are listed below.

Please comment on the issues.  If there are no objections raised, we suggest
that the changes be incorporated into the next update of the above I-D.

Thanks, Wai Sum and Jerry.

Issue 1: CT definition
----------------------
In Section 3.2, Class-Type (CT) is defined as
"the set of Traffic Trunks which share the exact same Bandwidth Constraint,
or set of Bandwidth Constraints, on all links, for the purpose of Constraint
Based Routing and Admission Control."

The above definition is technically incorrect.  A given LSP instance has the
same bandwidth "on all links," but a class type cannot have the same
constraints "on all links," as exemplified by Scenario 2.  A workable
definition is provided below.

Class Type (CT): the set of Traffic Trunks crossing a link that is governed
by a specific set of bandwidth constraints and whose packets receive either
the same or closely related DiffServ forwarding treatment.  CT is used for
purposes of link bandwidth allocation, constraint based routing, and
admission control.

Issue 2: Split EF
-----------------
Also in Section 3.2, another example can be added as follows:

A network operator may split the EF traffic into two different sets of
traffic trunks, so that one set of traffic trunks is given higher priority
access to bandwidth than the other set, to satisfy some QoS objectives.  In
this case, two distinct CTs are defined: one for the EF traffic with high
priority, the other for EF traffic with normal priority.

(This example of split-EF traffic was already discussed within the author
team and no objections were raised.)

Issue 3: Max number of BW constraints
-------------------------------------
It is proposed to add the following requirement in Section 3.3.

By definition of CT, each CT is assigned either a Bandwidth Constraint, or a
set of Bandwidth Constraints.  Since there is a maximum of 8 CTs, there is
correspondingly a maximum of 8 sets of Bandwidth Constraints.  That is,
maxCT = maxBC = 8, for IGP advertisement purposes.

There is the possibility that some related CTs may be grouped together and
share a common set of bandwidth constraints.  However, such kind of grouping
can be handled and enforced purely inside a router without being advertised
by the IGP.  This is because the use of such information in the computation
of unreserved bandwidths is a local matter.  

Issue 4: Suppression of preemption
----------------------------------
It is proposed to add the following requirement in Section 3.4.

A service provider preferring not to use preemption for user traffic should
not be burdened by the overheads associated with preemption.  Thus, a
service provider should not need to set all class types to the same
preemption level to avoid using preemption.

Issue 5: Relationship between preemption and CT
-----------------------------------------------
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.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Nov 2001 15:26:19 -0800

Hi,

> 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

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Thu, 29 Nov 2001 16:03:44 -0500

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:[email-masked]]
Sent: Tuesday, November 27, 2001 6:26 PM
To: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: RE: Issues in draft-ietf-tewg-diff-te-reqts-02.txt

Hi,

> 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:

Yours,
-Shahram

ATTACHMENT 2
============

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2001 5:55 PM
To: 'Francois Le Faucheur'; [email-masked]
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:[email-masked]]
> Sent: Tuesday, November 27, 2001 10:16 AM
> To: [email-masked]
> 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

---

From: [email-masked]
Date: Fri, 30 Nov 2001 09:30:35 -0000

Wai Sum,

I largely agree with your comments and those of Shahram's....but the
fundamental point remains that there is no relationship between QoS behavior
(in the up-state) and survivability.  And the real problem is that at a
packet level the only information that is carried is the up-state QoS
behaviour.  So the only way out now is to try and map 'like' packets to an
LSP.....'like' could mean many things here, and its definition will vary
whether we are considering VPNs or aggregate public services.....and this is
what you/Shahram are starting to allude to below in the many-many, etc
possible mappings.

Some further comments/requirements:

1	When we are considering VPNs it must be possible to decouple the
survivability of a LSP from *whatever* packets it contains....it's different
for public service aggregates, though clearly we can have a voice/EF CT
mapped to different aggregate survivability levels here and that makes sense
(as you point out under the 1-2-1 case below).  So for VPNs we must have the
ability to define LSPs that have (i) survivability and (ii) effective BW
(across the aggregate, irrespective of pkt CT) attributes.  This is the only
way to properly offer VPN solutions to customers who demand such 'VPN
isolation'.  I have explained why LDP fails in this respect several times
before....merging is a blunt tool. 

2	It must be possible to disable recursive pre-emption.  Those who
want it can have it, but we have had enough experience of this behaviour in
the past to know we need the ability to turn it off.  Dumping 'extra'
traffic is fine, but once dumped it stays dumped.  And from some comments I
have seen from AT&T previously it sounds like you too share this view.

3	A pre-cursor to any rigour wrt to the above is a sound ability to
fault-manage LSPs.  So all defects need defining, with specified entry/exit
criteria and consequent actions....and where protection-switching is but one
of the possible actions as appropriate.  There is a natural ordering here
which has to be followed:
-	define defects 1st....so this is entry/exit criteria and consequent
actions;
-	then define an availability metric based on defect persistence (note
I don't say 'objectives' for the metric);
-	then define QoS metrics (and again note I don't say 'objectives' for
the metrics)....since QoS metric collection/processing is only valid when in
the available/up-state.
All these aspects are important for vendor interoperability.

BTW - For some reason I have noted that some people seem to think MPLS OAM
is complex.....and I don't actually understand this since the basic
requirement (ie a CV flow) is about as trivial as you can get.  For those
who don't want it fine, just turn it off....but please don't stop those who
do want it from having it.

regards, Neil

> From: Lai, Wai S (Waisum), ALSVC [mailto:[email-masked]]
> Sent: 29 November 2001 21:04
> To: [email-masked]
> regard is discussed in 
> <draft-ash-mpls-diffserv-te-alternative-02.txt> (July
> 2001). 
> 
> Many-to-one
> -----------