Subject: Clarification on RSVP HELLO Optimization (draft-ietf-mpls-rsvp-ls p-tunnel-08)

From: "Arvind, K" <[email-masked]>
Date: Mon, 11 Jun 2001 17:14:33 -0400

The last paragraph of Section 5(.0) in draft-ietf-mpls-rsvp-lsp-tunnel-08
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
states:

"A poll request also includes the sender's instance value. This allows the
receiver of a poll to optionally treat the poll as an implicit response.
This optional handling is an optimization that can reduce the total number
of polls and responses processed by a pair of neighbors. In all cases, when
both sides support the optimization the result will be only one set of polls
and responses per failure detection interval. Depending on selected
intervals, the same benefit can occur even when only one neighbor supports
the optimization."

Could someone please clarify this optimization further? Does the
optimization consist of responding to a request with another (regularly
scheduled) request [Interpretation 1], or responding to a request with an
ack and then suppressing the next regularly scheduled request (i.e., treat
the request as an implicit precocious/unsolicited ack) [Interpretation 2],
or something else? 

With Interpretation 1, the two ends of a link exchange Hello requests
periodically and no explicit acks are involved. This sounds like a
reasonable optimization, but is not consistent with Section 5.3 ("On receipt
of a message containing a HELLO REQUEST object, the receiver MUST generate a
Hello message containing a HELLO ACK object"). 

With Interpretation 2, one end of a link may end up generating periodic
Hello requests only, while the other end may end up generating only Hello
acks in response. This also results in optimizing Hello traffic. If this was
indeed the intended interpretation, it would be helpful if the paragraph
quoted above were rewritten to make this clear. 

Thanks.

Regards,
Arvind.