Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC

On 2015-04-06, at 19:10 , Ackermann, Michael wrote:

> HI Fred
> 
> This will be a most beneficial document for those of us contemplating IPv6 deployments.  
> 
> A couple questions: 
> 
> 1.  In Section 2.1.2, second paragraph it states that a network with a large number of link local only interfaces, can just enable an IGP on each router  and not have to assign and trace addresses on each interface.   Does this advantage apply ONLY  to router link local only interfaces? 

Are you asking if the same approach could be taken for host interfaces?  If so, then the question is:  how would you send packets to the host from off-link?  With a router, there is a virtual interface that has a (manually-assigned) global or unique-local address, and so packets can be sent to this address.  Usually hosts do not have such interfaces...

> 
> 2.  Section 2.2.1.   Most of the text in this section seems to suggest that using link-locals for next hop addresses is the best approach.   But there are a couple situations where it is not.   And then at the end it says "Today most operators use GUA's as next hop addresses".      As a neophyte reader I was uncertain what conclusion I should draw?  

That, despite the specs seeming to say that static-routes should use link-local addresses, that in practice it can sometimes cause problems so most operators use GUAs instead.
Most large providers are large corporations with many employees with varying skill sets. These corporations have established procedures that work for IPv4 and most employees try to apply these IPv4 procedures to IPv6. Anything that causes IPv6 to be different than IPv4 means special procedures must be developed and taught to employees. Using link-local addresses in static routes is a difference, so most large providers don't use them.   Things can be different at a smaller provider where differences can be handled more easily.

> 
> 3.  Section 2.3.1.    For many of us EIGRP is the IGP of choice.     Is it not acceptable for this protocol to be included in the  Option Table?  

The thing about EIGRP is that it is not standardized, but is Cisco proprietary. So I suspect that we could only say "Cisco EIGRP does this" and "Cisco EIGRP does that", which is not a typical thing for IETF documents.  I work for Alcatel-Lucent, and I know we do not support EIGRP on our routers because it is not standardized. Most large providers don't use it for that reason.

Fred, as WG chair and as a Cisco employee, could comment further on whether he thinks the document should cover EIGRP.

> 
> 
> Once again,  a very helpful beneficial document!

Thanks!!  The document started out as my attempt to document many of the questions I had when I first started to design IPv6 networks. I also credit my co-author Victor, who added many useful insights gained from deploying IPv6 when he worked for Rogers Communications.

- Philip

> 
> Thanks
> 
> Mike
> 
> 
> 
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com
> Sent: Sunday, April 05, 2015 2:00 PM
> To: v6ops@ietf.org
> Subject: [v6ops] draft-ietf-v6ops-design-choices WGLC
> 
> This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-design-choices.  
> Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
> 
> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
> 
> _______________________________________________
> 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.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 