Subject: question regarding Message Id extension in draft-ietf-rsvp-refresh-reduct-03.txt

From: Sameer Shah <[email-masked]>
Date: Thu, 06 Apr 2000 12:06:42 -0400

Hi,

The draft says that the Refresh Reduction capable bit will be set in
messages
received from a node, if the node supports all the extensions suggested
in
the draft. But a node that supports reliable RSVP message delivery but
not
Bundle and refresh messages, will not set the Refresh-Reduction-Capable
bit.
This means that neighbor nodes ought to dynamically discover whether
this
node supports only the Message Id extension, from messages received from
this
node. If the messages contain a Message Id object or a Message Id Ack
object,
then this node supports Message Id extensions. Or if they receive an
error
message from the node specifying unknown object for the Message Id
object, then
it does not support Message Id extensions.

Would it not be more efficient to provide a bit in the flags field of
the common
RSVP header to indicate that a node supports only the Message Id
extensions,
similar to the RR capable bit, instead of using other mechanisms to
discover this.

Regards,
Sameer

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Apr 2000 09:02:00 -0400

Sameer,
         This is a reasonable alternative to what the draft describes.  I 
wouldn't want to use this alternative as the current approach (using the 
"Unknown Object Class" error) is the normal way, per rfc2205. to add 
functionality and detect when such new functionality isn't 
supported.    The use of flags field for the RRC bit was necessitated by 
the scope of the extensions and the addition of new message types.

Given the above, stage of the draft (it's been reviewed in numerous WG 
sessions and completed last call on 4/5) and apparent lack of support for 
your requested change, I don't think we should make this change.

Lou

---

From: Sameer Shah <[email-masked]>
Date: Mon, 10 Apr 2000 18:10:49 -0400

Hi Lou and RSVP drafts authors,

Guess its bit late in the IETF process, but have additional comments/
suggestions regarding the Refresh Reduction draft in addition to the
question raised earlier and have one question regarding the RSVP-TE
extensions to MPLS. This is a longer mail.

Related to Refresh Reduction Extensions:
1) Message Id on a per flow descriptor basis in the Resv message -
Currently there is a single Message Id on a per Resv message. So
this represents the state for all the flow descriptors in the flow
descriptor list. This is a problem when you have multiple flow
descriptors in the list. If the state for any one of the flow descriptor
changes e.g. the label value changes in a specific flow descriptor, this
would result in incrementing the Message Id for the Resv message,
and the receiver would have to fully process the Resv message,
including those flow descriptors that did not change. Or if a new flow
descriptor was added to the list, the Message Id would have to be
incremented. When the number of receivers are many e.g. in a
multicast session, this would lead to redundant processing at the
PHop node. I think we should have a Message Id on a per flow
descriptor basis similar to the flowspec (for fixed filter),
label and record route objects (as in MPLS extensions to RSVP).

2) Preserving Soft State with Srefresh message usage -
Two mechanisms are suggested in the draft to preserve RSVP's soft state
error recovery mechanism. In the first mechanism a node maintains a
checksum, and when it changes, a full refresh is sent. The draft should
clarify that if such an event happens, it should be treated as a trigger
and the new message should be sent with an incremented Mesage Id.
If you do not increment the Message Id, then as per Section 4.5 the
next hop will treat the message as a refresh and do only the refresh
processing. The other mechanism to avoid state corruption suggests
the sending of periodic standard Path and Resv refresh messages and
the period value must be longer than the Srefresh interval. In this case
too, when the full message is sent, it should be sent with an
incremented Message Id, otherwise the next hop may just do the
refresh processing.

(Though the difference between fully processing a message and refresh
processing of a message may be implementation specific, a node
may implement refresh processing by simply updating the internal time-
to-die values and not looking at any of the other objects).

3) Preserving soft state when using only the Message Id extensions -
This issue is similar to the earlier one but applies when the node
supports only the reliability extensions and does not support the
Bundling and other Refresh Reduction capabilities. As per processing
mentioned in Section 4.5 a node that receives the same Message Id
for a state may only do the refresh processing and not the full
processing. If we apply the definition of refresh processing as defined
above, then we again have the problem of soft state corruption. This
also should be addressed by sending an incremented Message Id, from
time to time so that the next hop node may perform full processing of
the message.

4) Aggregating Message Ids in the same Srefresh message -
Section 5.3 describes the usage of SRefresh message. Specifically

"When the outgoing interface is a point-to-point link, all Path state
 associated with sessions advertised out the interface SHOULD be
 included in the same Srefresh message. When the outgoing interface
 is not a point-to-point link, all unicast session Path state SHOULD be
 included in the same Srefresh message."

and the next paragraph reads

"Identifying which Resv state may be refreshed within a single
 Srefresh message is based simply on the source and destination IP
 addresses.  Any state that was previously advertised in Resv messages
 with the same IP addresses as an Srefresh message MAY be included."

I have a doubt regarding the use of the words SHOULD and MAY in these
paragraphs. For Path messages we are saying that all possible sessions
SHOULD be included in the Srefresh, but for Resv messages we are saying
that all those sessions MAY be included. Should we restrict how nodes
implement aggregation of the Message Ids in a Srefresh message ? In the
case of Path messages also, we may not want to aggregate all the Message
Ids together in order to prevent incurring huge processing during
smaller time intervals, if there are many sessions going through the same
next hop.

5) Question on bundling Path messages when the next hop is not
destination -
Section 3.3 describes various scenarios where Path messages could be
bundled. They can be bundled when the outgoing link is point-to-point.
But if the outgoing link is not point-to-point, does the following
statement imply a restriction

"It also includes Path and PathTear messages when the next hop is known
 to be the destination and changes in next hops can be detected."

For unicast sessions, if the outgoing link is of type broadcast
(e.g. Ethernet) should we still bundle Path messages only if the next hop
is the destination. Why cannot we bundle Path messages to a directly
connected RSVP next hop eventhough it is not the destination, if it is
possible to detect changes in routing.

Related to RSVP-TE Extensions to MPLS
6) What is the interpretation of the Resv Confirm object in
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt. Should a node generate a Resv
Confirm message if it was able to allocate resources for the LSP or
should Resv Confirm messages be only generated by the ingress node when
the end-to-end LSP is setup on receiving a Resv message. If the latter
makes more sense, then there is a problem according to the Resv Message
format described in section 3.2. This allows a single Resv Confirm object
in a Resv message, but in the MPLS case we have a requirement of
multiple Resv Confirm objects (maybe on a per flow descriptor basis).

Sameer

--
Sameer Shah
GlobeSpan Inc.
Email: [email-masked]
Web: www.globespan.net