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

From: "Iren, Sami" <[email-masked]>
Date: Fri, 29 Mar 2002 10:09:10 -0500

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:[email-masked]]
> Sent: Tuesday, March 19, 2002 11:30 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> 
>

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 29 Mar 2002 11:22:29 -0500

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

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 29 Mar 2002 11:49:43 -0500

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