Subject: Re: [RADIR] WAIT! last call on draft statement

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Aug 2007 11:09:07 -0400

Jason,

I'm finally getting back to this.

I made all of your suggested change except one.

> 5. Section 5.5
> The text is fine, but I think we are missing one point, which we could
> insert prior to the last sentence. 

> By adopting an IPv6 PI policy, the RIR members are encourging ISPs to
> route the more specific PI site prefix and propagate that prefix
> throughout the DFZ.  This suggests that consuming one or more routing
> slots in DFZ is acceptable in order to solve problems such as renumbering,
> or multi-homing, and may lead to leaking more specifics of PA addresses
> into the DFZ in support of multi-homing with PA addresses.

> maybe we decided this was a slippery slope and we wanted to avoid
> this?  (I can't recall).

I think this is covered elsewhere, i.e., in talking about the demand
for TE, etc.

I also think the above text is a bit to specific to a particular
concern about how the flood gates for more specifics has been opened
with the introduction of the IPv6 PI policy. IMO, this is a short-term
aspect of the overall problem (i.e, I agree with your concern, but I
see it as inevitable that ISPs will be asked to route more prefixes,
for all of the general reasons we've cited throughout the document).

So, the question I have w.r.t. the proposed text is: does this really
describe an issue not adequately covered elsewhere?

Or is the point that needs capturing that everytime an RIR adopts a
policy that implicitely assumes an assignment needs to be routable to
be useable (e.g., for critical infrastructure, anycasting, etc.), it
is contributing to the general problem? ANd if so, do we have evidence
that this is adding a significant amount of prefix, as opposed to just
a little bit?

Thomas

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: Jason Schiller <[email-masked]>
Date: Tue, 28 Aug 2007 11:53:27 -0400 (EDT)

Honestly I would like to defer the answer to your question to Marla, but
let me at least explain what I was thinking when I wrote the text.

We do have a section on the impact of de-aggregation to support
multi-homing and TE.  We also have a section on the impact of
de-aggregation to support provider independence.

Based on some of the earliest discussions with the RADIR it was my
impression that the point of section 5.5 was since the member communities
are pushing for RIR policy to assign IPv6 PI addresses, this will result
in a push to route these IPv6 PI /48 (and even IPv6 PA /48s).  In other
words, RIR policy increases the pressure and likelyhood for the problems
described in the multi-homing, TE, and PI sections to happen.

I think that the origional concers (and rightfully so) about the text was
shifting the focus away from the RIRs making policy to their member
communities.  But I think that rewrite lost the point that the passing of
these policies make it more difficult for providers to maintain that more
specifics should not appear in the DFZ.

Of course I could be mistaken and am misunderstanding Marla's concerns.

So I guess my questions to Marla are:

What were you concerns that you wanted address in section 5.5?
Do we currently have text that addresses these concerns?  
  If so which text?  
  If not can you take another stab at writing some text?

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Tue, 28 Aug 2007, Thomas Narten wrote:

> Date: Tue, 28 Aug 2007 11:09:07 -0400
> From: Thomas Narten <[email-masked]>
> To: Jason Schiller <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [RADIR] WAIT! last call on draft statement
> 
> Jason,
>