Brian,

I would be also interested in the conditionals in this which is best
case 3 machine instructions too.  And what the conditionals did to the
complexity of the code and future maintance.  Of course I am not clear
implementation details interest many these days in our decision process.
Its like we infinite time and infinite resources to do IPv6.

/jim
[Have you ever seen the rain coming down on a sunny day]


> -----Original Message-----
> From: Brian Haberman [mailto:bkhabs@;nc.rr.com] 
> Sent: Wednesday, October 30, 2002 9:08 PM
> To: Ole Troan
> Cc: Jun-ichiro itojun Hagino; Richard Draves; [EMAIL PROTECTED]
> Subject: Re: Limiting the Use of Site-Local
> 
> 
> 
> 
> Ole Troan wrote:
> >>>>A router might (and probably should) be hard-coded not to
> >>>>forward link-local packets, as there is no reason to ever 
> >>>>forward them.
> >>>>
> >>>>However, a router that might ever need have multiple
> >>>>interfaces in a single site can't be hard-coded not to 
> >>>>forward site-locals. Whether or not they will be forwarded is 
> >>>>the result of configuration.
> >>>
> >>>Actually, a router can forward link-locals between 
> interfaces on the 
> >>>same link. In particular, a router can forward a packet with 
> >>>link-local dest and/or source back out the interface from which it 
> >>>arrived (and presumably generate a Redirect too).
> >>>
> >>>If you are implementing link-locals properly, it's really 
> very little 
> >>>additional code to support site-locals. At least that's my 
> >>>experience.
> >>
> >>    could you comment on routing code? (RIPng, OSPFv3)  i 
> still think
> >>    it's way too tough to support multi-sited node.
> > 
> > 
> > RIPng is relatively simple. link-state protocols require congruent 
> > areas and sites. there are some open issues with regards to 
> multicast 
> > and PIM I believe. routing protocol support is required in any case 
> > for VPNs.
> 
> The actual routing protocol changes in RIPng is dependent on 
> how you structure your RIBs.  I hacked RIPng to make an SBR 
> using a monolithic RIB with an additional index (the zone 
> id). It was an additional 800-900 lines of code to deal with 
> figuring out which RIB entries needed to be advertised on 
> each interface.
> 
> Then there are the changes to configure and maintain the zone IDs.
> 
> The biggest hit is actually in the forwarding.  Each packet 
> gets at least one additional table lookup (for the incoming 
> zone id).  Then there are the checks to ensure that the 
> source address is valid (e.g. a site-local SA and global DA 
> trying to cross a site border).
> 
> The extra cost?  Performance drops around 25-30% for a SBR 
> between 3 sites.  Of course, this was all software based, but 
> even a hardware-based solution will take the extra lookup hits.
> 
> Brian
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to