Subject: [rrg] presentation/discussion list

From: Lixia Zhang <[email-masked]>
Date: Thu, 20 Nov 2008 08:57:03 -0800

Tony and I nailed down the details of agenda (it's online now, http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis) 
.

Tony sent a msg to the list more than an hour ago but I have not seen  
it out yet, someone asked, hence this msg

> looks like we'll have to nail down the exact order and time slots  
> for the talks/discussions tomorrow. for now here's the list of things
>
> - Mapped BGP Design (Paul Francis)
> - Evolving towards Routing Scalability (Dan Jen)
> - Border Router Discovery Protocol and BRDP Based Routing (Teco Boot)
> - Hostname-Oriented Network Protocol Stack (Vot)
> - HAIR: Hierarchical Architecture for Internet Routing (Anja Feldman)
> - Routing Architecture for the Next Generation Internet (Raj Jain)
> - the chairs slot: discussion and next step
>
> Lixia

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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 20 Nov 2008 19:04:48 +0200

Looks like you have missed one draft:

http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.
txt

I think Brian asked for a slot and I promised to present it.

Regards
Hannu 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Lixia Zhang
>Sent: Thursday, November 20, 2008 18:57
>To: [email-masked]
>Subject: [rrg] presentation/discussion list
>
>Tony and I nailed down the details of agenda (it's online now, 
>http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis)
>.
>
>Tony sent a msg to the list more than an hour ago but I have 
>not seen it out yet, someone asked, hence this msg
>
>> looks like we'll have to nail down the exact order and time 
>slots for 
>> the talks/discussions tomorrow. for now here's the list of things
>>

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 20 Nov 2008 09:16:56 -0800

> I think Brian asked for a slot and I promised to present it.

as I mentioned in a msg yesterday, a few agenda requests went to the  
PC directly without copying Tony and me.  I finally collected a (I  
thought complete) list and verified with PC last night; did not see  
any mentioning about this draft.

Brian, wonder what you would like to do at this time?

Lixia

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2008 12:43:11 -0600

On 20 nov 2008, at 11:16, Lixia Zhang <[email-masked]> wrote:

>> http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.txt

> Brian, wonder what you would like to do at this time?

Note that Brian couldn't make it to Minneapolis..

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Nov 2008 09:17:44 +1300

> Note that Brian couldn't make it to Minneapolis..

Hannu only needs 5 minutes to mention the existence of the draft
and request feedback. Or maybe people can just read the draft
and send feedback...

Just to be clear: we (the authors) are not looking for a re-run of
previous threads on this list about how renumbering is totally
horrible. We're looking for specific comments on the topics covered
in the draft so that we can make it a better draft. It seems likely
that the IETF Ops Area will host the draft, but for the moment we're
in feedback-collection mode.

   Brian

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 21:35:27 +0100

I'll give up the 5 minutes if requested, also because my work is somewhat
related.
See Brian's I-D why.
Teco.

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]] Namens Brian E
> Carpenter
> Verzonden: donderdag 20 november 2008 21:18
> Aan: Iljitsch van Beijnum
> CC: [email-masked]; Lixia Zhang
> Onderwerp: Re: [rrg] presentation/discussion list
>

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 20 Nov 2008 12:36:48 -0800

> and request feedback. Or maybe people can just read the draft

do you think this list has already served that purpose of informing  
people about the draft and your request for feedback (and this msg  
reaches even a much wider audience than the number of people who'll  
show up in the room tomorrow)?

---

From: "William Herrin" <[email-masked]>
Date: Thu, 20 Nov 2008 14:38:33 -0600

> in feedback-collection mode.

Brian,

I can sum up the single most significant obstruction to renumbering in
four words: get host by name.

So long as developers have a standard API for mapping names to
addresses which fails to propagate the duration of validity, app
developers will use the API and renumbering will remain a severe
operational drag.

Don't just think about the big standardized protocols. Think about a
the little one-off programs that get written to shoot this bit of info
to that doohickey in a custom way.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2008 22:15:35 -0600

> developers will use the API and renumbering will remain a severe

I don't think the mere fact that applications must do the name to  
address lookup and then hand the address to the network stack makes  
renumbering harder.

That is, unless you mean renumbering IP versions.

In the plenary, Dave Thaler mentioned the problem that many  
applications work with addresses where they should work with names.  
There is of course a laziness and shortsightedness component to that,  
but I believe that in most cases this is because the existing name  
resolution systems fail to meet the needs of the application writers  
or operators. Let me name a few issues.

The DNS is fairly slow. Looking up an address can take a few hundred  
milliseconds.

The DNS is somewhat unreliable. Under normal circumstances, it doesn't  
fail too often, but it's not too hard to create circumstances where  
DNS lookups fail to work.

The caching is braindead. If the TTL is 24 hours, then this means you  
could have wrong information for 23:59:59. It also means that at  
23:59:59 something may work fine, and at 24:00:01 it doesn't work at  
all. This is especially true when the source and destination can reach  
each other but part of the delegation hierarchy has become unreachable.

Although the DNS and (multicast) DNS service discovery can provide  
port numbers, applications generally don't look for them, limiting the  
usefulness in cases where port numbers are needed in addition to  
addresses.

Dynamic DNS allows hosts to register their address in the DNS, but  
this requires the availability of a server and a domain name, as well  
as significant coordination for security. Many end-users simply don't  
have a domain name or a server that can host the dynamic zone.

Interestingly, peer-to-peer applications spend a lot of complexity on  
a name to address mapping mechanism that doesn't require hierarchical  
delegations or long term reachable servers.

If we are serious about moving away from addresses in favor of names  
to make renumbering, and therefore multihoming and mobility, easier,  
we need to address these issues.

Especially if we want people to create firewall rules based on names,  
all of this has to have very high reliability, performance and security.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2008 13:51:18 +1300

> From: Iljitsch van Beijnum <[email-masked]>
> Date: Nov 21, 2008 5:15 PM

...
> address lookup and then hand the address to the network stack makes

I think it does, for two related reasons.

1. The address lookup API does not (currently) return a lifetime,
so the looker-up gets to make its own assumption about the lifetime
of the address. Many programmers have fallen into the trap of
assuming that the lifetime is infinity.

2. The fact that the upper layer has knowledge of an address with
no known lifetime creates an irresistible temptation to store that
address and use it again an undefined time later.

We've known this was a problem for many years so maybe it's
time to fix it, although that won't help with the legacy apps.

   Brian

---

From: "William Herrin" <[email-masked]>
Date: Sun, 23 Nov 2008 22:44:18 -0500

> assuming that the lifetime is infinity.

*cough* ntpd *cough*

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Nov 2008 17:39:38 +0100

> 1. The address lookup API does not (currently) return a lifetime,

Well, the application could simply perform an address lookup every  
time it needs the address. Most modern resolver libraries do caching  
so on those systems that wouldn't impact performance.

> address and use it again an undefined time later.

Well...

> time to fix it, although that won't help with the legacy apps.

Right. A name based API does have some disadvantages apart from what  
you mention above:

- architecturally cleaner
- ability to automatically try multiple addresses at connect() time
- ability to use multiaddress multihoming through the likes of SCTP
- ability to work with new address families
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 30 Nov 2008 16:44:44 +0100

With map&encap and larger ntp polling intervals, what about jitter / delay /
asymmetry / packet loss?

Recent postings suggest drop the first packet during map lookup. Oeps!!!!
I think first packet delivery is a MUST.

Teco. 

/ -----Oorspronkelijk bericht-----
/ Van: [email-masked] [mailto:[email-masked]] Namens William
/ Herrin
/ Verzonden: maandag 24 november 2008 4:44
/ Aan: Brian E Carpenter
/ CC: RRG
/ Onderwerp: Re: [rrg] Name-based API, was: Re: presentation/discussion
/ list
/ 
/ On Sun, Nov 23, 2008 at 7:51 PM, Brian E Carpenter
/ <[email-masked]> wrote:
/ > 1. The address lookup API does not (currently) return a lifetime,
/ > so the looker-up gets to make its own assumption about the lifetime
/ > of the address. Many programmers have fallen into the trap of
/ > assuming that the lifetime is infinity.
/ 
/ *cough* ntpd *cough*
/ _______________________________________________
/ rrg mailing list
/ [email-masked]
/ https://www.irtf.org/mailman/listinfo/rrg

---

From: "William Herrin" <[email-masked]>
Date: Sun, 30 Nov 2008 11:05:51 -0500

> I think first packet delivery is a MUST.

Hi Teco,

We went through this before nearly a year ago. The short version is
that the jitter at the cache duration boundary will impact that ntp
session regardless of whether you keep or drop the packet.

Solutions include:

1. TRRP style: place the NTP daemons that will communicate out over
the internet on bare (non-upgraded) addresses and sync the map-encap
machines to those nearby ntp servers.

2. Any pull-cache: modify the NTP software so that it ignores
out-of-bounds answers when it hasn't sent a packet in a while and
tries again a few seconds later.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Sun, 30 Nov 2008 12:45:30 -0800

|Recent postings suggest drop the first packet during map 
|lookup. Oeps!!!!
|I think first packet delivery is a MUST.

The problem is that first packet delivery requires buffering.  To quote an
esteemed colleague:  "Buffering bad."  ;-)

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 30 Nov 2008 13:19:13 -0800

>From: Tony Li [mailto:[email-masked]]
>Sent: Sunday, November 30, 2008 12:46 PM
>To: 'Teco Boot'; 'RRG'
>Subject: Re: [rrg] NTP and first packet delivery
>
>
>
>

Or send the first packet to a default mapper per APT?

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 30 Nov 2008 13:49:12 -0800

I have not seen this widely discussed, but in the map/encaps
approaches the Internet DFZ is essentially viewed as a giant
NBMA "link" that connects all *TRs. In other words, all *TRs
on the virtual link can reach each other in a single IP hop
and can use neighbor discovery mechanisms such as IPv6 ND.
This also paves the way for new ND mechanisms such as SEND.

This model exactly parallels that which was established
in ISATAP [RFC5214], and has been further developed in
RANGER/VET/SEAL. I made an effort to articulate this back
in 2002 in a note titled: "The Inside-Out ISATAP Model":

http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00657.html

but we seem to now be coming back around to the same concept.
The main point of this note therefore is to (re)introduce the
useful concept of the Internet DFZ as a giant NBMA "link" that
connects routers the same as for any link.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Dec 2008 11:10:07 +1300

> Or send the first packet to a default mapper per APT?

Buffer, drop or default-map are all going to badly impact a protocol
that assumes the first packet will usually get through quickly.
But doesn't that seem like a very risky assumption for a best-effort
Internet anyway?

    Brian

---

From: David Conrad <[email-masked]>
Date: Sun, 30 Nov 2008 14:14:51 -0800

> esteemed colleague:  "Buffering bad."  ;-)

Our esteemed colleague is over-generalizing (or perhaps is being taken  
out of context).  Buffering is not always bad, particularly since  
without it, the Internet probably wouldn't work.  In the context of  
performing a mapping lookup, it is part of a cost/benefit tradeoff.   
As has been said on numerous occasions, TANSTAAFL.  If you're going to  
have a mapping, you either need to take the hit of schlepping the  
entire map around to ever device that needs to do a lookup or you take  
the hit of increased latency as you buffer/drop the first packet and  
fetch the map entries you need.  There are numerous variations and/or  
gymnastics you can play to reduce the pain of the hit, but you'll  
_always_ have someone pointing out worst case edge scenarios where one  
solution is better than another.

You can argue that this indicates that adding a layer of indirection  
is fundamentally flawed, yet I have yet to see another approach  
proposed that passes the giggle test.

To be honest, this is all getting quite boring.  It has been over 2  
years since the AMS workshop and we're largely arguing about the same  
things that were raised in that meeting.  As far as I can tell, all  
we've been able to confirm is that all the potential solutions suck in  
some way and that they can't/won't be deployed operationally because  
of one particular sacred cow or another.

It would seem the future holds the following for us:
- increased PI allocations, leading to:
- increased cost in getting those PI allocations routed, leading to:
- increased use of NAT, leading to:
- increased use of overlay networks (e.g., "everything-over-HTTPS")

And of course, IPv6 merely exacerbates all of this.

I for one am coming to accept and welcome our not-so-new NAT  
overlords...

Regards,
-drc

P.S. Just for fun, I've appended the presentation I gave in AMS on 18  
Oct 2006.  Tell me if anything has changed.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 30 Nov 2008 21:02:38 -0800

> Or send the first packet to a default mapper per APT?

We have Data Probes in LISP that do the same thing. People don't like  
that either.

Dino

---

From: Scott Brim <[email-masked]>
Date: Mon, 1 Dec 2008 00:52:53 -0500

> tries again a few seconds later.

The issue will rarely come up.  In order for it to arise, a site
border router must come up cold with no knowledge of prefixes where it
wants to find its NTP servers.  Once it maps these prefixes, which
will very probably be few and well-used, it will have mappings for
them until it comes up cold again.  So as yet another alternatives,
avoid completely cold restarts, or give it what it needs via
configuration or synchronization.  There are probably other
possibilities.  

Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 1 Dec 2008 00:55:59 -0500

Excerpts from Templin, Fred L on Sun, Nov 30, 2008 01:49:12PM -0800:
> approaches the Internet DFZ is essentially viewed as a giant NBMA
> "link" that connects all *TRs. In other words, all *TRs on the
> virtual link can reach each other in a single IP hop and can use
> neighbor discovery mechanisms such as IPv6 ND.  This also paves the
> way for new ND mechanisms such as SEND.

How would this scale?  We're considering O(10^9) prefixes and rather
more xTRs.  

> This model exactly parallels that which was established in ISATAP
> [RFC5214], and has been further developed in RANGER/VET/SEAL. I made
> an effort to articulate this back in 2002 in a note titled: "The
> Inside-Out ISATAP Model":
> 
> but we seem to now be coming back around to the same concept.  The
> main point of this note therefore is to (re)introduce the useful
> concept of the Internet DFZ as a giant NBMA "link" that connects
> routers the same as for any link.

I'll take a look again.

Scott