Subject: [RRG] on draft-meyer-lisp-eid-block-00.txt

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Mar 2008 09:51:50 -0700

This draft follows from the comments I made at the mike
during Christian Vogt's presentation on 3/14 and also
here on the list:

http://www.ops.ietf.org/lists/rrg/2008/msg00780.html
http://www.ops.ietf.org/lists/rrg/2008/msg00781.html

The idea is that if a sufficiently large IPv6 prefix
is reserved for use as EID space, then a simple
transition is possible since it can be known whether
an EID resides behind an ETR simply by examining the
prefix. (Plus, the legacy IPv6 deployments never have
to renumber.)

My comment to the draft authors is that the request
for a /16 may be overly conservative; why not ask for
something more like a /8, /10, etc. (or even more) to
reduce fragmentation of the IPv6 address space.

To Christian Vogt, my comments did not show up on your
meeting minutes, which is understandable because you
were presenting at the time. Maybe update the minutes
if you get a chance.

Thanks - Fred
[email-masked]  

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Mar 2008 10:10:55 -0700

> reduce fragmentation of the IPv6 address space.

I am fine with that, but what will the IANA, er IETF allow.

Dino

----

Internet Protocol Version 6 Address Space

(last updated 2007-07-19)

IPv6 Prefix           Allocation              Reference      Note
-----------           ----------              ---------      ----
0000::/8              Reserved by IETF        [RFC4291]      [1] [5]
0100::/8              Reserved by IETF        [RFC4291]
0200::/7              Reserved by IETF        [RFC4048]      [2]
0400::/6              Reserved by IETF        [RFC4291]
0800::/5              Reserved by IETF        [RFC4291]
1000::/4              Reserved by IETF        [RFC4291]
2000::/3              Global Unicast          [RFC4291]      [3]
4000::/3              Reserved by IETF        [RFC4291]
6000::/3              Reserved by IETF        [RFC4291]
8000::/3              Reserved by IETF        [RFC4291]
A000::/3              Reserved by IETF        [RFC4291]
C000::/3              Reserved by IETF        [RFC4291]
E000::/4              Reserved by IETF        [RFC4291]
F000::/5              Reserved by IETF        [RFC4291]
F800::/6              Reserved by IETF        [RFC4291]
FC00::/7              Unique Local Unicast    [RFC4193]
FE00::/9              Reserved by IETF        [RFC4291]
FE80::/10             Link Local Unicast      [RFC4291]
FEC0::/10             Reserved by IETF        [RFC3879]      [4]
FF00::/8              Multicast               [RFC4291]

----

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Mar 2008 10:22:55 -0700

> I am fine with that, but what will the IANA, er IETF allow.

	Likewise. We can easily ask for more :-)

	Dave

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Mar 2008 13:22:11 -0700

Note - so that this is not misconstrued as an unqualified
endorsement, I still believe LISP has to tackle a number
of issues including the tunnel MTU situation, per my
message on 3/9/08:

  http://www.ops.ietf.org/lists/rrg/2008/msg00692.html

Fred

>-----Original Message-----
>From: Templin, Fred L 
>Sent: Thursday, March 20, 2008 9:52 AM
>To: Routing Research Group Mailing List
>Cc: Christian Vogt; Darrel Lewis (darlewis); [email-masked]; 
>Vince Fuller
>Subject: [RRG] on draft-meyer-lisp-eid-block-00.txt
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Mar 2008 13:59:47 +1300

If this is really a preferred architectural direction,
using 1/256th of the total address space for it wouldn't seem
unreasonable (certainly less unreasonable than Class E,
for example). So try for a /8 ?

     Brian