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

[Dimitry Haskin <dhaskin@axiowave.com>]

As a side note, I don't believe that meaningful use of CTs in the DiffServ
context is possible without LSR knowledge of relationship between PSCs and
CTs (nothing fancy about this). After all, advertising available bandwidth
in a particular TE class, is the way for an LSR to indicate what is
available at this LSR for a particular class of service.

In addition to adding text to deal with CT-PSC discrepancies, I'd also
suggest that the text specifying what CT is to be assumed if the CT object
is not present in the Path message is modify with something in line with
below:

"If the CLASSTYPE object is not present in the Path message and relationship
between PSCs and CTs is known, the LSR should assume CT that corresponds to
PSC of the LSP tunnel. If the CLASSTYPE object is not present in the Path
message and relationship between PSCs and CTs is not known, the CT 0 must be
assumed."

Hopefully it may simplify some deployments.

Dimitry

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