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

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 08 Apr 2002 15:22:05 +0200

Sami,

At 10:09 29/03/2002 -0500, Iren, Sami wrote:
>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?

Remember that the solution must work with all types of LSPs including 
"E-LSPs with preconfigured EXP<-->PHB Mapping" for which no PSC is 
signaled. So we do need CT signaling. Our solution simply handles CT and 
CT-signaling independently of the LSP type.

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

Again, this relates to DS-TE use with E-LSPs for which no PSC is signaled. 
For those, you can do something useful using the only info you have which 
is the CT. If you use L-LSPs only and have PSC signaled, then you are free 
to use PSC only.

Do you agree with that?

Current text basically says:
         - you may optionnaly use CT
         - you may use PSC when it happens to be signaled.
So I believe current text is trying to say the right thing. No?

>Furthermore, CT will not be good enough in some cases for this purpose
>anyways.

agreed, but in some cases that's all you have.

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

This is coming form a long discussion with Shai relating to the case where 
we transport multiple OAs per E-LSP. One rationale for allowing that case 
is where you can assume consistent relative proportion of traffic across 
the OAs. In brief, Shai made the point that to do some reasonable bandwidth 
accounting you also needed to distribute the OAs in the same way on all the 
LSPs. Please see archive for detailed thread. The text is trying to capture 
that point.

Cheers

Francois

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

_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 19 98 50 90
Fax:                   +33 4 97 23 26 26
Email:                 [email-masked]
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 08 Apr 2002 15:36:01 +0200

Dimitry,

At 11:22 29/03/2002 -0500, Dimitry Haskin wrote:
>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."

This does not work for E-LSPs (with preconfigured EXP<-->PHB Mapping) since 
there is no signaled PSC.
Current solution works for both L-LSPs and E-LSPs as well as mix of those.
We thought that would "simplify some deployments" 8^). No?

Francois

>Hopefully it may simplify some deployments.
>
>Dimitry
>