Re: NATFW issue: state 'transit' timer definition
Hannes Tschofenig <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
Setting the default value to 30 seconds sounds fine to me. Ciao Hannes Martin Stiemerling wrote: > [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 >