[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment on draft-ietf-tewg-diff-te-proto-00.txt
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.
At 11:45 11/04/2002 -0400, Nabil Seddigh wrote:
>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
_________________________________________________________
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: flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410 Biot - Sophia Antipolis
FRANCE
_________________________________________________________