Subject: [rrg] NANOG44 session on current IP address challenges

From: Lixia Zhang <[email-masked]>
Date: Mon, 20 Oct 2008 14:55:57 -0700

There was a joint NANOG/ARIN session last week on
   "Moderated Panel: What Would Jon have Done About the Addressing
    Challenges Currently Facing Us?"

this was the last session on NANOG-44 agenda
    http://www.nanog.org/meetings/nanog44/agenda.php
All talk slides are online, and I thought they might be interesting to  
at least some RRG people
My talk is at
http://www.nanog.org/meetings/nanog44/presentations/Wednesday/Zhang_Wed_N44.pdf

FYI,
Lixia
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 20 Oct 2008 16:31:40 -0700 (PDT)

"13 years have passed How well does the above still apply / not apply today?"

IMO points on slides 8 and 9 applied from day one as they remain today.

Thank you,

Peter

--- On Mon, 10/20/08, Lixia Zhang <[email-masked]> wrote:

> From: Lixia Zhang <[email-masked]>
> Subject: [rrg] NANOG44 session on current IP address challenges
> To: [email-masked]
> Date: Monday, October 20, 2008, 5:55 PM

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2008 13:05:20 +1300

Lixia,

Your talk asked
"13 years have passed
How well does the above
still apply/not apply today?"

I fear that the answer is 100%. Was there any clear outcome from
the discussion?

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Oct 2008 17:25:44 -0700

> I fear that the answer is 100%. Was there any clear outcome from

Van said NAT was a bad idea and urged people to not use it as a  
solution.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Mon, 20 Oct 2008 17:54:26 -0700

|> Your talk asked
|> "13 years have passed
|> How well does the above
|> still apply/not apply today?"
|>
|> I fear that the answer is 100%. Was there any clear outcome from
|> the discussion?
|
|Van said NAT was a bad idea and urged people to not use it as a  
|solution.

Yet, what other solutions are there?  13 years have passed and renumbering
is still verboten.  13 years have passed and the only possible solutions
that we have in hand all are either a form of NAT or incorporate NAT.

The only alternative is to perform the brain surgery on the architecture to
allow dynamic renumbering, and no one wants to bite that off either.

Our choices are to NAT or renumber, and we seem unwilling to choose either.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Oct 2008 18:00:00 -0700

Of course, they proposed no solutions.

Dino

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 20 Oct 2008 19:53:49 -0700

> Our choices are to NAT or renumber, and we seem unwilling to choose  

I would like to add another solution, map-and-encap (without  
renumber), which
seems holding best promise to me.

Lixia

---

From: "Tony Li" <[email-masked]>
Date: Mon, 20 Oct 2008 22:33:38 -0700

|I would like to add another solution, map-and-encap (without  
|renumber), which
|seems holding best promise to me.

How does that reduce the table size?

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 20 Oct 2008 23:20:30 -0700

> How does that reduce the table size?

that will take a slide deck to explain.
We are currently working on that for a presentation for Minneapolis  
(and a draft too to pass your criterion for a slot request:)

Lixia

---

From: Robin Whittle <[email-masked]>
Date: Tue, 21 Oct 2008 18:09:13 +1100

Hi Tony,

In "Re: [rrg] NANOG44 session on current IP address challenges", you

> How does that reduce the table size?

Many or most end-user networks have micronets (roughly equivalent to
LISP EID prefixes).  These are not in the global BGP routing table.

Each Mapped Address Block (MAB) is advertised in the BGP routing
table.

Each MAB contains many (ideally thousands to millions) of micronets.

MABs are required so that OITRDs (Open ITRs in the DFZ - similar to
LISP Proxy Tunnel Routers) can collect packets addressed to these
micronets and then tunnel the packets to the correct ETR.  Without
this, there would be no support for multihoming and portability for
the adopters of the map-encap (really core-edge separation) scheme -
so hardly anyone would adopt it.

Because thousands (or perhaps millions) of end-user networks share a
single MAB, this greatly reduces the size of the global BGP routing
table compared to doing nothing, since without map-encap, many of
those end-user networks would gain their own conventional PI space,
and advertise it in the BGP system.

Map-encap is not the only approach - it is one way of getting
packets from ITRs to ETRs in a core-edge separation scheme.

Two other methods involve forwarding, using modified DFZ routers:

  ETR Address Forwarding (EAF) - for IPv4
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw

  Prefix Label Forwarding (PLF) - for IPv6
  http://www.firstpr.com.au/ip/ivip/ivip6/

Unlike map-encap, these have no encapsulation or overhead or PMTUD
problems.  Without the PMTUD problems, the ITRs and ETRs can be simpler.

Also, there is translation - Six/One Router, for IPv6 only.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Wed, 22 Oct 2008 02:09:39 +1100

Hi Tony,

I understand you weren't just asking how map-encap could solve the
routing scaling problem by reducing the number of prefixes in the
DFZ routing table.  I understand you were asking about this without
renumbering.  You were referring to Lixia's statement:

> renumber), which seems holding best promise to me.

Regarding renumbering, as I have written:

   Renumbering once might be OK when converting to Scalable PI (SPI
   space)
   http://psg.com/lists/rrg/2008/msg02355.html  2008-08-26

   Re: Fast and sparse mapping? aggregated EIDs, OITRDs etc.
   http://psg.com/lists/rrg/2008/msg02475.html  2008-09-16

   also:  http://psg.com/lists/rrg/2008/msg02536.html

some very large end-user networks may decide to convert their
existing PI address space to an MAB, and therefore be responsible
for its management, mapping and OITRDs (Open ITRs in the DFZ - like
LISP "Proxy Tunnel Routers").

This address space then becomes the new kind: Scalable PI (SPI)
space, since it is managed by Ivip and can be split into as many
micronets as there are IPv4 addresses (or IPv6 /64s).

A single MAB is a single advertised prefix in the DFZ, but it
supports as many sites as this end-user wants, via it being split
into multiple micronets.

So assuming the end-user network would otherwise have used this PI
space in multiple sites, with multiple advertised prefixes in the
DFZ, then we have a scalable routing benefit - and this end-user
network has not had to renumber.

(This end-user network might choose to go into business renting out
some of its space to other end-users - in which case it is taking on
a new kind of role, not really like an ISP, since there is no
physical Internet connectivity, but a new role of an MAB Company.
In this case, it is not really just an "end-user" network any more,
since it is selling Internet services of this new kind to customers.)

I anticipate that most end-user networks adopting the new SPI kind
of space will be those with PA space at present, including those who
only need one or a few IPv4 addresses (or /64s for IPv6.

They need to renumber anyway if they change ISPs for another PA service.

To adopt the new kind of SPI space, they renumber once, to gain some
SPI space rented to them on a long-term basis by some MAB Company -
a company (including perhaps an RIR) which has an MAB for this
purpose.  The MAB company pays for the mapping distribution of all
micronets in the MAB, and for the OITRD services to support packets
from hosts in non-upgraded networks which are addressed to any
address in the MAB.  The MAB Company charges their customers for
this, according to OITRD traffic, number of mapping changes etc. in
addition to whatever they charge for renting a subset of the MAB's
address space.

So this is renumbering once only for all these smaller networks, and
for any large network which doesn't want to run its own MAB.

After that, there is no renumbering.  Multihoming and portability
work fine, including for all packets from hosts in non-upgraded
networks (networks without ITRs) - as long as there is an OITRD or
more likely multiple OITRDs around the Net, supporting this MAB.

 - Robin

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Oct 2008 11:31:02 -0400

> http://www.nanog.org/meetings/nanog44/presentations/Wednesday/Zhang_Wed_N44.pdf

"Dependency on DNS":  If we substitute using a different distributed
database to resolve identifiers to locators, Jon would still be
concerned.   Actually not just identifiers, but anything for which a
route is not known and for which a separate mapping system has to be
used to figure out how to  deliver a packet, including scoped locators.

However, the only way to avoid this is to change all the hosts, and most
of the approaches that change all the hosts still have site renumbering
problems.  The only way to avoid site renumbering problems is to
completely decouple internal locators from external locators (GSE).

Map-n-encap would upset Jon, as written GSE depends heavily on DNS, GSE
conversion would take longer to solve routing scaling than we have time
for, and nobody wants to make NAT the centerpiece of the new architecture.

How bad is the "relying on something like DNS" problem for map-n-encap?
  I would only be concerned if some non-technical issue made it
difficult to build redundancy and dynamicity into a mapping system.
Security need be no worse than in routing.

Scott

---

From: "Tony Li" <[email-masked]>
Date: Tue, 21 Oct 2008 10:28:14 -0700

|> How does that reduce the table size?
|
|that will take a slide deck to explain.
|We are currently working on that for a presentation for Minneapolis  
|(and a draft too to pass your criterion for a slot request:)

I look forward to it.  Please don't forget to cover the transition issues.

Thanks,
Tony

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 21 Oct 2008 10:44:19 -0700

> for, and nobody wants to make NAT the centerpiece of the new  

Scott, do you think Jon would be upset with LISP, as the way it is  
currently defined?

Dino

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Oct 2008 14:01:08 -0400

> Scott, do you think Jon would be upset with LISP, as the way it is

The question is really about mapping.  I wasn't in the room at that time
(that I remember) but I think DNS was a lot more fragile than it is now,
and more fragile than ALT.  Personally I think we're okay as long as we
can deploy the robustness the system is designed for.  If Jon's problem
was having IP forwarding depend on something fragile -- like
the-then-DNS -- then I don't think there's a problem.  If he objected in
principle to depending on anything other than hop-by-hop routing then I
guess he would still have a problem ... but then again he never liked
route filtering either.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2008 09:56:51 +1300

> guess he would still have a problem ... but then again he never liked

There's no doubt Jon felt strongly about this. I'm not sure whether he
or Lixia was the originator of the following words in RFC 1958:

   3.11 Circular dependencies must be avoided.

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing.

It might have been Lixia, because the point was explicit in her report
of the plenary discussion at IETF 33:

     "  In addition to the need
for autoconfiguration on tools at low levels, renumbering requires
changes to high-level protocols.  It also puts further reliance on the
DNS system to keep up-to-date address binding.  To avoid circular
dependency, DNS servers themselves will require special treatment,
such as provider-independent addresses, assured connectivity, issues
that are yet to be explored.  "

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 21 Oct 2008 14:18:52 -0700

|There's no doubt Jon felt strongly about this. I'm not sure whether he
|or Lixia was the originator of the following words in RFC 1958:
|
|   3.11 Circular dependencies must be avoided.
|
|      For example, routing must not depend on look-ups in the Domain
|      Name System (DNS), since the updating of DNS servers depends on
|      successful routing.
|
|It might have been Lixia, because the point was explicit in her report
|of the plenary discussion at IETF 33:
|
|     "  In addition to the need
|for autoconfiguration on tools at low levels, renumbering requires
|changes to high-level protocols.  It also puts further reliance on the
|DNS system to keep up-to-date address binding.  To avoid circular
|dependency, DNS servers themselves will require special treatment,
|such as provider-independent addresses, assured connectivity, issues
|that are yet to be explored.  "

I fully understand the (blindingly obvious) concern about circular
dependencies with DNS.  I also understand the issues with overloading DNS (a
naming system) and turning it into a Internet database system.  Are there
concerns *past* those points about leveraging DNS?

Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Oct 2008 17:23:06 -0400

> that are yet to be explored.  "

Good morning, Brian.  So the fundamental concern was about circular
dependencies.  In map-n-encap there are two different pieces routing
information distribution mechanisms, to reach locators and to reach
EIDs.  We just need to be sure that sources for mapping information (to
reach EIDs) are reachable in the global scope.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2008 10:42:55 +1300

> concerns *past* those points about leveraging DNS?

"US Department of Commerce Seeks Public Comments Regarding the Deployment
of LISP based on ICANN's and Verisign's Administration of the DNS Root Zone.
The Notice of Inquiry (NOI) was published in the Federal Register on
October 9, 2009."

But seriously... there is an issue of proper administration of
any mapping system, because it will be critical infrastructure. We
should consider whether this is a plus or a minus for the DNS.

    Brian

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 21 Oct 2008 14:54:19 -0700

> or Lixia was the originator of the following words in RFC 1958:

No it was not me.
It was Jon who felt strongly about avoiding circular dependency.

> that are yet to be explored.  "

1/ the above was the writing by whoever took the minutes of the plenary.
It was not me.

2/ my presentation was an interim report of the group.  I recall that  
6 of us hashed over the slides' wording a few times during that IETF  
week prior to the plenary (didn't anyone notice some convoluted  
wording? reflection of compromises:)

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 21 Oct 2008 15:14:48 -0700

> I look forward to it.  Please don't forget to cover the transition  

I interpreted your original question "How does that reduce the table  
size?" as how to reduce the table size for the first mover, that's why  
I said it'd take a deck of slides to explain our current thought.

I assume that's what you meant by transition?

Lixia

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2008 11:34:13 +1300

For anyone who's wondering what Lixia and I are referring to, see
http://www.ietf.org/proceedings/95jul/presentations/allocation.html

It's amusing, or depressing, to compare what was said at IETF33
to what was said at NANOG44. As Elise Gerich said in 1995,
"Until some technological advancements are deployed, the uneasy
compomise will continue".

   Brian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 21 Oct 2008 18:17:31 -0700

|> I look forward to it.  Please don't forget to cover the transition  
|> issues.
|
|I interpreted your original question "How does that reduce the table  
|size?" as how to reduce the table size for the first mover, 
|that's why  
|I said it'd take a deck of slides to explain our current thought.
|
|I assume that's what you meant by transition?

Yup.  The first mover, the 2nd mover, the 1,000th mover, and the last mover
are all interesting cases, IMHO.

Tony