[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment on draft-ietf-tewg-diff-te-proto-00.txt
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
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.
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