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

[Yannis Nikolopoulos <[e-mail]>]

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 <[e-mail]>
> *To:* Mark ZZZ Smith <[e-mail]>
> *Cc:* v6ops list <[e-mail]>
> *Sent:* Saturday, 6 June 2015, 0:27
> *Subject:* Re: [v6ops] Looking for info on IGP choices in production 
> dual-stack networks
>
> [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:
> >> 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.
>
> 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?
>
> 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:
>
> / - are you comparing IGP protocols or experience with IGP protocol 
> implementations?
>

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 
> does the audience have?
>

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
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops


--