Re: [GROW] draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores

[Warren Kumari <[e-mail]>]

On Jul 17, 2012, at 8:48 AM, Michael Behringer (mbehring) wrote:

> Wes, 
> 
> Thanks for your great input and sorry for the delay. In the meantime we have updated our draft to include many of your (and others') comments. (http://tools.ietf.org/html/draft-behringer-lla-only-01). Most importantly, we made it now an informational draft. 
> 
> We believe it is best to keep the drafts separate.

Excellent (actually, I believe that draft-ietf-grow-private-ip-sp-cores lies with the IESG at the moment, and so it kinda has to stay separate)...

> There are important differences between private addresses and link local: One is routed, one is not; one needs to be configured, one not. We added however a xref to draft-ietf-grow-private-ip-sp-cores, because as you rightly comment, they are related.
> 

Cool.

> We still think there is value in draft-behringer-lla-only. Bottom line, we want to provide a document presenting the issues and advantages that allows operators to make an educated decision whether link local is the right approach for them. 
> 
> We'll ask for slots in Vancouver at v6ops and opsec to discuss the new version. 
> 

Excellent, and just to close the loop (so v6ops / grow folk know), you did ask, and we've created a slot on the OpSec agenda  (15min, Wednesday, Aug 1, 13:00 - 15:00, Georgia B) for this...

W
 

> Eric and Michael
> 
>> -----Original Message-----
>> From: George, Wes [mailto:[e-mail]]
>> Sent: 31 March 2012 01:15
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail]; Anthony Kirkham
>> Subject: draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores
>> 	
>> Cross-posting to both lists again because I was unable to attend the v6ops
>> session where draft-behringer was discussed, draft-ietf-grow-private-ip-sp-
>> cores is likely nearing WGLC, and I believe that the issue I raised needs to be
>> addressed before either proceeds. I defer to the chairs of both groups to
>> determine how to manage this across the two groups.
>> 
>> After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and draft-
>> behringer-lla-only again, I am even more convinced that they either need to
>> be merged, or that draft-behringer needs to be abandoned altogether as a
>> bad idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in its
>> discussion of the considerations around private IP usage, but focuses on
>> IPv4, meaning that it *is* incomplete for lack of discussion of IPv6, which is
>> a reality in most SP cores today. Nearly all of the same considerations apply
>> for IPv4 and IPv6 in this case, so there are probably a limited number of
>> changes that would be necessary to cover IPv6 in the Kirkham document.
>> I think that we need to come to some consensus on the recommended
>> behavior on both cases. If the recommendation is different for one versus
>> the other, we need to have a unified and clear articulation as to why this is
>> the case. It may be that the consensus is to not recommend a behavior at all,
>> and simply expand the format of Kirkham's document to cover any IPv6-
>> specific items, since it discusses pros and cons evenly (as an informational
>> doc) rather than recommending anything as a BCP. My vote is to do this, as I
>> am unconvinced that use of LLA represents BCP today, nor should it. I
>> outline some reasons below, but that's probably not as critical if others
>> agree that this is the proper method to proceed with these documents.
>> 
>> 
>> 
>> If draft-behringer is left as a separate document, here are some specific
>> comments:
>> The advantages proposed in draft-behringer are IMO not enough to justify
>> recommending use of LLA.
>> - Smaller routing tables can be achieved through other methods such as
>> setting the interfaces into passive mode in the IGP (so that they are not
>> redistributed into the IGP) and/or not redistributing connected routes.
>> Further, as SPs make great use of interface bundling (LAG), the number of
>> interfaces with IP addresses is dramatically reduced, making the need to
>> pull the point to point interfaces out of the routing table significantly lower.
>> - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 10
>> and 11 discuss this in great detail, and come to the conclusion that it is of
>> limited benefit, and that alternatives exist to protect the infrastructure.
>> - lower configuration complexity - while this is true, it is replaced by
>> additional complexity in troubleshooting. In the case of traces and pings
>> locally on the box, it adds the additional step of requiring the operator to
>> use extended ping and trace commands to specify the exit interface in order
>> to make the ping work (vs simply issuing "ping [ip address]"), and makes it
>> nearly impossible to derive the address of the remote interface without
>> determining the remote side router through some other means and logging
>> into the router to look. (vs practice today of using an IP in the same subnet,
>> usually 1 digit up or down that can be guessed to save time).
>> - less address space: The other draft mentions this as well, in the context of
>> IPv4 where it might make a difference, but this simply is not much of a
>> concern with IPv6. An entire network could be numbered many times over
>> out of one /64.
>> -simpler DNS : Most ISPs operating at the scale where this makes any
>> difference at all have tools to build the DNS forward and reverse entries for
>> their infrastructure automatically based on the router name and interface
>> name extracted from their inventory tools. It's a few bits of scripting, so it's
>> not like having less interfaces in DNS results in any net reduction in work or
>> increase in the possibility of mistakes.
>> 
>> - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed
>> solution to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has
>> little or no implementation. This makes it a hard sell as any sort of
>> recommended solution unless the benefits are much more significant than
>> what is currently discussed in draft-behringer. This has to be a large enough
>> benefit to justify pushing hard on router vendors to implement the feature
>> and SPs to certify and deploy the code, and frankly there are many more
>> important features to consider.
>> 
>> Thanks,
>> 
>> Wes George
>> 
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of [e-mail]
>>> Sent: Wednesday, March 28, 2012 7:21 AM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the Global Routing
>>> Operations Working Group of the IETF.
>>> 
>>>      Title           : Issues with Private IP Addressing in the Internet
>>>      Author(s)       : Anthony Kirkham
>>>      Filename        : draft-ietf-grow-private-ip-sp-cores-00.txt
>>>      Pages           : 15
>>>      Date            : 2012-03-28
>>> 
>>>   The purpose of this document is to provide a discussion of the
>>>   potential problems of using private, RFC1918, or non-globally-
>>>   routable addressing within the core of an SP network.  The discussion
>>>   focuses on link addresses and to a small extent loopback addresses.
>>>   While many of the issues are well recognised within the ISP
>>>   community, there appears to be no document that collectively
>>>   describes the issues.
>>> 
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-core
>>> s-00.txt
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores
>>> -00.txt
>>> 
>>> _______________________________________________
>>> GROW mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/grow
>> 
>> 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.
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
> 

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett