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

[neil.2.harrison@bt.com]

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

> -----Original Message-----
> From: Lai, Wai S (Waisum), ALSVC [mailto:wlai@att.com]
> Sent: 29 November 2001 21:04
> To: te-wg@ops.ietf.org
> Subject: RE: Issues in draft-ietf-tewg-diff-te-reqts-02.txt
> 
> 
>   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
>