[Tsvwg] RE: Comments on draft-lefaucheur-rsvp-dste-01

Hi Rurick,

Thanks for your comments. See below:

________________________________

	From: Rurick Kellermann [mailto:rurick@nortel.com] 
	Sent: lundi 7 mars 2005 22:15
	To: Francois Le Faucheur (flefauch)
	Subject: Comments on draft-lefaucheur-rsvp-dste-01

	Hi Francois, 

	First things first, I think the draft is very concise in what it
intends to describe. Given the nature of its contents, this is an
accomplishment in itself. Kudos to the authors. 

	Two comments - 

	1- General: 

	IMO the introduction section would be better off by having a
separate sub-section dedicated to the differences with RSVP-TUN
(RFC2746). 
	[FLF:] So there is a separate paragraph about RSVP-TUN. You are
just suggesting this should be made a subsection instead?

	2- Section 3.2 - Receipt of E2E path message 

	First time the E2E path message is mentioned in the draft. 
	[FLF:] We reused the "E2E" (aka end-to-end) terminology from
RFC3175, but I guess we haven't made that clear nor re-included a proper
definition. We can add that. In simple terms, E2E referes to
reservations (i) whose sender is upstream of the Aggregator , (ii) whose
destination is downstream of the Deaggregtor and (iii) who are to be
aggregated.

	houldn't it be described that several hosts have previously sent
RESV messages to the sender host(s) and as a result the de-aggregator is
bundling the individual "PATHS" messages into an E2E path message? Also,
it might be useful to add an explanation that the standard RSVP (and TE)
procedure applies to the individual RESV messages (i.e. no aggregation).

	As a separate comment,did you guys consider the case where there
might be several aggregators that could benefit of a hierarchical-type
of aggregation in itself? (i.e. E2E Path1, E2EPath2 E2EPath3, etc., as
long as they have the same destination).  Maybe is adding un-necessary
complexity to the protocol and it's easier to deal with individual E2E
paths...
	[FLF:] This is actually already allowed because:
	    - the TE tunnels themselves can be suject to aggregation (as
per "LSP Hiererachy").
	    - The E2E reservations aggregated over TE tunnels can be
pre-aggregated reservations (ie they can be RFC3175 type of
reservations). This is discussed in section 5.

	Cheers

	Francois

	Rurick K. 