Subject: WORKING GROUP LAST CALL

From: Bob Braden <[email-masked]>
Date: Wed, 9 Feb 2000 01:38:45 GMT

This is a Working Group Last Call on RSVP Refresh Overhead Reduction
Extensions for Proposed Standard, as defined in:

	draft-ietf-rsvp-refresh-reduct-02.txt

We strongly urge you to read it and comment.

Bob Braden
Lixia Zhang
Co-chairs

---

From: Lou Berger <[email-masked]>
Date: Wed, 09 Feb 2000 12:51:32 -0500

Bob,
         When does the last call close?

Thanks,
Lou

---

From: Mayumi Tomikawa <[email-masked]>
Date: Fri, 18 Feb 2000 09:53:06 +0900

Comment on draft-ietf-rsvp-refresh-reduct-02.txt.

Section 5.5. the second paragraph says, "the node compares the new
checksum value and stored one periodically, and if the values differ,
then a corresponding standard Path or Resv refresh message should be
sent." 
But it is not clear who should send the standard refresh message. Is
it the node which found the checksum error, or the original node of
the corresponding state? 

If the former sends a standard refresh message, an incorrect state may 
be sent to the next hop, because the different values show some
internal errors. So we think, when the values differ, the node which
found the error needs to receive a standard message. 
However, most likely, the node will not receive any standard message,
since the sender continues to send Srefresh messages.

So, the node must explicitly request the sender for a full (standard)
message.
We think there are two approachs.
1) The node sends NACK to the original node as soon as he finds the
   checksum error.
2) The node sends NACK, when he receives the next Srefresh message
   from the original node.
When the node receives a standard message, it processes the whole
message regardless of the Message_ID value.

---
Mayumi Tomikawa
Fujitsu Laboratories Ltd.

---

From: Lou Berger <[email-masked]>
Date: Sun, 20 Feb 2000 14:05:11 -0500

>it the node which found the checksum error, or the original node of

I think it's clear in full context:

    The first mechanism uses a checksum or other algorithm to detect a
    previously unnoticed change in internal state.  When sending a Path
    or Resv trigger message, a node should run a checksum or other
    algorithm, such as [MD5], over the internal state and store the
    result.  The choice of algorithm is an administrative decision.
    Periodically the node should rerun the algorithm and compare the new
    result with the stored result.  If the values differ, then a
    corresponding standard Path or Resv refresh message should be sent
    and the new value should be stored.  The recomputation period should
    be set based on the computation resources of the node and the
    reliability requirements of the network.

it's the node that finds the difference.

>internal errors.

The describe mechanism is aimed solely aimed at advertising state changes 
that may have gone unnoticed by the mechanism that generates trigger 
messages.  (This is inherent in standard RSVP refreshes.)

Protection against internal state corruption is not addressed by this 
mechanism and cannot be addressed by the transmission of a refresh 
message.  As eluded to in your message, it may be addressed by the receipt 
of a refresh messages.  This is the purpose of the paragraph following the 
one mentioned above.  It simply says to periodically send standard 
refreshes even when doing summary refreshes.

>So we think, when the values differ, the node which

I think you're combining two cases here: unnoticed state changes and 
internal state corruption.  Both of these are separately addressed in 
section 5.5.

>since the sender continues to send Srefresh messages.

right, because the described mechanism is covering unnoticed changed not 
corruption.

>message regardless of the Message_ID value.

or just follow all of section 5.5.

Thank you for the comment,
Lou Berger