RE: Alternative to draft-ash-mpls-diffserv-te-class-types-00.txt ?

["Lai, Wai S (Waisum), ALSVC" <wlai@att.com>]

Sven,
   Our proposal is not to use preemption for user traffic as described
below, assuming proper network dimensioning.
   In the case of recovery under failure, whether an operator chooses to use
preemption or not is dependent on backup dimensioning, the severity of the
failure, and service objective.  For example, an operator may provision
sufficient reserve capacity to ensure that all restorable LSPs can be
recovered under any single failure event.  Such spare capacity can be shared
as described in the TEWG Design Team's "Network Hierarchy and Multilayer
Survivability."
Thanks, Wai Sum.

-----Original Message-----
From: sven.van_den_bosch@alcatel.be
[mailto:sven.van_den_bosch@alcatel.be]
Sent: Thursday, 22 November 2001 3:42 AM
To: Lai, Wai S (Waisum), ALSVC
Cc: te-wg@ops.ietf.org
Subject: RE: Alternative to
draft-ash-mpls-diffserv-te-class-types-00.txt ?




Waisum,

That's an interesting statement. Do you mean that preemption should only be
allowed for protection traffic preempting primary traffic of sufficiently
low priority?

Sven.





"Lai, Wai S (Waisum), ALSVC" <wlai@att.com> on 21/11/2001 22:53:44
                                                              
                                                              
                                                              
  To:          te-wg@ops.ietf.org                             
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           
                                                              
                                                              
                                                              
  Subject      RE: Alternative to                             
  :            draft-ash-mpls-diffserv-te-class-types-00.txt  
               ?                                              
                                                              





Under normal conditions, a network should be properly dimensioned so that
preemption is not needed while ensuring that service objectives are met.
Preemption used under overload often leads to network instability.  Hence,
preemption is not a remedy for lack of network capacity, or lack of proper
capacity planning and provisioning in the network dimensioning process.
Thanks, Wai Sum.

-----Original Message-----
From: Balazs Szviatovszki [mailto:Balazs.Szviatovszki@eth.ericsson.se]
Sent: Wednesday, November 21, 2001 10:36 AM
To: Naidu, Venkata
Cc: Lai, Wai S (Waisum), ALSVC; te-wg@ops.ietf.org
Subject: Re: Alternative to
draft-ash-mpls-diffserv-te-class-types-00.txt ?


I suppose the idea behind higher priority for control traffic is to assure
proper link-state routing operation in sever overloads. Check out this
draft:

<draft-ash-ospf-isis-congestion-control-01.txt>
"Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS
Networks"

Still, I would not dare to say that there should not be preemption among
other non-control traffic types. Recall, the draft of Jim, proposed that it
should be configurable which class-type could preempt which one
<draft-boyle-tewg-ds-nop-00.txt> :

            class voice use priority 2
         class data use priority 4
         [mpls preempt <yes|limited|map|no>]
----------> [preempt map voice over data]
         [class mute <list>]

Previous idea was that higher priority can preempt any lower priority. I
think this is the concept actually coded in many MPLS implementations.

Balazs


"Naidu, Venkata" wrote:
>
> Wai Sum:
>
>   I didn't understand why control traffic is so different?
>   Draft recommends, no preemption of LSPs and/or transport
>   links across CTs, except for control-traffic CT. (Why?)
>
>  * I mentioned my concern about CT6 because, control traffic is
>    also *some data* in IP sense. For good example, I can send
>    OSPF/RSVP Hellos in one particular CT and all other Control
>    messages (updates etc) in other CTs. Don't you agree?