From arjun at ceeyes.com Wed Dec 5 05:31:21 2007 From: arjun at ceeyes.com (Arjun Prasad) Date: Wed, 5 Dec 2007 19:01:21 +0530 Subject: [Xorp-hackers] Limitations and disadvantages of XORP Message-ID: <001901c83743$28612210$2283a8c0@ceeyes.com> Hi All! Can you people share the limitations and disadvantages with XORP till date. Regards , Arjun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071205/eacaeaf1/attachment.html From M.Handley at cs.ucl.ac.uk Mon Dec 10 15:48:43 2007 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Mon, 10 Dec 2007 23:48:43 +0000 Subject: [Xorp-hackers] XORP BGP 4-byte AS number support Message-ID: <84a612dd0712101548v40dfe8b1s1ec9e6d644270dbc@mail.gmail.com> I just committed a jumbo patch to CVS adding 4-byte AS number support to BGP. It's such a large patch because previously we stored path attributes in the form we received them, and didn't need to recode them on a per-peer basis because all peers used the same coding. 4-byte AS numbers break this, so now we encode only on output, as needed. Changing the way we store and process path attributes impacts a lot of code, but it's the right thing to do. RIPE will start allocating 4-byte AS numbers by default in a year, so we want to be ready! Anyway, just a heads up that although from the testing I've done I don't think this broke anything, it's possible BGP will have some issues until we've had a chance to see what happens on all the tinderbox platforms and the live test hosts. If you want to test this, the version of the user manual in CVS gives the details - let me know if the manual is unclear on anything. Cheers, Mark From kristian at spritelink.net Sat Dec 29 02:41:37 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Sat, 29 Dec 2007 11:41:37 +0100 Subject: [Xorp-hackers] XORP BGP 4-byte AS number support In-Reply-To: <84a612dd0712101548v40dfe8b1s1ec9e6d644270dbc@mail.gmail.com> References: <84a612dd0712101548v40dfe8b1s1ec9e6d644270dbc@mail.gmail.com> Message-ID: <20071229104136.GC53858@spritelink.se> On Mon, Dec 10, 2007 at 11:48:43PM +0000, Mark Handley wrote: > I just committed a jumbo patch to CVS adding 4-byte AS number support > to BGP. It's such a large patch because previously we stored path > attributes in the form we received them, and didn't need to recode > them on a per-peer basis because all peers used the same coding. > 4-byte AS numbers break this, so now we encode only on output, as > needed. Changing the way we store and process path attributes impacts > a lot of code, but it's the right thing to do. RIPE will start > allocating 4-byte AS numbers by default in a year, so we want to be > ready! > > Anyway, just a heads up that although from the testing I've done I > don't think this broke anything, it's possible BGP will have some > issues until we've had a chance to see what happens on all the > tinderbox platforms and the live test hosts. If you want to test > this, the version of the user manual in CVS gives the details - let me > know if the manual is unclear on anything. Why is this an option? Is there a reason not to have it turned on by default (ie always have support) ? -K -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From M.Handley at cs.ucl.ac.uk Sat Dec 29 09:04:59 2007 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Sat, 29 Dec 2007 17:04:59 +0000 Subject: [Xorp-hackers] XORP BGP 4-byte AS number support In-Reply-To: <20071229104136.GC53858@spritelink.se> References: <84a612dd0712101548v40dfe8b1s1ec9e6d644270dbc@mail.gmail.com> <20071229104136.GC53858@spritelink.se> Message-ID: <84a612dd0712290904rf3db788v1bc40d71ee6db9a2@mail.gmail.com> Well, the RFC says: To simplify transition, this document assumes that an Autonomous System could start using a 4-octet AS number only after all the BGP speakers within that Autonomous System have been upgraded to support 4-octet AS numbers. I'm really unclear on what happens if you enable it on a few routers and its not supported on others within an AS. The RFC isn't really clear on the issue in the case where your AS is two-octet compatible. In the case when your AS number is not two-octet compatible obviously it should default to on (currently it doesn't; this is a bug). Anyway I set it to be an explicit decision to turn it on rather than force anyone who upgrades to test out untested corner cases. - Mark On Dec 29, 2007 10:41 AM, Kristian Larsson wrote: > Why is this an option? Is there a reason not to > have it turned on by default (ie always have > support) ? > > -K > > -- > Kristian Larsson KLL-RIPE > Network Engineer & Peering Coordinator SpriteLink [AS39525] > +46 704 910401 kll at spritelink.net >