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

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

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
nseddigh@tropicnetworks.com