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

[David Charlap <David.Charlap@marconi.com>]

Nabil Seddigh wrote:
> 
> I just finished reading the latest version of the TE solutions
> draft (draft-ietf-tewg-diff-te-proto-00.txt) and had the following
> comment.
> 
> Section 3 of the draft indicates that the CLASSTYPE object is only
> carried in the PATH msg and not the RESV msg. This would appear to
> be a significant departure from RSVP's traditional approach wrt
> bandwidth mgment. i.e. in regular RSVP-TE, the traffic params and
> service are required to be present in the RESV in the form of a
> FLOWSPEC.

Note, however, that the DIFFSERV object (from the mpls-rsvp diff-ext
draft) also works this way.

> 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