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

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 11 Apr 2002 16:00:57 +0200

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:                 [email-masked]
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 11 Apr 2002 11:45:36 -0400

Francois, 

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

Did I really miss your point? There are many objects that RSVP-TE
has introduced - many of these are carried in either the PATH
or RESV. There's no need to carry them in both msgs.
However, you are referring to DIFFSERV object in the context of
usage for CAC.

I reiterate my question: why would you use both CT and PSC for 
CAC? This whole DS-TE CT rigamarole is about using CT for CAC
otherwise, we would have used PSCs as the basis of CAC and not
signaled CT. 

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

Your point about setup & hold priorities being present only
the PATH message is a valid argument. But it's a double-edged
sword. Do we say there's precedent for keeping the info only 
in the PATH msg and not worry about further deviation from 
the original design intent of RSVP. Or do we say that the
SESSION_ATTRIB case is a small deviation and that future design
should strive to retain the original design intent.

I say this because of at least two arguments:

1. In the case of DS-TE, I still see CT as a replacement for 
   service (Ctrl Load, Guaranteed etc) in the CAC. The service 
  field is carried in the FLOWSPEC in the RESV. It is only 
   natural that its replacement be carried in the same message.

2. If in the future, it is decided for some reason to carry
   multiple traffic parameters for multiple CTs on an e-lsp,
   would you restrict these traffic parms to only the PATH msg?
   
   By restricting the CT object to the PATH message you
   preclude future design evolution. 

Regards...
Nabil

---
Best,
Nabil Seddigh
[email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 12 Apr 2002 11:05:05 +0200

Nabil and all,

I think the bottom line is:

1) RSVP-TE needed to signal a number of new attributes (priorities, 
affinities,..) which were (i) necessary for CAC and (ii) controlled by 
sender and could not be modified by receiver. They elected to signal those 
in Path only for a number of reasons we discussed (e.g. echoing them back 
in Resv brought absolutely no functionality and added opportunities for 
errors,...)

2) Thus, any RSVP-TE implementation must be capable of factoring 
information in Path message to do CAC.

3) DS-TE needs to extend RSVP-TE to signal a new attribute (CT) which is 
(i) necessary for CAC and (ii) controlled by sender and can not be modified 
by receiver.

I vote for taking the same approach as RSVP-TE did and signal this 
attribute in Path only.

What does everyone else think?

Francois

PS: RSVP extensibility comes through easy addition of objects, not making 
objects themselves super extendible. If one needs to signal additional 
things in the future those can be added as separate objects. In fact if 
these additional parameters are so functionally different to CT that they 
can be controlled by receiver, then they would much more naturally go into 
a differnet object to the CT anyway.