| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [patch]: CONFIG_IPV6_SUBTREES fix for MIPv6 |
| From: | Henrik Petander <lpetande@xxxxxxxxxx> |
| Date: | Thu, 12 Jun 2003 11:44:49 +0300 |
| Cc: | nakam@xxxxxxxxxxxxxx, lpetande@xxxxxxxxxxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx, vnuorval@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, ajtuomin@xxxxxxxxxxxxxxxxxxx, jagana@xxxxxxxxxx, kumarkr@xxxxxxxxxx, usagi-core@xxxxxxxxxxxxxx |
| In-reply-to: | <20030611.202003.74721468.davem@xxxxxxxxxx> |
| References: | <3EE5F85E.9080006@xxxxxxxxxx> <20030610.095135.28806569.davem@xxxxxxxxxx> <3EE6ECD3.6050103@xxxxxxxxxx> <20030611.202003.74721468.davem@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 |
David S. Miller wrote: From: Henrik Petander <lpetande@xxxxxxxxxx> Date: Wed, 11 Jun 2003 11:48:19 +0300Does this make sense to you?No it doesn't. When you startup zebra, it may flush the entire routing table. I don't see a problem in that. It would only result in a short period of missing mipv6 route optimization information, until MIPv6 daemon reinserted the mipv6 information. MIPv6 daemon would do this after getting a notification of the deletion of the old mipv6 related cached routes. This would relate to zebra in the same way as pmtu discovery. Regards, Henrik |
| Previous by Date: | Re: IPSec: Policy dst bundles exhausting storage, David S. Miller |
|---|---|
| Next by Date: | Re: gettime: Was (Re: Route cache performance under stress, David S. Miller |
| Previous by Thread: | Re: [patch]: CONFIG_IPV6_SUBTREES fix for MIPv6, David S. Miller |
| Next by Thread: | Re: [patch]: CONFIG_IPV6_SUBTREES fix for MIPv6, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |