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

["t.petch" <[e-mail]>]

----- Original Message -----
From: "George, Wes" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, March 31, 2012 1:14 AM
> 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.
<tp>
Disagree.  As you say, the grow draft is more or less complete, more or less
ready for WGLC.  And it has taken the IETF two years to get to this state.

IPv6 is different.  We probably know little as yet as to how it works or how it
should.

Adding IPv6 would put this work back a year or two, and given that GROW is not
the most lively of growps, it may never happen.

Get the grow draft out as an RFC while it is still of value to its audience.

Then contemplate a -bis with IPv6 if there is sufficient enthusiasm in a WG to
do so.

Tom Petch






> 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-cores-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
>
>