RE: NATFW issue: state 'transit' timer definition
"Georgios Karagiannis" <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
Hi Martin A default value of 30 seconds for the timer is fine for me! Best regards, Georgios _____ From: Martin Stiemerling [mailto:[email protected]] Sent: woensdag 30 januari 2008 9:37 To: nsis Subject: Re: [NSIS] NATFW issue: state 'transit' timer definition [writing with chair's hat off, i.e., as NATFW NSLP author only!] Hi, I do assume that everybody is fine with the proposed change. If not, please speak up now! Thanks, Martin (as NATFW NSLP author) Am 24.01.2008 11:22 Uhr schrieb "Martin Stiemerling" unter <[email protected]>: [writing with chair's hat off, i.e., as NATFW NSLP author only!] Hi all, I finally found time to get back to the NATFW NSLP and your WGLC comments. Thanks to all who did a review and sent in their comments! I also have done a complete review of draft-ietf-nsis-nslp-natfw-16.txt and found some issues to be discussed. There will be separate e-mails for each issue I've found. Here we go: In Section 3.2.8. NATFW NSLP Signaling Sessions the different conceptual states of the a NATFW NSLP signaling session are defined. I see all states are fine except the last one which is 'transit': Transit: The node has received an asynchronous message, i.e., a NOTIFY, and can delete the NATFW NSLP signaling session if needed. When a node has received a NOTIFY message (for instance, indicating a route change) it marks it as 'Transit' and deletes this NATFW NSLP signaling session if it is unused for some time specific to the local node. This idle time does not need to be fixed, since it can depend on the node local maintenance cycle, i.e., the NATFW NSLP signaling session could be deleted if the node runs it garbage collection cycle. The issue is see, is the undefined timer value in this state. It simply says "...for some time..." which can result in implementations removing state immediately (time = 0), wait for seconds or minutes, or do never remove the state (would be a bug indeed). I personally would prefer to either give a fixed value or to give a formula to calculate this time in a standardised way. My proposal: Set this timer to 30 seconds fixed, as if there is no updating CREATE or EXTERNAL message within 30 seconds to a 'transit' state there won't be anything beyond this anymore. Martin [email protected] NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _____ _______________________________________________ nsis mailing list [email protected] https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list [email protected] https://www1.ietf.org/mailman/listinfo/nsis