Re: Comment on draft-ietf-tewg-diff-te-proto-00.txt

[Francois Le Faucheur <flefauch@cisco.com>]

Nabil,

At 15:47 10/04/2002 -0400, Nabil Seddigh wrote:
>Francois,
>
>Can you give me a scenario where both DIFFSERV and CT objects will
>be used for CAC? I thought you would use one or the other.
>
>In E-LSPs, the purpose of the DIFFSERV object has nothing to do
>with CAC and resource reservation. It is an optional object
>which gives you the mapping between EXP->PHBID. In many cases,
>on E-LSPs, nodes may simply maintain their pre-configured
>mapping which are common for the entire node.

You missed my point.
My point is that to perform TE CAC for an L-LSP, you would want to take 
into account the L-LSP PSC which is included in the DIFFSERV object, which 
in turn is available in the Path message only.

But anyway there are even more blatant cases in existing TE where CAC has 
to take into account information which is ONLY available in the Path 
message: I think you would agree that Holding priority, Setup priority and 
affinities have to be taken into account by CAC. Well, I believe those are 
encoded in the SESSION ATTRIBUTE object which is only in the Path message.

Regardless of DS-TE, I'm afraid your RSVP implementation may still need 
enhancements even for regular TE.

Francois

>Not putting the CT in the RESV is a significant departure from
>the way that reservations are treated in RSVP. If we were designing
>a protocol from scratch this may not be an issue. However, we
>are not - there are clear principles upon which RSVP was built.
>
>I would say that TE should not undertake such a radical departure
>unless the benefits were significant. I don't see that this is the
>case.
>
>Best,
>Nabil
>
>
> > I support David's analysis:
> >
> > - there is no reason to resignal CT in RESV (apart from creating
> >   additional error scenarios) since it cannot be changed.
> > - DIFFSERV object already works this way (for the same reason)
> >
> > In addition, because the DIFFSERV object already works that way,
> > it seems to me that implementations have to be able to factor
> > in information in the Path message anyway (eg PSC) to be able
> > to do proper CAC.


_________________________________________________________
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:                 flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________