Subject: Re: [NSIS] layer split summary? opinions?

From: Bob Braden <[email-masked]>
Date: Tue, 4 Feb 2003 20:12:02 GMT

*> 
  *> Another example:
  *> - TCP has this notion of connection
  *> - when TCP connection broke, what assumption would you make regarding
  *>   the state at the other signalling party?
  *>   currently BGP assumes all states were gone, and it ships another
  *>   copy of that huge routing table of 118000 entries over again
  *>   (bar the recent graceful restart, that does not handle all
  *>   the cases anyway)
  *> 

Lixia,

State recovery is indeed a serious design problem.  In RSVP we simply
assumed that the normal refrseshes would restore state in a neigbhbor
node that had crashed with loss of state and then restarted.  So, after
an average of 15 seconds, all reservations would be restored.  Is this
fast enough?  Perhaps not.

RFC 2961 (I think) added a handshake mechanism so a node would know
that its neighbor had crashed and recovered -- an epoch number.  When
the epoch number changes, a node can then flood (and flood is probably
the right word) all its state to the newly recovered node.  [The TCP
connection implies equivalent synchronization.]  But this is exactly
the 118000 entry case of BGP, and I don't see any logical alternative.

Bob
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 04 Feb 2003 12:30:01 -0800

> State recovery is indeed a serious design problem.

I believe the step before worrying about recovery is how one defines
failure.

(e.g. If the TCP connection gone, has the RSVP failed?)

Lixia