Subject: [v6ops] EIGRP and the Design Choices draft

From: Philip Matthews <[email-masked]>
Date: Mon, 11 May 2015 11:38:11 -0400

Folks:

Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP.

To do this, we are looking for information on dual-stack networks that run EIGRP.

Specifically we want to get feedback on production dual-stack networks that run EIGRP. We are interested in any of the following combinations:

* EIGRP for both IPv4 and IPv6
* EIGRP for IPv4 and OSPF/ISIS for IPv6
* OSPF/ISIS for IPv4 and EIGRP for IPv6

If you know of any such networks, then please email either Victor or myself. (If you are concerned about doing this, then you could email one of the chairs instead).

Our goal is to get answers to the following questions:
1) Is this combination known to work well -- in other words, have multiple production networks used it without problems?
2) Why was this particular dual-stack combination chosen? 
3) Any comments or pieces of advice that you would like to pass on?

Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2015 08:36:40 +1200

> Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP.

If I'm not mistaken, that's a proprietary protocol that isn't even described in an
RFC (although there seems to be a stalled draft under consideration as an
Independent Submission RFC). While I don't object to describing reality, I think
you need to explain *why* it's appropriate to do this in an IETF stream draft.

If you go ahead, I would suggest putting this topic in an appendix.

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 11 May 2015 23:17:43 +0000 (UTC)

From: Brian E Carpenter <[email-masked]>
 To: Philip Matthews <[email-masked]>; v6ops list <[email-masked]> 
 Sent: Tuesday, 12 May 2015, 6:36
 Subject: Re: [v6ops] EIGRP and the Design Choices draft

/ Regardless of whether or not EIGRP makes it into the draft, it could be worth mentioning that the deployment of IPv6 is also an good opportunity to deploy a non-proprietary IGP, and perhaps at a later date migrate IPv4 to using the new IGP too if it supports multiple protocol families.

    Brian

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 May 2015 00:26:51 +0000

> On May 11, 2015, at 1:36 PM, Brian E Carpenter <[email-masked]> wrote:

How would you characterize Babel? Read the header on page 1 of RFC 6126 before responding. This difference, as near as I can tell, is that the draft made it through the ISE to RFC. That and the fact that a whole lot more people use EIGRP (enough to have it requested during a WGLC discussion) than use Babel.

draft-boutier-babel-source-specific-00.txt
draft-chroboczek-babel-doesnt-care-00.txt
draft-chroboczek-babel-extension-mechanism-04.txt
draft-chroboczek-babel-security-considerations-00.txt
draft-mrw-homenet-rtg-comparison-02.txt

https://tools.ietf.org/html/rfc6126
6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format:
     TXT=99833 bytes) (Updated by RFC7298) (Status: EXPERIMENTAL)

https://tools.ietf.org/html/rfc7298
7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic
     Authentication. D. Ovsienko. July 2014. (Format: TXT=128503 bytes)
     (Updates RFC6126) (Status: EXPERIMENTAL)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 May 2015 20:30:47 -0400

To put an even finer point on it, one of the big problems with EIGRP at this point is that although that are many interoperating implementations, they were implemented using a reference implementation, not a spec, so there is no spec that got the kind of interop testing that multiple independent implementations would have given us. Getting to that now would be very difficult, since there's no real incentive for anybody to do a complete new implementation now.  So while indeed it might be good to write down the spec for posterity and the benefit of sharing experience, I don't think it'd make a lot of sense as an IETF standard.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 May 2015 20:33:36 -0400

> How would you characterize Babel? Read the header on page 1 of RFC 6126 before responding. This difference, as near as I can tell, is that the draft made it through the ISE to RFC. That and the fac…

Babel has two interoperating implementations that were done independently, the first of which produced RFC 6126, and the second of which interoperates with it after being implemented using RFC 6126 as a specification. So from an IETF perspective it is actually farther along, despite the fact that what you say about EIGRP is quite true.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 12 May 2015 00:36:31 +0000

As perhaps one of the individuals responsible for this idea.   I realize EIGRP is proprietary protocol and therefore possibly not appropriate for IETF consideration.  
But the reason I would even ask, is that EIGRP deployment within Enterprise/Corporate Networks, is nearly ubiquitous.   These are the same large networks that need guidance and motivation to get serious about IPv6 deployment.   Optimal configuration of the primary routing protocol, in dual stack environments,  is likely to be a significant success factor.   Providing related information and experiences could give us E/C Networks one less reason to delay IPv6 deployments, which is what most of us are doing currently.  
So although I understand the potential inappropriateness,  please consider this a call for help from those of us trying to evangelize IPv6 in corporate networks.    

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, May 11, 2015 4:37 PM
To: Philip Matthews; v6ops list
Subject: Re: [v6ops] EIGRP and the Design Choices draft

> Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP.

If I'm not mistaken, that's a proprietary protocol that isn't even described in an RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I think you need to explain *why* it's appropriate to do this in an IETF stream draft.

    Brian

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: "Howard, Lee" <[email-masked]>
Date: Mon, 11 May 2015 20:43:38 -0400

From: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Reply-To: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 11, 2015 at 7:17 PM
To: Brian Carpenter <[email-masked]<mailto:[email-masked]>>, Philip Matthews <[email-masked]<mailto:[email-masked]>>, 'IPv6 Operations' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] EIGRP and the Design Choices draft

________________________________
From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
To: Philip Matthews <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, 12 May 2015, 6:36
Subject: Re: [v6ops] EIGRP and the Design Choices draft

<hat off>
IETF documents talk about lots of things that aren’t IETF protocols.  There have been requests in the WG to include consideration of this protocol. So, as you say, let’s describe reality. Why do we need to explain why this protocol is being included, and not explain why all others are (or aren’t) being included?

Please clarify. What makes EIGRP a poor design choice for an IPv6 network?

</hat off>

Lee

    Brian

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 May 2015 20:44:54 -0400

> Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP.

Based on the conversation thus far, I have to ask: is this the homenet routing design team document, or some other document I hadn't heard of before? If it's for homenet, I think asking about corporate infrastructure choices is a bit off topic.  If it's for something else, then I tend to agree that the question about EIGRP is worth asking, although my observations about its appropriateness as a future IETF standard still stand.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 May 2015 00:47:08 +0000

> On May 11, 2015, at 5:30 PM, Ted Lemon <[email-masked]> wrote:
> 

My point on RFC 6126 is that it’s not an IETF standard either, yet homenet appears to be deciding to standardize on it.

I don’t know the status of Donnie Savage’s draft (https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the EIGRP data formats are well known, the algorithms are well known, and if the vector metric patent and the DUAL patent haven’t expired, they're about to. As you say, there are multiple implementations around. What I’m looking at is a request for commentary in a draft making comments on the operational use of routing protocols.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 May 2015 00:49:37 +0000

> On May 11, 2015, at 5:36 PM, Ackermann, Michael <[email-masked]> wrote:
> 
> But the reason I would even ask, is that EIGRP deployment within Enterprise/Corporate Networks, is nearly ubiquitous.   These are the same large networks that need guidance and motivation to get serious about IPv6 deployment.

A web page dated 2008:

http://www.techtutorials.net/articles/ipv6_training_cisco_how_to_enable_ipv6_eigrp.html

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2015 13:06:38 +1200

> My point on RFC 6126 is that it’s not an IETF standard either, yet homenet appears to be deciding to standardize on it.

Well yes, but it's open source and there has been a serious discussion about moving
it to the standards track, with Alia describing to the homenet WG what that would
involve.

Again: I'm not against documenting reality, with reasonable justification.
But it has to be carefully positioned vs standardised solutions. That's why
I suggested an appendix. So we'd end up with something like

2.3.1.  IGP Choice

   One of the main decisions for an IPv6 implementer is the choice of
   IGP (Interior Gateway Protocol) within the network.  The primary
   options are OSPF [RFC2328] [RFC5340] or IS-IS [RFC5120] [RFC5308],
   though some operators may consider RIP [RFC2080] or non-standardized
   protocols.  Here we limit our discussion to the pros and cons of OSPF
   vs. IS-IS. Appendix A discusses the widely used non-standardized
   EIGRP protocol.

     Brian

---

From: Philip Matthews <[email-masked]>
Date: Mon, 11 May 2015 21:35:57 -0400

In response to Brian's suggestion, I thought I should let everyone know what the authors' current plan is for the IGP section of the Design Choices draft:

1) Include EIGRP in the table in section 2.3.1
2) Gather deployment data for all combinations of the three protocols (EIGRP, ISIS, OSPF) and use this to drive the "known-to-work-well" column of the table (*)
3) Gather deployment data on the use of RIP and RIPng and document this in a new section (**)
4) Gather comments on gotchas and similar, and consider adding these to the draft.

(*) This addresses another WGLC comment (from Mikael Abrahamsson). Right now, a combination is flagged as "known to work well" if Victor or I have heard of someone using that combination. But we did not make a significant effort to gather this information and did not consider "how significant" the usage was. We now plan to do that.

(**) RIP is not as dead as some might think. My company (Alcatel-Lucent) recently added support for RIPng due to customer requests. Victor and I plan to  to gather info on who is using RIP and RIPng and where, and then add this to the draft.

Brian has proposed a slight different approach. See his email below.

Comments on the two approaches are welcome.

Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 11 May 2015 22:03:56 -0400

Let me add a additional comment on this discussion as an author of the document.

From the perspective of updating the document, the fact that EIGRP is not standardized is not really a problem. The authors simply plan to gather data on how it is deployed. We didn't really "use" the fact that OSPF and ISIS are standardized when writing the current version of the draft.

So I think the only question is whether it is "appropriate" to include EIGRP in the document. I personally don't know of any IETF document that says "thou shall only discuss standardized protocols in IETF documents". But perhaps others do. Or perhaps this is something that can be left to "WG discretion". We certainly have a number of people with some heavy-duty IETF experience in on this thread.

- Philip

---

From: t.petch <[email-masked]>
Date: Tue, 12 May 2015 09:06:40 +0100

----- Original Message -----
From: "Philip Matthews" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "Fred Baker
(fred)" <[email-masked]>; "Ted Lemon" <[email-masked]>; "Michael
Ackermann" <[email-masked]>
Sent: Tuesday, May 12, 2015 3:03 AM

Let me add a additional comment on this discussion as an author of the
document.

>From the perspective of updating the document, the fact that EIGRP is
not standardized is not really a problem. The authors simply plan to
gather data on how it is deployed. We didn't really "use" the fact that
OSPF and ISIS are standardized when writing the current version of the
draft.

So I think the only question is whether it is "appropriate" to include
EIGRP in the document. I personally don't know of any IETF document that
says "thou shall only discuss standardized protocols in IETF documents".
But perhaps others do. Or perhaps this is something that can be left to
"WG discretion". We certainly have a number of people with some
heavy-duty IETF experience in on this thread.

<tp>

EIGRP is indeed very widely used in the Enterprise arena and I let out a
small cheer when I saw the I-D about it; and Ivery much hope that that
I-D becomes an RFC.

As to its inclusion in the Design Choices, I think the answer will stem
from the question that prompted this thread.  If enough people mail in
their experiences, then we have the data to include it in that I-D.  If
we do not get the response, then we are not qualified to do so and so
should, at most, make a passing reference to its existence (and that
EIGRP I-D/RFC).

Since there is, in general,  no IPv6 available in my small, offshore
island, I can offer no experience myself:-(

Tom Petch

- Philip

On 2015-05-11, at 21:06 , Brian E Carpenter wrote:

>>> To put an even finer point on it, one of the big problems with EIGRP
at this point is that although that are many interoperating
implementations, they were implemented using a reference implementation,
not a spec, so there is no spec that got the kind of interop testing
that multiple independent implementations would have given us. Getting
to that now would be very difficult, since there's no real incentive for
anybody to do a complete new implementation now.  So while indeed it
might be good to write down the spec for posterity and the benefit of
sharing experience, I don't think it'd make a lot of sense as an IETF
standard.
>>
>> My point on RFC 6126 is that it’s not an IETF standard either, yet
homenet appears to be deciding to standardize on it.
>> I don’t know the status of Donnie Savage’s draft
(https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the
EIGRP data formats are well known, the algorithms are well known, and if
the vector metric patent and the DUAL patent haven’t expired, they're
about to. As you say, there are multiple implementations around. What I’
m looking at is a request for commentary in a draft making comments on
the operational use of routing protocols.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 May 2015 08:14:48 -0400

> My point on RFC 6126 is that it’s not an IETF standard either, yet homenet appears to be deciding to standardize on it.

I did actually speak to that, and notice that you haven't disputed what I said, yet don't seem to agree with my conclusion. That said, if we are talking about homenet, the proponents of Babel there have two really specific reason for preferring babel to EIGRP. The first is the one I have:it is not an open standard, and isn't likely to become one. The second is that it doesn't meet their requirements, particularly with respect to its handling of lossy links. It would be good to document that it doesn't meet their requirements, but doesn't seem a likely candidate whether it is specifically analyzed in the document or not. 

It is also worth noting that homenet isn't appearing to decide on a routing protocol, and that's why we have a design team. There are participants in homenet who have stated good reasons for using Babel, but the working group as a whole does not have consensus on the question.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 May 2015 08:21:44 -0400

On May 12, 2015, at 8:14 AM, Ted Lemon <[email-masked]> wrote:
> 
> The first is the one I have:it is not an open standard, and isn't likely to become one.

That was supposed to say "have already explained."  Typing on the iPad is difficult due to registration issues. :/

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 12 May 2015 12:26:33 +0000

<snip>
> That said, if we are talking about
> homenet ... <snip>

I don't see that draft-ietf-v6ops-design-choices has any applicability to homenet. The design-choices draft states up front that the applicable network is one being designed (i.e., "managed") by someone "who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6". That puts homenet way, way out of scope. IMO, it's really about enterprise networks.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 May 2015 08:47:40 -0400

> I don't see that draft-ietf-v6ops-design-choices has any applicability to homenet. The design-choices draft states up front that the applicable network is one being designed (i.e., "managed") by so…

Great, thanks for answering that. I couldn't get the context from the subject line.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2015 08:19:05 +1200

> says "thou shall only discuss standardized protocols in IETF documents".

And I very carefully didn't say that, because it isn't true.

What I suggested is: put discussion of a non-standardized proprietary solution
in an appendix, to recognize and document reality without endorsing it.

> "WG discretion". 

Well, the WG can propose what it wants, and it's the IETF Last Call that
verifies.

   Brian

> We certainly have a number of people with some

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 May 2015 21:05:39 +0000

> On May 12, 2015, at 5:14 AM, Ted Lemon <[email-masked]> wrote:
> 
> I did actually speak to that, and notice that you haven't disputed what I said, yet don't seem to agree with my conclusion. That said, if we are talking about homenet, the proponents of Babel there have two really specific reason for preferring babel to EIGRP.

I'm not disputing Babel. I'm not disputing Homenet. The conversation is about neither.

We have a request on the table for a document being developed in v6ops about routing deployment to comment on a routing protocol that is widely used in enterprise networks. Brian is pushing back because the protocol is not on the IETF standards track and is not an RFC. I can tell you that it was posted as an Internet Draft, and that https://datatracker.ietf.org/doc/draft-savage-eigrp says it is in ISE review. Babel came up because it followed exactly that path to (experimental) RFC publication. Why draft-savage-eigrp is not an RFC is something I don't know. Ask Nevil.

I do know that there is an internet draft, and the multiple implementations of the protocol were done from a book written about it before the draft was written (available from Amazon). To me, that is largely comparable to the Babel experience, which is why I brought it up. I'm questioning the ferocity behind Brian's pushback. I think it is unwarranted.

If we're documenting deployment experience with common routing protocols, it's one of them. Is this about the purity of the RFC series, or the relevance to operational networks? If it is about routing in operational networks, why would we exclude discussion of protocols in current use in operational networks?

As to Brian's suggestion of putting EIGRP into an appendix, I'm not the author, but if I were, I would wonder how he wanted me to do that. The request is to add one or more rows (the current draft mentions "RIP [RFC2080] or non-standardized protocols") to
   +--------+--------+---------+---------+------------+----------------+
   | Option |  IGP   | IGP for |  Known  |    Hard    |    Similar     |
   |        |  for   |   IPv6  | to work | separation | configuration  |
   |        |  IPv4  |         |   well  |            |    possible    |
   +--------+--------+---------+---------+------------+----------------+
   |        |        |         |         |            |                |
   +--------+--------+---------+---------+------------+----------------+
   |   a    | IS-IS  |  IS-IS  |   YES   |     -      |      YES       |
   +--------+--------+---------+---------+------------+----------------+
   |   b    | IS-IS  |  OSPFv3 |    -    |    YES     |       -        |
   +--------+--------+---------+---------+------------+----------------+
   |        |        |         |         |            |                |
   +--------+--------+---------+---------+------------+----------------+
   |   c    | OSPFv2 |  IS-IS  |   YES   |    YES     |       -        |
   +--------+--------+---------+---------+------------+----------------+
   |   d    | OSPFv2 |  OSPFv3 |   YES   |    YES     |      YES       |
   +--------+--------+---------+---------+------------+----------------+
   |        |        |         |         |            |                |
   +--------+--------+---------+---------+------------+----------------+
   |   e    | OSPFv3 |  IS-IS  |    -    |    YES     |       -        |
   +--------+--------+---------+---------+------------+----------------+
   |   f    | OSPFv3 |  OSPFv3 |    -    |     -      |      YES       |
   +--------+--------+---------+---------+------------+----------------+ .

along the lines of

   +--------+--------+---------+---------+------------+----------------+
   |   g    | RIPv2  |  RIPng  |    -    |    YES     |      YES       |
   +--------+--------+---------+---------+------------+----------------+
   |   h    | EIGRP  |  EIGRP  |   YES   |     -      |      YES       |
   +--------+--------+---------+---------+------------+----------------+ .

and a bibliographic reference (presumably to either the book or the internet draft, if we can’t get it published as an RFC) indicating what the acronym EIGRP stood for.

https://tools.ietf.org/html/rfc2080
2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format:
     TXT=47534 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc2453
2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT=98462
     bytes) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056)
     (Status: INTERNET STANDARD)

https://datatracker.ietf.org/doc/draft-savage-eigrp
https://tools.ietf.org/html/draft-savage-eigrp
     Enhanced Interior Gateway Routing Protocol. D Savage, 2014-10-13

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2015 10:11:09 +1200

Fred,

> I do know that there is an internet draft, and the multiple implementations of the protocol were done from a book written about it before the draft was written (available from Amazon). To me, that…

I didn't intend to be ferocious ;-).

Let's see a draft with this added. If there's no support for it being in an appendix,
I lose. But I would like to see some words recording as a matter of fact that
EIGRP isn't an IETF protocol. We all know how marketing people use RFCs.

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 13 May 2015 02:15:44 +0000 (UTC)

I've seen it as applicable to managed networks, including ISP networks. Having worked on both enterprise and ISP networks, I don't see any thing in there that is an exclusive consideration for one or the other types of networks.
The draft doesn't really describe much context other than saying that the considerations apply to single or dual stack IPv6 networks. So I think a bit of expansion on the type of networks it applies to would be useful.
I'd suggest it applies to "managed" networks, where deployment decisions are either unavoidable or there can be operational advantages in considering various methods of achieving the same goal. I think it would also be worth mentioning that in an automated network (I wouldn't specifically mention a home network, but that is an example of one) it may be useful to override the defaults, and in that case the issues discussed should then be considered.
Regards,Mark.

     From: "STARK, BARBARA H" <[email-masked]>
 To: Ted Lemon <[email-masked]>; Fred Baker (fred) <[email-masked]> 
Cc: v6ops list <[email-masked]>; Philip Matthews <[email-masked]> 
 Sent: Tuesday, 12 May 2015, 22:26
 Subject: Re: [v6ops] EIGRP and the Design Choices draft
   
<snip>

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 May 2015 16:57:29 +0200

Hi,

> As to Brian's suggestion of putting EIGRP into an appendix, I'm not the author, but if I were, I would wonder how he wanted me to do that. The request is to add one or more rows (the current draft…

This approach works for me - have it in the table, and maybe add a footnote
that explains that EIGRP is not an IETF standard but a vendor protocol.

"Operational useful content" in an operational RFC trumps "purity" for me.

(I'm actually one of the people that use EIGRP for IPv4 and have also
used it for IPv6, and prefer it to OSPF or ISIS any day)

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: Ray Hunter <[email-masked]>
Date: Sat, 16 May 2015 14:56:24 +0200

> So although I understand the potential inappropriateness,  please consider this a call for help from those of us trying to evangelize IPv6 in corporate networks.
+1

IMHO Having the IETF recommending proprietary protocols is entirely 
different from documenting operational experience of whether they will 
work nicely together with IETF standard protocols or not, and/or how to 
migrate to/ introduce said "standard track" solutions in place of the 
proprietary one.

My most recent project just turned off the last EIGRP connection to a 
particular data centre (replaced with eBGP), almost twenty years after I 
first introduced EIGRP there ..... and I know there's plenty of EIGRP 
still around elsewhere.