[j-nsp] IPv6

[Richard A Steenbergen]

On Sun, Jan 24, 2010 at 02:43:19AM +0800, Mark Tinka wrote:
> On Sunday 24 January 2010 02:13:41 am Richard A Steenbergen wrote:
> 
> > Convenience. Obviously with eBGP there are other reasons to run two
> > sessions (like liveness tests), but with iBGP there is no inherent
> > reason why you'd need to duplicate your BGP mesh. Cisco does the
> > right thing w/next-hop-self, you just have to work around this
> > behavior with Juniper NHS.
> 
> With regard to routing policy, we originally considered utilizing the
> same policy framework for v6 as we did v4, literally sharing it
> between both v4 and v6 iBGP sessions, but that didn't work out easily
> as there are some kinky things we did with v4 that the simplicity of
> v6 gladly takes away. So separating them made sense, and the
> convenience was retained.
> 
> Independent iBGP sessions for v4 and v6 are convenient enough for us,
> but if for nothing else, the ability to have v6 up and running even
> when something terrible happens to the v4 network (if it does) is not
> too shabby.

Our policy framework is precisely the same for v4 and v6, for the sake
of simplicity and maintainability. About 98% of our Juniper policies are
standardized, either as apply-groups synced by netconf, or generated on
demand by commit scripts. Any specific policies which need to be applied
are linked in as a subroutine via a transient change under the framework
of a commit script. This not only makes it more convenient, and helps 
prevent BGP sessions from flapping every time you do something which 
would otherwise break update grouping (juniper does a terrible job 
handling this, unfortunately), but it lets you put a lot of safeguards 
in place which prevent bad things from happening as the result of a 
misconfiguration (hey, everybody makes them, just ask leveled3 :P).

Given that, I see no real benefit to running independent iBGP sessions,
only more sessions which need to be configured unnecessarily (and when
they land on a Cisco, they aren't nearly as easy to deploy and maintain
automatically :P). Can't say that I've ever seen an instance where there
would be a benefit from running the two seperately either. Now IGP on
the other hand is a different story, I've seen several instances where
something bad happens (mostly to v6) where it pays to run multi-topology
isis so you can turn off v6 on a particular link when a router decides
it just doesn't want to forward v6 packets via that interface any more.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)