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

Philip Matthews <philip_matthews@magma.ca> Mon, 08 June 2015 13:40 UTC

Return-Path: <philip_matthews@magma.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AB21A8788 for <v6ops@ietfa.amsl.com>; Mon, 8 Jun 2015 06:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUL7f6t7rHIt for <v6ops@ietfa.amsl.com>; Mon, 8 Jun 2015 06:39:55 -0700 (PDT)
Received: from tor-smtp-04.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2944A1A8785 for <v6ops@ietf.org>; Mon, 8 Jun 2015 06:39:53 -0700 (PDT)
Received: from [24.114.105.18] (helo=[172.20.10.4]) by tor-smtp-04.primus.ca with esmtpa (Exim 4.84) (envelope-from <philip_matthews@magma.ca>) id 1Z1xHK-0003MJ-5Y; Mon, 08 Jun 2015 09:39:51 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-3-197053811
From: Philip Matthews <philip_matthews@magma.ca>
In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDF63E3@PWN401EA160.ent.corp.bcbsm.com>
Date: Mon, 8 Jun 2015 09:39:46 -0400
Message-Id: <083A228E-347F-4F70-82DB-68B4EEF2966D@magma.ca>
References: <D5A1FD44-0ECD-41CE-AEC6-7A85C80D465E@magma.ca> <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com> <55746159.2080607@otenet.gr> <4FC37E442D05A748896589E468752CAA0CDF63E3@PWN401EA160.ent.corp.bcbsm.com>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>, Yannis Nikolopoulos <yanodd@otenet.gr>, Michael Ackermann <MAckermann@bcbsm.com>
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.105.18]
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/3TADzccdhHil7W_5Zr1-ocMz0C0>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] Looking for info on IGP choices in production dual-stack networks
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2015 13:40:00 -0000

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



On 2015-06-07, at 17:00 , Ackermann, Michael wrote:

> 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:v6ops-bounces@ietf.org] 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
> 
> 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 <philip_matthews@magma.ca>
> To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au> 
> Cc: v6ops list <v6ops@ietf.org> 
> 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> -- 
> 
> 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.
>