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

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

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.

Cheers

Francois

At 19:39 02/04/2002 -0500, Nabil Seddigh wrote:
>David,
>
>I don't quite agree with the notion that it is a lot of work
>for nothing. I feel that including the CLASSTYPE in the RESV is
>the east departure from the current RSVP approach to admission
>control.
>
>The CLASSTYPE is going to be used by RSVP-TE for CAC purposes.
>The way I see it, it is essentially a replacement of the former
>"service" field in the FLOWSPEC. Including the CLASSTYPE
>in the RESV is the easiest way of avoiding the debate on
>changing the RSVP strategy about receiver-based reservations -
>a point on which I believe you have argued in the past.
>
>In addition, there is another implication on implementation.
>Many RSVP-TE implementations CAC on the RESV (for uni-directional)
>since RSVP-TE requires that the CAC be done on the FLOWSPEC
>contents. i.e. they do the CAC based solely on the contents of
>the RESV and do not examine the PATH msg or path state blocks
>or "cached" contents.
>
>Best,
>Nabil
>
>David Charlap wrote:
> >
> > Nabil Seddigh wrote:
> > > Correspondingly, I would suggest that the CLASSTYPE object MUST be
> > > present in the RESV message as well.
> >
> > To what purpose?  So that the egress router can mirror it back?
> >
> > The only reason reservations are made by the FLOWSPEC in RSVP-TE is that
> > it is possible for an egress node to reserve different resources from
> > those requested in the Path TSPEC.  This normally only happens in
> > classical RSVP (as deefined by RFC 2205).
> >
> > If it is not possible for an egress node to reserve resources with a
> > different CLASSTYPE from what is requested, then there is no reason to
> > send the object back in the Resv message.
> >
> > Please note also that every node along the LSP will have a cached copy
> > of the CLASSTYPE object on-hand, since it's necessary to regenerate the
> > Path messages (during refreshes.)
> >
> > If you add it to the Resv message, then every node will need to cache
> > two copies - one from the Path and one from the Resv message - so that
> > it can properly generate both kinds of refreshes.  And since these will
> > be on a per-LSP (aka per-sender) basis, they will have to be stored as a
> > part of the flow descriptor.  And there will have to be appropriate
> > merge rules if the request doesn't match the reservation, and if two
> > LSPs sharing resources have different CLASSTYPES.
> >
> > These are a lot of extra rules that have to be defined before CLASSTYPE
> > can be moved into the Resv message.  Unless you can show a real need to
> > do this (i.e. cases where the Resv CLASSTYPE will differ from the Path
> > CLASSTYPE) then this is a lot of work for no good reason.
> >
> > -- David