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

From: David Charlap <[email-masked]>
Date: Mon, 01 Apr 2002 10:40:24 -0500

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

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 02 Apr 2002 19:39:13 -0500

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

---

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

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

---

From: Nabil Seddigh <[email-masked]>
Date: Wed, 10 Apr 2002 15:47:00 -0400

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.

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

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