Subject: [v6ops] Looking for info on IGP choices in production dual-stack networks

From: Philip Matthews <[email-masked]>
Date: Thu, 4 Jun 2015 10:53:44 -0400

Folks:

Victor and I are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our Design Choices draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 5 large production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well".
 
If you have a production dual-stack network, then we would like to know which IGP you use to route IPv4 and which you use to route IPv6.  We would also like to know roughly how many routers are running this combination. Feel free to share any successes or concerns with the combination as well.  
 
We are looking particularly at combinations of the following IGPs:  IS-IS, OSPFv2, OSPFv3, EIGRP.
If you run something else (RIP?) then we would also like to hear about this, though we will likely document these differently. [We suspect you run RIP/RIPng only at the edge for special situations, but feel free to correct us].

And if you have one of those modern networks that carries dual-stack customer traffic in a L3VPN or similar and thus don’t need a dual-stacked core, then please email us and brag ...

Philip

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 5 Jun 2015 02:54:04 +0000 (UTC)

Hi,
      From: Philip Matthews <[email-masked]>
 To: v6ops list <[email-masked]> 
 Sent: Friday, 5 June 2015, 0:53
 Subject: [v6ops] Looking for info on IGP choices in production dual-stack networks
   
Folks:
Victor and I are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our Design Choices draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 5 large production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well". / I don't think this is really a good thing to be stating in such abstract terms, that is, at the IGP protocol level. I'd think the successful co-existence or not of IGPs, assuming the protocols themselves aren't broken (e.g., by using the same field value id for two different things), is  implementation dependent, and dependent on which specific revision of the implementation a network has chosen to deploy, and how that network has chosen to deploy it. For example, a literally perfect implementation of OSPF + IS-IS might be "judged to work badly" if deployed badly (by, for example, putting too many routers in the backbone area, overloading control plane resources.) 
/ I'm wondering a bit what the fundamental question trying to be being answered is? Is it to try to capture some information on the current popularity of various IGPs used to carrying IPv6 routes, and how popular the use of a single IGP to carry both IPv4 and IPv6 routes is?   What particular question or questions would the reader have that this text is trying to provide an answer for?
/ Regards,Mark.

If you have a production dual-stack network, then we would like to know which IGP you use to route IPv4 and which you use to route IPv6.  We would also like to know roughly how many routers are running this combination. Feel free to share any successes or concerns with the combination as well.   We are looking particularly at combinations of the following IGPs:  IS-IS, OSPFv2, OSPFv3, EIGRP.If you run something else (RIP?) then we would also like to hear about this, though we will likely document these differently. [We suspect you run RIP/RIPng only at the edge for special situations, but feel free to correct us].
And if you have one of those modern networks that carries dual-stack customer traffic in a L3VPN or similar and thus don’t need a dual-stacked core, then please email us and brag ...
Philip
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Matthews <[email-masked]>
Date: Fri, 5 Jun 2015 10:27:43 -0400

[Reformatting and excerpting my original message and Mark's reply  due to some technical issues]

On 2015-06-04, at 22:54 , Mark ZZZ Smith wrote:
> I don't think this is really a good thing to be stating in such abstract terms, that is, at the IGP protocol level. I'd think the successful co-existence or not of IGPs, assuming the protocols themselves aren't broken (e.g., by using the same field value id for two different things), is  implementation dependent, and dependent on which specific revision of the implementation a network has chosen to deploy, and how that network has chosen to deploy it. For example, a literally perfect implementation of OSPF + IS-IS might be "judged to work badly" if deployed badly (by, for example, putting too many routers in the backbone area, overloading control plane resources.) 
> 
> I'm wondering a bit what the fundamental question trying to be being answered is? Is it to try to capture some information on the current popularity of various IGPs used to carrying IPv6 routes, and how popular the use of a single IGP to carry both IPv4 and IPv6 routes is?   What particular question or questions would the reader have that this text is trying to provide an answer for?
> 
> Regards,
> Mark.

In the draft we have a table that lists the various combinations of IGPs for IPv4 and IPv6 and gives a few properties for each combination that people might want to consider when selecting a combination. The idea is to give people with less IPv6 knowledge some guidance and perhaps some reassurance when selecting a combination. 

One of the columns in the table is called "Known to work well".  Originally, Victor and I populated this based on our own experiences and biases, without consulting others.  However, in mid-April Mikael Abrahamsson commented on this table, noting that he has actually run one of the combinations that we marked as "not known to work well".  So Victor and I decided that we should be more scientific in populating this column.  Hence this survey of what people actually run.

Do you think the draft should NOT contain this type of information?  I can say that I have found the responses so far to be very interesting, even though it has been just a day so far.

Or do you have a suggestion for something else useful to say about each combination?  Victor and I feel it might be nice to add more information about each combination, but we don't have any ideas yet on what the "more information" should be.  We would love to hear from anyone who has a suggestion.

- Philip

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 6 Jun 2015 07:17:41 +0000 (UTC)

Hi Philip,
So I've spent more than the last 2 hours writing many abandoned emailed responses, if the below sounds a bit short, it's only because I want to send something to get some thoughts out there for consideration!

  From: Philip Matthews <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: v6ops list <[email-masked]> 
 Sent: Saturday, 6 June 2015, 0:27
 Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks

One of the columns in the table is called "Known to work well".
/ I think my main issue is with this column. I think it is asserting that, for example, all implementations of the combination of OSPFv2 for IPv4 and IS-IS for IPv6 are "Known to work well". So if you pick a combination with a "Y" in this column, you'll have no issues regardless of your OSPF and IS-IS implementation choice, or what deployment model you choose (single or multiple area, number of routers in an area/level etc.)
  Originally, Victor and I populated this based on our own experiences and biases, without consulting others.  However, in mid-April Mikael Abrahamsson commented on this table, noting that he has actually run one of the combinations that we marked as "not known to work well".  So Victor and I decided that we should be more scientific in populating this column.  Hence this survey of what people actually run.
/ Rhetorically, for the combination that Mikael has reported, are you going to put "Yes and No" in the "Known to Work Well" column? Or does Mikael's evidence cancel out that evidence that Victor and yourself have?

/ I'm struggling with what criteria should or should not be there, and I think it depends on answers to the following questions:
/ - are you comparing IGP protocols or experience with IGP protocol implementations?
/ I think it is mixing together comparisons of both, but then it is attributing all of those characteristics to the protocols, rather than to either the protocols or implementations of the protocols (e.g., "Known to work well" is certainly a protocol implementation characteristic, and is implementation specific (as Mikael Abrahamsson's contrary evidence shows) )
/ The results of comparison of protocols will remain the same unless the protocols change, which doesn't occur often. The results of comparison of implementations of those protocols (e.g., "Known to work well") can change tomorrow with a firmware update.

/ - what level of knowledge of IGPs and IGP selection considerations does the audience have?

/ By not including a number of important IGP selection criteria that need to be considered (e.g., available control plane resources, addressing aggregation boundaries, vendor implementation maturity etc.), it implies that the audience should already have an understanding of the all of the criteria for IGP selection.
/ Yet the inclusion of the "Known to work well" information, without any implementation or deployment detail, seems to be implying that the choice can be so simple that if you don't know what to select, just select one of the protocol combinations with a "Y" in that column. Given how critical an IGP is to the reliable operation of a network, "staying ignorant" of IGP implementation details such as maturity, capacity limitations etc. is dangerous.
/ Regards,Mark.

- Philip

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Sun, 07 Jun 2015 18:20:57 +0300

Hello Mark, Philip

(as an operator with a dual stack network in place) when I first read 
through the draft I found it useful, especially for operators just 
starting out with IPv6. Please find some comments inline

On 06/06/2015 10:17 AM, Mark ZZZ Smith wrote:
> Hi Philip,
>
> So I've spent more than the last 2 hours writing many abandoned 
> emailed responses, if the below sounds a bit short, it's only because 
> I want to send something to get some thoughts out there for consideration!
>
>
> *From:* Philip Matthews <[email-masked]>
> *To:* Mark ZZZ Smith <[email-masked]>
> *Cc:* v6ops list <[email-masked]>
> *Sent:* Saturday, 6 June 2015, 0:27
> *Subject:* Re: [v6ops] Looking for info on IGP choices in production 
> dual-stack networks
>
> >> Victor and I are looking for information on the IGP combinations 
> people are running in their dual-stack networks. We are gathering this 
> information so we can document in our Design Choices draft which IGP 
> choices are known to work well (i.e., people actually run this 
> combination in production networks without issues). The draft will not 
> name names, but just discuss things in aggregate: for example, "there 
> are 5 large production networks that run OSPF for IPv4 and IS-IS for 
> IPv6, thus that combination is judged to work well".
> >>
> > I don't think this is really a good thing to be stating in such 
> abstract terms, that is, at the IGP protocol level. I'd think the 
> successful co-existence or not of IGPs, assuming the protocols 
> themselves aren't broken (e.g., by using the same field value id for 
> two different things), is  implementation dependent, and dependent on 
> which specific revision of the implementation a network has chosen to 
> deploy, and how that network has chosen to deploy it. For example, a 
> literally perfect implementation of OSPF + IS-IS might be "judged to 
> work badly" if deployed badly (by, for example, putting too many 
> routers in the backbone area, overloading control plane resources.)
> >
> > I'm wondering a bit what the fundamental question trying to be being 
> answered is? Is it to try to capture some information on the current 
> popularity of various IGPs used to carrying IPv6 routes, and how 
> popular the use of a single IGP to carry both IPv4 and IPv6 routes 
> is?  What particular question or questions would the reader have that 
> this text is trying to provide an answer for?
> >
> > Regards,
> > Mark.
>
> In the draft we have a table that lists the various combinations of 
> IGPs for IPv4 and IPv6 and gives a few properties for each combination 
> that people might want to consider when selecting a combination. The 
> idea is to give people with less IPv6 knowledge some guidance and 
> perhaps some reassurance when selecting a combination.
>
> / I think my main issue is with this column. I think it is asserting 
> that, for example, all implementations of the combination of OSPFv2 
> for IPv4 and IS-IS for IPv6 are "Known to work well". So if you pick a 
> combination with a "Y" in this column, you'll have no issues 
> regardless of your OSPF and IS-IS implementation choice, or what 
> deployment model you choose (single or multiple area, number of 
> routers in an area/level etc.)
>
>   Originally, Victor and I populated this based on our own experiences 
> and biases, without consulting others.  However, in mid-April Mikael 
> Abrahamsson commented on this table, noting that he has actually run 
> one of the combinations that we marked as "not known to work well".  
> So Victor and I decided that we should be more scientific in 
> populating this column. Hence this survey of what people actually run.
>
> / Rhetorically, for the combination that Mikael has reported, are you 
> going to put "Yes and No" in the "Known to Work Well" column? Or does 
> Mikael's evidence cancel out that evidence that Victor and yourself have?
>
> Do you think the draft should NOT contain this type of information?  I 
> can say that I have found the responses so far to be very interesting, 
> even though it has been just a day so far.
>
> / I'm struggling with what criteria should or should not be there, and 
> I think it depends on answers to the following questions:
>

In my mind, it's about IGP implementations, not IGPs

> / I think it is mixing together comparisons of both, but then it is 
> attributing all of those characteristics to the protocols, rather than 
> to either the protocols or implementations of the protocols (e.g., 
> "Known to work well" is certainly a protocol implementation 
> characteristic, and is implementation specific (as Mikael 
> Abrahamsson's contrary evidence shows) )
>
> / The results of comparison of protocols will remain the same unless 
> the protocols change, which doesn't occur often. The results of 
> comparison of implementations of those protocols (e.g., "Known to work 
> well") can change tomorrow with a firmware update.
>

In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS combination 
for quite a few years now so a firmware update or something along those 
lines, would not really affect the overall "experience"

> / - what level of knowledge of IGPs and IGP selection considerations 

supposedly, the audience is network operators, so a certain degree of 
knowledge should be considered a given.

> / By not including a number of important IGP selection criteria that 
> need to be considered (e.g., available control plane resources, 
> addressing aggregation boundaries, vendor implementation maturity 
> etc.), it implies that the audience should already have an 
> understanding of the all of the criteria for IGP selection.
>

well, yes they should. This document's intended audience is operators 
who are starting out with IPv6, not people starting out with IP networks 
in general.

> / Yet the inclusion of the "Known to work well" information, without 
> any implementation or deployment detail, seems to be implying that the 
> choice can be so simple that if you don't know what to select, just 
> select one of the protocol combinations with a "Y" in that column. 
> Given how critical an IGP is to the reliable operation of a network, 
> "staying ignorant" of IGP implementation details such as maturity, 
> capacity limitations etc. is dangerous.

The choice is not so simple, you're right. It shouldn't come down to 
looking up a table in an Internet draft. I believe that the "IGP Choice" 
table could also be quite useful as it is, even if "Known to work well" 
column can be a bit ambiguous and/or inadequate on its own as as 
selection criterion. That's why it would help if the section is enriched 
with comments and notes about said implementation choices.

regards,
Yannis

>
> / Regards,
> Mark.
>
>
> Or do you have a suggestion for something else useful to say about 
> each combination?  Victor and I feel it might be nice to add more 
> information about each combination, but we don't have any ideas yet on 
> what the "more information" should be.  We would love to hear from 
> anyone who has a suggestion.
>
>
>
>
> - Philip
>
>
>
>
>

--

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 7 Jun 2015 21:00:35 +0000

As an organization which is significantly behind Yannis (and most at IETF), I would like to thank him for and agree with all of his inline comments below.

I would like to add that this document is and will be of more value to those of us just now attempting serious IPv6 deployments.
Although purveying manifold benefits in this regard,  I would like to highlight that this document:

1.       Is unlikely to pick an IGP or specific implementation for those of us currently looking, but should assist us in determining which ones to look at.

2.       Showing viable implementation scenarios helps eliminate one more excuse for not implementing IPv6, which is a major barrier in many large enterprises.

Thanks to the authors and others who have contributed!

Mike

From: v6ops It [mailto:[email-masked]] On Behalf Of Yannis Nikolopoulos
Sent: Sunday, June 07, 2015 11:21 AM
To: Mark ZZZ Smith; Philip Matthews
Cc: v6ops list
Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks

Hello Mark, Philip

(as an operator with a dual stack network in place) when I first read through the draft I found it useful, especially for operators just starting out with IPv6. Please find some comments inline

From: Philip Matthews <[email-masked]><mailto:[email-masked]>
To: Mark ZZZ Smith <[email-masked]><mailto:[email-masked]>
Cc: v6ops list <[email-masked]><mailto:[email-masked]>
Sent: Saturday, 6 June 2015, 0:27
Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks

In our case, we've been running the IPv4/OSPFv2 - IPv6/IS-IS combination for quite a few years now so a firmware update or something along those lines, would not really affect the overall "experience"

supposedly, the audience is network operators, so a certain degree of knowledge should be considered a given.

well, yes they should. This document's intended audience is operators who are starting out with IPv6, not people starting out with IP networks in general.

The choice is not so simple, you're right. It shouldn't come down to looking up a table in an Internet draft. I believe that the "IGP Choice" table could also be quite useful as it is, even if "Known to work well" column can be a bit ambiguous and/or inadequate on its own as as selection criterion. That's why it would help if the section is enriched with comments and notes about said implementation choices.

regards,
Yannis

/ Regards,
Mark.

- Philip

v6ops mailing list

[email-masked]<mailto:[email-masked]>

--

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 07 Jun 2015 23:07:15 +0100

On 06/06/2015 08:17, Mark ZZZ Smith wrote:
> Yet the inclusion of the "Known to work well" information, without any
> implementation or deployment detail, seems to be implying that the choice
> can be so simple that if you don't know what to select, just select one of
> the protocol combinations with a "Y" in that column. Given how critical an
> IGP is to the reliable operation of a network, "staying ignorant" of IGP
> implementation details such as maturity, capacity limitations etc. is
> dangerous.

maybe the root issue we're trying to figure out is what we mean by "Known
to work well".  E.g. ISIS is known to work well as both an ipv4 and ipv6
IGP unless you happen to use Netgear GSM7224 switches, in which case it
doesn't work at all - this hardware flat refuses to forward ISIS frames.

EIGRP and Babel are fine for IPv4 and IPv6 IGP operation but completely
useless the moment you enable mpls, because they're distance vector
protocols and mpls needs a full topology map in order to work.  You could
even argue that there were situations where rip/ripng made sense.  I've
even come across a single instance in my career where rip was arguably a
good choice of routing protocol in a large production network - but do we
really want to push ripv2/ripng as serious general purpose options?  I
doubt it.

Looking at the blanks in the table, I've no doubt that ISIS for ipv4 and
OSPFv3 for ipv6 would be fully appropriate for a production network which
wanted separate IGPs for each protocol for whatever reason (e.g. mpls for
ipv4 but native ipv6).

The "Hard Separation" column can disappear as it's redundant.  If you're
running the same IGP on the same interface to handle two different
protocols, it pretty much a necessity to handle this in the same IGP
instance on each side.  So Hard Separation is equivalent to running the
same protocol on each side.

The "Similar Configuration Possible" column is awkward.  I'm guessing that
this refers to old style and new style cisco ospfv2 configuration grammar.
 Do we really need this?

Quagga OSPFv3 is a bit shaky at times.  Does that qualify as "Known to work
well"?  Quagga ISIS doesn't support MT, so if the rest of the network is
running ISIS-MT, there might need to be a compatibility mechanism in place.

Perhaps as a WG we're heading towards stating truisms here, namely that
(with the potential exception of ospfv3 for ipv4 which is relatively new),
IGPs which carry a particular protocol work well for that protocol, and
that pretty much all competently-written routing stacks can mix-n-match
different IGPs for different protocols without causing problems.

Could I suggest that the existing section 2.3 be dropped and replaced with
either:

1. a couple of paragraphs which state:

- the operator needs to make a choice between whether to run the same IGP
for each protocol or a different IGP.

- it is not unusual practice to run different IGPs for different protocols
and the competence of each routing protocol is often implementation dependent.

- routing protocol choice for IPv6 often boils down to much the same
parameters as for IPv4 which might go from from NOC familiarity to existing
deployment requirements.  There may be caveats, e.g. potentially no
requirement for an ipv6 igp if the network is pure mpls+ldp.

or:

2. an description of each IGP which supports ipv6 with a brief rundown of
capabilities / limitations.

Nick

---

From: Gert Doering <[email-masked]>
Date: Mon, 8 Jun 2015 08:49:55 +0200

hi,

On Sun, Jun 07, 2015 at 11:07:15PM +0100, Nick Hilliard wrote:
> protocols and mpls needs a full topology map in order to work.  

Don't tell that to my MPLS routers.  *TE* needs the topology map, normal
LSPs work perfectly well with distance-vector protocols.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Philip Matthews <[email-masked]>
Date: Mon, 8 Jun 2015 09:39:46 -0400

Mark, Yannis, Michael:

Thanks to all of you for your comments, and especially to Mark for trying to keep us honest :)

Victor and I have not yet had a chance to discuss the responses we are getting back from the survey. However, to answer one of Mark's questions, our plan before we sent out the original emails (to various mailing lists) was to say that a combination was known to work well if we heard of a number of production deployments running that combination, say at least four deployments of reasonable size. So just one deployment was not sufficient grounds to say "known to work well".

Never-the-less, I understand some of Mark's concerns. I don't have an answer right now on how we are going to address them. Give Victor and I a chance to discuss them and then we will reply.

- Philip