Subject: Some more questions

From: [email-masked]
Date: Fri, 5 Nov 1999 15:17:09 -0800

Lou,

I am still struggling to understand your refresh-reduct I-D.
(Since I see no other issues raised on the list, I must conclude
that I am the only one who doesn't get it.)  In any case, since
I have not a shred of pride, let me ask you the following:

1. Section 2.3: "RSVP Bundle messages MUST not be used if ...
	changes in next hops cannot be identified via routing"

	Precisely why? (There seems to be some logic omitted here...)

2. Section 3.4: "Message_ID objects can be used in both a Bundle
	message and its sub-messages".

	What is a Message_ID object in a Bundle message used for?
	(BTW, your BNF for a Bundle message does not include
	a Message_ID object).

3. Section 3.5: "Implementations SHOULD include MESSAGE_ID_ACK
	and MESSAGE_ID_NACK objects in standard RSVP
	messages when possible."

	There is no alternative for NACK objects, is there?
	Is it always preferable to send an ACK object piggy-backed
	rather than in an ACK object?

4. How long should the ACKer delay before sending an ACK object or
	piggy-backing?

5. The [only] reason you have MESSAGE_ID MCAST_LIST and SRC_LIST
	objects is to allow RPF checks when Srefresh messages for
	multicast sessions are sent to the all-hosts multicast
	address?

Thanks,

Bob Braden

---

From: Lou Berger <[email-masked]>
Date: Fri, 05 Nov 1999 20:37:06 -0500

Bob,
         Thanks for the additional comments.

>         Precisely why? (There seems to be some logic omitted here...)

Because if you can't detect a route change you could send path and path 
tear messages to the wrong (pre change) next hop.  Remember Bundle messages 
are sent hop-by-hop.

>         What is a Message_ID object in a Bundle message used for?

Reliable transmission of the whole bundle.

>         (BTW, your BNF for a Bundle message does not include

woops, that's a bug.

>         There is no alternative for NACK objects, is there?

Both NACKs and ACKs may be sent piggy-backed (see section 3 intro or 3.5) 
or in an ACK message (see section 3.3).

(Are you perhaps reading draft -00?  draft -01's text is cleanup a bit and 
is more consistent - mostly resulting from your earlier comments.  Let me 
know if you want a version with change-bars.)

I think the current text is fairly explicit on this.

>         rather than in an ACK object?

In my opinion, yes. Hence the "should".  Note that it is intentionally NOT 
a requirement.

>4. How long should the ACKer delay before sending an ACK object or

That's an implementation choice.  Your right, some guidance could be helpful.

>         multicast sessions are sent to the all-hosts multicast

The first part of the sentence is correct.  Both are required solely to 
perform RPF checks.

SRC_LIST objects contain {message_identifier, S}.  They are sent in 
messages destined for a session's multicast destination {G}.  Since the 
multicast group is carried in the IP header it doesn't need to be present 
in the object.

MCAST_LIST objects contain {message_identifier, S, G}.  They are carried in 
messages destined for an RSVP next hop when that next hop is directly 
connected over a point to point link.  This allows the aggregation of all 
multicast (and unicast) path associated message_identifiers to be 
aggregated into a single message.   Since the multicast destination {G} 
isn't in the header it must be carried in the object.

If we sent the Srefreshes for all multicast Path state to the all- RSVP 
hosts multicast address (this is George's preference) then all we wouldn't 
need the SRC_LIST object, but RSVP hosts that were not listening to a group 
would need to filter (at the RSVP level) Srefreshes for each group it 
wasn't listening to.

Thanks,
Lou