Re: [v6ops] EIGRP and the Design Choices draft

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

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

> On 12/05/2015 12:47, Fred Baker (fred) wrote:
>> 
>>> On May 11, 2015, at 5:30 PM, Ted Lemon <Ted.Lemon@nominum.com> 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.
> 
> 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
> 
>> 
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops