RE: Additional Error Handling scenario for draft-ietf-tewg-diff-t e-proto-

[Dimitry Haskin <dhaskin@axiowave.com>]

> 
> Francois:
> 
> My understanding is that we are assuming a consistent PSC to CT
> mapping throughout the domain. If this is correct, then why do we
> need to signal the CT? LSRs can figure out what the CT is by just
> looking at the PSCs which is already signalled and part of the
> DIFFSERV object in RSVP-TE and CR-LDP. We do not need the CLASSTYPE
> object. Am I missing something else here?
>
Potentially a PSC could be partitioned in multiple CTs (e.g. to allow to
limit some LSPs to a portion of resources of a given PSC). But relaxing the
text that deal with the absence of CT object (see my other message), would
probably remove the need to signal CT in many deployments. 

> Another issue is related with the dynamic adjustment of the 
> PSC scheduler
> weights based on the signalled CT. I really believe this should not be
> part of the DS-TE solution. Dynamic adjustment of the 
> scheduler weights
> should be based on the signalled PSC (or PSCs if E-LSPs are 
> used) not CT.
> Our aim should be to address the problems of DS traffic 
> engineering not
> traffic management.
> Furthermore, CT will not be good enough in some cases for this purpose
> anyways.
> Take the example you gave in Section 3.2 of the requirements 
> draft where
> AF1 and AF2 are mapped to the same CT say x. In this case, 
> when an LSP is
> signalled with classtype x, which scheduler weight are we 
> going to adjust
> AF1 or AF2? 
> 
> Regarding E-LSP support, I was not clear about a sentence in the last
> paragraph of Section 3.5 of the requirements draft:
> ".... In that case, it is also assumed that OAs are grouped 
> together in a
>  consistent manner throughout the DS-TE domain (e.g., if OA1 
> and OA2 are
>  transported together on an E-LSP, then there will not be any L-LSP
>  transporting OA1 or OA2 on its own and ...."
> Why is this limitation?
> 
> Regards,
> --Sami
> 
> 
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > Sent: Tuesday, March 19, 2002 11:30 AM
> > To: te-wg@ops.ietf.org
> > Cc: flefauch@europe.cisco.com
> > Subject: Additional Error Handling scenario for
> > draft-ietf-tewg-diff-te-proto-
> > 
> > 
> > Hi,
> > 
> > I got a similar comment from two people about a potential 
> > inconsistency 
> > between CT and PSC which could arise in some cases.
> > 
> > To address that, we could add some text explaining that in 
> > the case where:
> > 	- L-LSPs are used
> > 	- an intermediate LSR happens to have some local 
> > knowledge of relationship 
> > between PSCs and CTs (e.g. because the LSR implements some 
> > fancy scheduler 
> > weights adjustments)
> > 	- the PSC and CT signaled are inconsitent with the 
> > local knowledge of 
> > PSC/CT relationbship,
> > then the LSR must reject the setup and send Error Message "xyz".
> > 
> > Thoughts/comments/concerns about that?
> > 
> > Cheers
> > 
> > Francois
> > 
> > 
>