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

["Iren, Sami" <Sami.Iren@marconi.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?

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