Re: [v6ops] EIGRP and the Design Choices draft

Ackermann, Michael wrote:
> 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.
+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.

>
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] 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
>
> On 12/05/2015 03:38, Philip Matthews wrote:
>> 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.
>
> 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
>
> _______________________________________________
> 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.
>
>