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

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Sat, 06 June 2015 07:17 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 84A501AD35E for <v6ops@ietfa.amsl.com>; Sat, 6 Jun 2015 00:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.802
X-Spam-Level: ***
X-Spam-Status: No, score=3.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 bVzC_6FnJZ_t for <v6ops@ietfa.amsl.com>; Sat, 6 Jun 2015 00:17:56 -0700 (PDT)
Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D461AD35D for <v6ops@ietf.org>; Sat, 6 Jun 2015 00:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1433575075; bh=RqGLY27LaaaznInpEkVviGEqrRNx42QQupUgLn7gHZM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=pXy4cIZ0kv3jlyC9RlvtpYNEPvUT16VR6Bwkv/qjOSOgH/XKZiFL5WOsfnmzQbBFEh+0UhWtjBknyz0i2hhfa9DqPz97z0wVECO3uxGjfvzRfPr08sTG6l5c0Hlbmj6a3meqfECZwkpPSB+DhTcTRjQbJwTmPBpMkB3U7fWgbTPJHA+GFUKZ3cP+sbOyClV2sVVeYQRU+4/el27Up45ub0bNO9MUv3bdlkMZ6waeWVjTzZtCZahSTg85xNTpoMR+P5CjlXIOrww4veC8kppQlJSzN4OEwSoJvQ1uMucJ1pxAalP5Zn3VKh68X3IWxflZlAkYMXbaSxjOX3jSWIjxhg==
Received: from [98.139.170.181] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jun 2015 07:17:55 -0000
Received: from [98.139.212.215] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jun 2015 07:17:55 -0000
Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 06 Jun 2015 07:17:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 294364.67595.bm@omp1024.mail.bf1.yahoo.com
X-YMail-OSG: vMDdLMAVM1mKXrzvPi05YHlKHX7YE4KHx6ayjZWhR3If4hUlgmL.dpRVFodJVc. P.9ee.PnaFZtEAHGthF729iDtedLiRZx_KRfEFUT9r9wj7jPK5.VN9e8VNSQU3cGvxTW4kQHKjqe 0G4zNa71kxpFFYZFekykTZSZ6Q6xfiUFkXKLz8ri1UW5jyMwmoolXTrElQ8Rdti9kccFShBFUkKg .L2eo0Gbw1.Xz5Mo6eShX.qgzFstXRnm3Vkmg8AeitBEbxbHBqanXjL1wpFrQ1Utdm7iK.s_XyQ7 0IvIjCYQelHyy1zmnqgx8hndj37BQZcme2xJqCeS4MDMdpPTx7lYVsrCegGMIok_Uwyfkf5Fl776 nct90szBEDmePLptceqommBh1WQCoDKDBBd.ML_uBSp9Of5d0gnjd0npKM69VCqQQ5LYLaeZwzx2 fi1JRT2Mc4dMoWHahVq7FmqMJdZ3uCZ.dYqAzh7BkFLxZ7Ou.Wt9TsLKyKRwidMmDeN9GrCKAiT7 bqmxfx5WcLrckQdFyGA--
Received: by 76.13.27.197; Sat, 06 Jun 2015 07:17:54 +0000
Date: Sat, 6 Jun 2015 07:17:41 +0000 (UTC)
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Philip Matthews <philip_matthews@magma.ca>
Message-ID: <1674874883.7129828.1433575061194.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <D5A1FD44-0ECD-41CE-AEC6-7A85C80D465E@magma.ca>
References: <D5A1FD44-0ECD-41CE-AEC6-7A85C80D465E@magma.ca>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_7129827_990964408.1433575061184"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/BG4V0G1gPqAmUIb-ge8juAlxB5Y>
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
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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: Sat, 06 Jun 2015 07:17:58 -0000

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?
/ 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.

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