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

["Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>]

 Hi! Some of my thoughts are inline in the forwarded e-mail.

 Thanks,
 sanjay

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALCTA [mailto:gash@att.com]
> Sent: Wednesday, November 21, 2001 7:05 PM
> To: 'Choudhury, Sanjaya'
> Cc: Ash, Gerald R (Jerry), ALCTA; te-wg@ops.ietf.org
> Subject: RE: Alternative to
> draft-ash-mpls-diffserv-te-class-types-00.txt ?
> 
> 
> Sanjay,
> 
> Some comments below.
> 
> Thanks,
> Jerry Ash
> 
> > b. From the recent posting, I sense that the
> > new revision of DS-TE-REQTS will remove the 
> > Class-Type as a requirement.
> 
> Not so, CT remains in the upcoming DS-TE-REQTS draft.

 	The draft just got announced today & I haven't got a
	chance to read it as yet. Personally, I still believe
  	there exists alternatives to the ClassType based 
  	DS-TE solution --but that is probably a discussion 
  	on a separate thread.
> 
> > The DS-TE scalability issue can be handled by the some
> > of the existing DS-TE proposals (kompella,ash,boyel..)
> 
> This is a different scalability issue than addressed in the 
> current draft.
> E.g.,
> http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv
>-te-alternativ
e-02.txt and
http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-contro
>l-01.txt address concerns about scalability of IGPs and extensions of LSAs
>to communicate per-CT available bandwidth, etc. In particular, the former
>('te-alternative') draft proposes 'no further IGP extensions' to support
>CTs, and illustrates one possible technical solution which avoids further
>extensions to the IGP.  Some progress is being made now toward that 'no
>further extensions' objective.

	Let us assume that such a DS-TE alternative exists
	to handle the IGP scalability problem, for the rest
	of the discussion.

>The scalability issue discussed in the current draft
>http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-class-typ
e
>s-00.txt (e.g., see Section 3) is to reduce the dimensionality/complexity
of
>possible CTs across 4 levels of priority (DiffServ PHBs, admission-control
>priority, restoration priority, preemption priority).  The intent is to
>reduce a possibly very large number of independent CTs to 6, by combining
>the 4 priority-dimensions into a smaller number (6) of CT combinations.  We
>feel that this approach is more scalable than allowing a very large number
>of CT combinations.
	
	The draft assumes that if one supports 4 DS classes 
	and 4 preemption priorities, one has to define 4 x 4 = 16
	"Class Types". But one does not have to. Just signal
	the DS class & preemption priority (as separate TLVs).
	

>Another motivation for defining consistent CTs (also pointed out by Wai
Sum)
>is for consistent mapping of services across SP network boundaries to
>achieve end-to-end QoS.  This objective is not new, but has already been
>addressed in other standards fora for similar reasons (see the references
in
>the I-D for more information).  Services such as emergency services, for
>example, (as discussed in
>http://search.ietf.org/internet-drafts/draft-folts-ieps-white-paper-00.txt,
>http://search.ietf.org/internet-drafts/draft-baker-ieps-requirements-00.txt
,
>and
http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-911-01.txt)
>need to cross multiple SP networks with consistency and interoperability on
>priority treatment, etc. 

	If a LSP with DS class = EF, Setup Priority = 2 & Holding
	Priority = 2, is signaled, all the LSRs (in SP1 or SP2)
	are expected to treat the LSP in a similar way! I still 
	don't see a interoperability problem.

	If the main goal of the proposed draft, is to define a set
	of well-defined LSP characteristics, may be it should publish
	a set of recommended parameters [well known SLAs ?], without
	tying the solution to a particular DS-TE solution (Class Type).