IPv6: IS-IS or OSPFv3
Hello, I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern! 1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resource utilization for both the protocol will be same as they are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature! 2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6! 3. what if i have already running OSPFv2 for IPv4 in the network then should i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS? regards Devang Patel
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
General rule of thumb - use whichever you / your operation is most familiar with. Using IS-IS today, use it for IPv6. Using OSPFv2 today, use OSPFv3 for IPv6. If that isn't good enough for you, then you need to understand the operational differences between the protocols, and which aspects are most relevant to your environment. I can't answer that for you ...
1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2
be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resource utilization for both the protocol will be same as
will Yes, MT could be a benefit ... but "not the same thing" for OSPF. they
are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature!
ISIS is generally considered easier to extend, but OSPF has proven to be quite extensible itself ... a wash, for the most part.
2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6!
Yes, lack of a native IPv6 "control plane" could be something of (cough) problem.
3. what if i have already running OSPFv2 for IPv4 in the network then
should
i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS?
Again, IMHO this depends on way too many factors to make a simple, blanket statement.
regards Devang Patel
HTH! /TJ
TJ wrote:
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
General rule of thumb - use whichever you / your operation is most familiar with. Using IS-IS today, use it for IPv6. Using OSPFv2 today, use OSPFv3 for IPv6.
Well, OSPFv3 has enough differences from OSPFv2 to make switching to IS-IS a benefit to stop people making mistakes through expected operational similarity (if that makes sense). Also it means that once you're doing v6 everywhere you can dump OSPFv2 and only have one IGP for both v4 and v6. I personally think that'll save a lot of headaches down the line, not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work with. adam.
TJ wrote:
... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work with.
WRT that last sentence, that is an almost religious debate I was trying to avoid starting ... :)
I will offer a mantra that has helped me, over the years, about the indeed religious wars that emerge when a New Technology or Youthful feature comes to these two link state protocols. I begin to mutter "ISNT and OySPF".
TJ wrote:
... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work
with.
WRT that last sentence, that is an almost religious debate I was trying to avoid starting ... :)
Well IMHO it's a very important point to consider. This is a great chance to switch your IGP, if you've ever wanted to. You *need* to deploy a new one anyways, so it's a great opportunity to see if you can simplify your network by migrating. Especially as OSPFv3 *isnt* the same as OSPFv2, so you will have to learn new things either way! Oh, and I *am* in the process of organising a Crusade to wipe out those heretical OSPF supporters once and for all... ;) adam.
... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work with.
WRT that last sentence, that is an almost religious debate I was trying to avoid starting ... :)
Well IMHO it's a very important point to consider. This is a great chance to switch your IGP, if you've ever wanted to. You *need* to
And that is what I tell people too - if you are looking to change (in either direction (or others!), mind you), this could be an excuse / opportunity.
deploy a new one anyways, so it's a great opportunity to see if you can simplify your network by migrating. Especially as OSPFv3 *isnt* the same as OSPFv2, so you will have to learn new things either way!
Well from a pragmatic/operational perspective OSPFv3 and OSPFv2 are "close enough" that you would require _very_ little re-training.
Oh, and I *am* in the process of organising a Crusade to wipe out those heretical OSPF supporters once and for all... ;)
Funny, that is how most ISIS proponents seem to feel - but without the smiley! /TJ
Date: Fri, 26 Dec 2008 19:47:21 -0700 From: "devang patel" <devangnp@gmail.com>
Hello,
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resource utilization for both the protocol will be same as they are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature!
2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6!
3. what if i have already running OSPFv2 for IPv4 in the network then should i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS?
FWIW, we run OSPF for IPv4 and ISIS for IPv6. We started with ISIS for v6 because we were routing IPv6 before OSPFv3 was available. The main reason I prefer ISIS is that it uses CLNS packets for communications and we don't route CLNS. (I don't think ANYONE is routing CLNS today.) That makes it pretty secure. I would hope you have a backbone well enough secured that you don't need to rely on this, but it does make me a bit more relaxed and makes me wish we were using ISIS for IPv4, as well. The time and disruption involved in converting is something that will keep us running OSPF for IPv4 for a long time, though. I remember the 'fun' of converting from IGRP to OSPF about 13 years ago and I'd prefer to retire before a repeat. The real issue is that you need to run something you understand and can manage effectively. It that is OSPF, it will certainly do the job. If it is ISIS, it will, too. The real differences are few and not significant for most. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Kevin, Thanks for pointing out other good part of having CLNS as a transport for ISIS as a security point! regards Devang Patel On Fri, Dec 26, 2008 at 9:37 PM, Kevin Oberman <oberman@es.net> wrote:
Date: Fri, 26 Dec 2008 19:47:21 -0700 From: "devang patel" <devangnp@gmail.com>
Hello,
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resource utilization for both the protocol will be same as they are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature!
2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6!
3. what if i have already running OSPFv2 for IPv4 in the network then should i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS?
FWIW, we run OSPF for IPv4 and ISIS for IPv6. We started with ISIS for v6 because we were routing IPv6 before OSPFv3 was available.
The main reason I prefer ISIS is that it uses CLNS packets for communications and we don't route CLNS. (I don't think ANYONE is routing CLNS today.) That makes it pretty secure.
I would hope you have a backbone well enough secured that you don't need to rely on this, but it does make me a bit more relaxed and makes me wish we were using ISIS for IPv4, as well. The time and disruption involved in converting is something that will keep us running OSPF for IPv4 for a long time, though. I remember the 'fun' of converting from IGRP to OSPF about 13 years ago and I'd prefer to retire before a repeat.
The real issue is that you need to run something you understand and can manage effectively. It that is OSPF, it will certainly do the job. If it is ISIS, it will, too. The real differences are few and not significant for most. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Saturday 27 December 2008 12:56:39 pm devang patel wrote:
Thanks for pointing out other good part of having CLNS as a transport for ISIS as a security point!
We've been happy with IS-IS, having migrated from OSPF ealrier on in the year. We like it because it lets us "stretch" the network without worrying about connectivity to the "backbone" area. However, as most others have said, go with what you're comfortable with. The knobs and switches really aren't that different nowadays, just a few fundamentals that you can easily use to decide which makes (more) sense to you. For v6, using a single routing protocol for both address families is not so bad (although running both OSPFv2 and OSPFv3 really isn't a big deal, or bad thing, having done it at my previous employment and so on). For IS-IS, highly recommend MT to avoid any nasties while turning up v6 in a dual-stack environment. Cheers, Mark.
For IS-IS, highly recommend MT to avoid any nasties while turning up v6 in a dual-stack environment.
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing? randy
On Sat, 27 Dec 2008, Randy Bush wrote:
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing?
Personally, if my v4 and v6 topologies are not different, I'd run ISIS and not run MT. MT for me is to make v4 and v6 have different control planes (even though it's using the same protocol), thus I see little difference in running OSPFv3+ISIS, or running ISIS-MT for v4+v6. I argue that it's better to have different control planes for v4 and v6 and make it obvious (OSPv3 / ISIS), than to use ISIS-MT and "obfuscate". -- Mikael Abrahamsson email: swmike@swm.pp.se
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing?
Personally, if my v4 and v6 topologies are not different, I'd run ISIS and not run MT. MT for me is to make v4 and v6 have different control planes (even though it's using the same protocol), thus I see little difference in running OSPFv3+ISIS, or running ISIS-MT for v4+v6.
I argue that it's better to have different control planes for v4 and v6 and make it obvious (OSPv3 / ISIS), than to use ISIS-MT and "obfuscate".
the real control plane is bgp. is-is is for recursive resolution to find bgp's next hop interface, fertig. so the simpler the better. i am annoyed enough that bgp4 and bgp6 peerings and configs are overly divergent. running a different igp for 6 and 4 would not make me happy. randy
On Saturday 27 December 2008 09:27:05 pm Randy Bush wrote:
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing?
In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured. Those links surely lost IS-IS adjacency which threatened stability of the network. Things could probably have been easier if all routers accepted all transition commands at the same time (or if all routers were pre-configured and powered on at the same time), but that's not possible. MT allowed us to bring up individual v6 links on the same and different routers, at different times, without bringing down the v4 network, considering that several routers had as many as 4 - 6 links into the core. Cheers, Mark.
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing?
In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured.
Those links surely lost IS-IS adjacency which threatened stability of the network.
Yup, that is the rub: if rolling out your v6 routing impacts your v4 routing you are not "winning". /TJ
In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured. Those links surely lost IS-IS adjacency which threatened stability of the network. Yup, that is the rub: if rolling out your v6 routing impacts your v4 routing you are not "winning".
this is not very deep. mark did point out how to avoid it, pointing out why mt was very useful as opposed to just another bell and whistle. during a transition, in fact, topologies are not congruent due to inability to have a flag millisecond, a very very useful observation. randy
In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured. Those links surely lost IS-IS adjacency which threatened stability of the network. Yup, that is the rub: if rolling out your v6 routing impacts your v4 routing you are not "winning".
this is not very deep.
Is it untrue?
mark did point out how to avoid it, pointing out why mt was very useful as opposed to just another bell and whistle. during a transition, in fact, topologies are not congruent due to inability to have a flag millisecond, a very very useful observation.
Indeed, and not creating the problem is good thing. I don't think we are disagreeing on anything here ... Although I don't believe anyone has mentioned "multi-topology" + "transition" just yet, the goal being that when you go from ST to MT (assuming you aren't already there, that is) you don't impact ongoing operations / neighborships. /TJ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Dec 28, 2008, at 3:00 AM, Mark Tinka wrote:
On Saturday 27 December 2008 09:27:05 pm Randy Bush wrote:
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing?
In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured.
at least in my case, I did turned ISISv6 in one WAN interface where the router on the other side (a Cisco) did not have the "ipv6 unicast routing" general command on and the isis adjacency went down completely. So, yes that was an issue. But if you enabled IPv6 in both ends first and then one interface at the time, it worked. I used MT to avoid IPv6 black holes during the configuration period, but as some boxes did not implemented it, I needed to use the "transition" option where IPv6 adjacencies are carried in both native and the MT-IPv6. Fortunately the two vendors that were lacking of MT support are up-to-date, however not in time as the migration ended and MT was removed and I left the company. Roque. - - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklabZkACgkQnk+WSgHpbO49PACg2Rx0yaH4owU2GA5koORD+pra kjgAoMgoXYDVD2ayWhn56fkt0urcyyAx =1tWb - - - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklacwUACgkQnk+WSgHpbO4TUgCfVpGEMMIdS8y0RrtNQh9rh1Ne fQcAoIOBUc2O4em8NwqwR2UJDDm1Z7Mh =YAeJ -----END PGP SIGNATURE-----
On Wednesday 31 December 2008 03:14:13 am Roque Gagliano wrote:
at least in my case, I did turned ISISv6 in one WAN interface where the router on the other side (a Cisco) did not have the "ipv6 unicast routing" general command on and the isis adjacency went down completely. So, yes that was an issue.
One of the things I'm hoping Cisco can fix in not-too- distant future releases of IOS.
But if you enabled IPv6 in both ends first and then one interface at the time, it worked.
What we saw on our test segment was that v4 adjacencies were not torn down by merely enabling IS-ISv6 on an interface (given that JunOS enables IS-ISv6 by default when IS-IS is enabled on the router; in IOS, you have to explicitly turn IS-ISv6 on). v4 adjacencies were torn down *after* an IPv6 address was added to the interface. We witnessed this issue under both IOS and JunOS. Cheers, Mark.
On Fri, 26 Dec 2008, devang patel wrote:
Thanks for pointing out other good part of having CLNS as a transport for ISIS as a security point!
It's also a potential hassle, where you can have IS-IS up and running, but have IP completely hosed. With OSPF this is harder as it actually runs over IP; no IP, no IGP adjacancy. There is good reason why neither OSPF nor IS-IS rules the IGP world, they both have their advantages and disadvantages. Differences are usually in what the organisation is used to, not because one is fundamentally better than the other. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, 26 Dec 2008 20:37:41 -0800 "Kevin Oberman" <oberman@es.net> wrote:
The main reason I prefer ISIS is that it uses CLNS packets for communications and we don't route CLNS. (I don't think ANYONE is routing CLNS today.) That makes it pretty secure.
Unless, of course, someone one hop away -- a peer? a customer? an upstream or downstream? someone on the same LAN at certain exchange points? -- sends you a CLNP packet at link level... --Steve Bellovin, http://www.cs.columbia.edu/~smb
Steven M. Bellovin writes:
Unless, of course, someone one hop away -- a peer? a customer? an upstream or downstream? someone on the same LAN at certain exchange points? -- sends you a CLNP packet at link level...
True enough, and mistakenly enabling ISIS on external ports has been known to happen though in the absence of malice it usually causes no problems. If it does cause problems, generally the source can be more easily localized given that it has to be L2-adjacent to one of your routers. Joe
Date: Sat, 27 Dec 2008 15:23:25 -0500 From: "Steven M. Bellovin" <smb@cs.columbia.edu>
On Fri, 26 Dec 2008 20:37:41 -0800 "Kevin Oberman" <oberman@es.net> wrote:
The main reason I prefer ISIS is that it uses CLNS packets for communications and we don't route CLNS. (I don't think ANYONE is routing CLNS today.) That makes it pretty secure.
Unless, of course, someone one hop away -- a peer? a customer? an upstream or downstream? someone on the same LAN at certain exchange points? -- sends you a CLNP packet at link level...
You mean that someone is silly enough to enable CLNS on external interfaces? I mean, it's not by default on either Cisco or Juniper. I don't imagine any other routers do that, either. (Of course, SOMEONE is always that silly. But I hope the folks reading this are not.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Kevin Oberman wrote:
I would hope you have a backbone well enough secured that you don't need to rely on this, but it does make me a bit more relaxed and makes me wish we were using ISIS for IPv4, as well. The time and disruption involved in converting is something that will keep us running OSPF for IPv4 for a long time, though. I remember the 'fun' of converting from IGRP to OSPF about 13 years ago and I'd prefer to retire before a repeat.
I did the OSPF --> IS-IS migration some time back and here's some of the info I found at the time. http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=&nm=nanog29 Vijay did a nice presentation on AOL's migration to IS-IS. IIRC AOL migrated everything in 2 days. Day 1 was to migrate their test POP and hone their script. All remaining POPs were migrated on Day 2. I believe he said it went well. There have been several other documented migrations too: http://www.geant.net/upload/pdf/GEANT-OSPF-to-ISIS-Migration.pdf http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof-ospf.pdf I migrated my SP from a flat OSPF network (end to end area 0) to IS-IS. The OSPF setup was seriously screwed up. Someone got the bright idea to changes admin distances on some OSPF speakers, introduce a default in some places with static defaults in others, redistributing like it was going out of style, redisting a static for a large customer subnet on P2 instead of P1 which is what PE1 actually connected to (and not advertising the route from PE1 for some unknown reason), etc. The old setup was a nightmare. The IS-IS migration went fairly well after I got some major bugs worked out on our 7600s. I implemented IS-IS overtop of OSPF. Some OSPF speakers had admin distances of 80 and some were default. IS-IS slipped in over top with no problems. I raised IS-IS to 254 for the initial phase anyway just to be safe. Once I had IS-IS up I verified it learned all the expected routes via IS-IS. Then I lowered its admin distance back to the default and bumped OSPF up to 254. Shortly thereafter I nuked OSPF from each device. It was hitless. I never could get IS-IS to work with multiple areas. The 7600s made a smelly mess on the CO floor every time I tried. In the end I went with a L2-only IS-IS network. Still it works well for the most part. I've had about as much trouble with IS-IS as I have had with OSPF. Occasionally some random router will get a burr under it's saddle and jack up the MTU on the CLNS packets beyond the interface's max. The receiving router will drop the padded frame as too big. Fixing this can sometimes happen with a shut/no shut. Sometimes I can nuke the entire IS-IS config and re-add the config. Other times I simply have to reboot. This doesn't happen too often; it's usually several hours after I rock the IS-IS boat so to speak. Still, I wouldn't go back to OSPF for this SP. Justin
Thanks all for sharing information! regards Devang Patel On Mon, Jan 5, 2009 at 11:43 AM, Justin Shore <justin@justinshore.com>wrote:
Kevin Oberman wrote:
I would hope you have a backbone well enough secured that you don't need to rely on this, but it does make me a bit more relaxed and makes me wish we were using ISIS for IPv4, as well. The time and disruption involved in converting is something that will keep us running OSPF for IPv4 for a long time, though. I remember the 'fun' of converting from IGRP to OSPF about 13 years ago and I'd prefer to retire before a repeat.
I did the OSPF --> IS-IS migration some time back and here's some of the info I found at the time.
http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=&nm=nanog29
Vijay did a nice presentation on AOL's migration to IS-IS. IIRC AOL migrated everything in 2 days. Day 1 was to migrate their test POP and hone their script. All remaining POPs were migrated on Day 2. I believe he said it went well. There have been several other documented migrations too:
http://www.geant.net/upload/pdf/GEANT-OSPF-to-ISIS-Migration.pdf http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof-ospf.pdf
I migrated my SP from a flat OSPF network (end to end area 0) to IS-IS. The OSPF setup was seriously screwed up. Someone got the bright idea to changes admin distances on some OSPF speakers, introduce a default in some places with static defaults in others, redistributing like it was going out of style, redisting a static for a large customer subnet on P2 instead of P1 which is what PE1 actually connected to (and not advertising the route from PE1 for some unknown reason), etc. The old setup was a nightmare.
The IS-IS migration went fairly well after I got some major bugs worked out on our 7600s. I implemented IS-IS overtop of OSPF. Some OSPF speakers had admin distances of 80 and some were default. IS-IS slipped in over top with no problems. I raised IS-IS to 254 for the initial phase anyway just to be safe. Once I had IS-IS up I verified it learned all the expected routes via IS-IS. Then I lowered its admin distance back to the default and bumped OSPF up to 254. Shortly thereafter I nuked OSPF from each device. It was hitless. I never could get IS-IS to work with multiple areas. The 7600s made a smelly mess on the CO floor every time I tried. In the end I went with a L2-only IS-IS network. Still it works well for the most part. I've had about as much trouble with IS-IS as I have had with OSPF. Occasionally some random router will get a burr under it's saddle and jack up the MTU on the CLNS packets beyond the interface's max. The receiving router will drop the padded frame as too big. Fixing this can sometimes happen with a shut/no shut. Sometimes I can nuke the entire IS-IS config and re-add the config. Other times I simply have to reboot. This doesn't happen too often; it's usually several hours after I rock the IS-IS boat so to speak. Still, I wouldn't go back to OSPF for this SP.
Justin
On Fri, 26 Dec 2008, devang patel wrote:
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
Both work and have advantages and disadvantages. Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3. ISIS-MT means you have to know that all your ISIS speakers will handle the MT packets gracefully. I know products from large vendors in the market which do not (IPv6 not enabled, it receives IPv6 MT packets, affects IPv4 ISIS control plane badly). -- Mikael Abrahamsson email: swmike@swm.pp.se
Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3.
I totally agree on the discrete/segregated control planes, although note that - for those who want it - OSPFv3 will "soon" be able to do IPv4 route exchange as well ... /TJ
-----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Saturday, December 27, 2008 6:23 AM To: devang patel Cc: nanog@nanog.org Subject: Re: IPv6: IS-IS or OSPFv3
On Fri, 26 Dec 2008, devang patel wrote:
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
Both work and have advantages and disadvantages.
Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3. ISIS-MT means you have to know that all your ISIS speakers will handle the MT packets gracefully. I know products from large vendors in the market which do not (IPv6 not enabled, it receives IPv6 MT packets, affects IPv4 ISIS control plane badly).
-- Mikael Abrahamsson email: swmike@swm.pp.se
TJ wrote:
Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3.
I totally agree on the discrete/segregated control planes, although note that - for those who want it - OSPFv3 will "soon" be able to do IPv4 route exchange as well ...
Only if the vendors pick up on those changes. Kind regards, Martin List-Petersen
/TJ
-----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Saturday, December 27, 2008 6:23 AM To: devang patel Cc: nanog@nanog.org Subject: Re: IPv6: IS-IS or OSPFv3
On Fri, 26 Dec 2008, devang patel wrote:
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern! Both work and have advantages and disadvantages.
Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3. ISIS-MT means you have to know that all your ISIS speakers will handle the MT packets gracefully. I know products from large vendors in the market which do not (IPv6 not enabled, it receives IPv6 MT packets, affects IPv4 ISIS control plane badly).
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3.
I totally agree on the discrete/segregated control planes, although note that - for those who want it - OSPFv3 will "soon" be able to do IPv4 route exchange as well ...
Only if the vendors pick up on those changes.
Well, of course - just like anything else. That was part of the reason for the scary-quotes around soon ... /TJ
There is no fundamental difference between ISIS and OSPF; it's all in details and style. You might want to look at: http://www.nada.kth.se/kurser/kth/2D1490/06/hemuppgifter/bhatia-manral-diff-... Glen. On Sat, Dec 27, 2008 at 8:17 AM, devang patel <devangnp@gmail.com> wrote:
Hello,
I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern!
1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resource utilization for both the protocol will be same as they are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature!
2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6!
3. what if i have already running OSPFv2 for IPv4 in the network then should i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS?
regards Devang Patel
participants (14)
-
Adam Armstrong -
devang patel -
Glen Kent -
Howard C. Berkowitz -
Joe Malcolm -
Justin Shore -
Kevin Oberman -
Mark Tinka -
Martin List-Petersen -
Mikael Abrahamsson -
Randy Bush -
Roque Gagliano -
Steven M. Bellovin -
TJ