Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

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

----- Original Message -----
From: "Owen DeLong" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: "Tore Anderson" <[e-mail]>; "Brian E Carpenter"
<[e-mail]>; "V6 Ops List" <[e-mail]>
Sent: Friday, May 30, 2014 6:18 PM
>
>> Yes, we need to change the fundamental way we deal with routing and
come
>> up
>> with a more scalable solution than the current everyone knows every
>> prefix
>> model.
>>
> <tp>
> Owen,
>
> yes, and that is what the RRG did.  It came up with two solutions and,
> being an IRTF and not an IETF WG, one solution was declared
appropriate
> while the other (LISP) is being developed by the IETF:-)

Not sure why your mailer can’t do quoting correctly, but I’ve fixed it
here
for you.

<tp>
Sorry about that, my mailer doesn't cope  with quoted-printable so if we
could if we could just eliminate all those funny European characters and
live with USASCII - sigh, perhaps not

Meanwhile ...

>
> The key to both is that while the number of prefixes is likely to grow
> beyond the capacity of routers, the number of locations involved is
> likely to remain much smaller so that routing will be based on
> locations, with a mapping from prefix to location prior to routing.

LISP is way over-complicated for the problem space in question, though
it’s
probably the right general idea.

In reality, what is needed is a simpler solution probably related to
doing
the IDR portion of routing on destination ASN. Unfortunately, we don’t
have
a good way in the current protocol to encode the destination ASN onto
the
packet. My thinking is that a revised 44 octet header would do the trick
and
that during the transition process, having routers that border between
44-octet header capable zones and non-44-octet header capable zones
would
perform the header replacement. Unfortunately, this has PMTU-D issues
which
I haven’t figured out how to address yet.

<tp>

... I commend RFC 6115 to you, although the I-Ds that led up to it are
perhaps better. And there is the RRG list archive (which makes v6ops
look like a low volume list:-).

A lot of options were explored, ILNP got the WG chair's recommendation,
LISP became an IETF WG; I liked SEAL (and am always glad to read what
Fred has to say) and I think that Ivip never got the attention it
deserved.

Between the IAB report in 2006 and the RFC in 2011, a lot of work went
into this area, with results as above.  Multi-homing, PI v. PA, PMTUD,
tunnels, NAT, IPv6 rate of migration, DFZ churn, the impact of 2B cell
phones on IPv6, network API, ... all of life is there and I suspect that
revisting the topic will bring little new (pace a revision of the
predicted chip capacity and hence a longer life for BGP4))

Tom Petch


Owen

>
> All in the RRG archives.
>
> Tom Petch
>
> However, at any likely growth rate, if we actually start working on
the
> problem
> instead of simply inflicting limitations and calling it handled, then
we
> have
> time to address the issue in IPv6. Hopefully the RRG will wake up and
> start
> addressing this issue. For now, it is out of scope for v6ops as I
> understand
> the WG charter.
>
>> And I think that every SME who has lost business with the
> unreliability
>> of their ISP will want multi-homing and will think that with IPv6 and
> PI
>> the constraints have gone, and the number of such SMEs can only
> approach
>> 10M over time.
>
> All the more reason this issue needs to get addressed instead of
> ignored.
>
>> So, Brian is spot on, and just as the IETF did little about IPv4
>> addresses running out until the event loomed large, so I expect
> history
>> to repeat itself with the growth of PI in IPv6.
>
> He’s somewhat right about the problem. He’s absolutely wrong in
> believing that
> the current limitations are a solution.
>
> Owen
>