+1
Thank all for the insightful discussion that took place around this draft.
Your feedback will be carefully considered to progress the work and we welcome
any further comment/feedback/help. :-)
ciao
Luigi
On 27 Nov. 2012, at 14:30 , Brian Haberman br...@innovationslab.net wrote:
I want
I want to thank everyone who has provided feedback on this draft. Given
the issues raised, I am sending the draft back to the LISP WG for
additional work. I encourage folks interested in this draft to
participate on the LISP mailing list.
Regards,
Brian
On 11/13/12 9:45 AM, The IESG wrote:
On Wed, Nov 21, 2012 at 11:01 PM, Dino Farinacci farina...@gmail.com wrote:
Make it an allocation for EIDs and ILNP can use it too.
Somehow I hear a voice in the back of my head asking if we're talking
about starting to use another big IPv6 block than 2000::/3 for the two
above mention usage?
Hi Roger,
On 22/11/2012 09:04, Roger Jørgensen wrote:
On Wed, Nov 21, 2012 at 11:01 PM, Dino Farinacci farina...@gmail.com wrote:
Make it an allocation for EIDs and ILNP can use it too.
Somehow I hear a voice in the back of my head asking if we're talking
about starting to use another big
Date:Thu, 22 Nov 2012 16:50:40 +1100
From:Geoff Huston g...@apnic.net
Message-ID: 08fcd406-f556-4f7e-ba98-9591d161a...@apnic.net
| With respect Robert, I disagree with your line of argument and I disagree
| with your assertion that a reference to an existing RFC
I would be a bit nervous about dedicating another /3 for unproven
use. There's a risk of it ending up unusable like Class E. So
if we are going to do this, doing it inside 2000::/3 seems a
bit safer to me.
So what if we could say the use is simply to assign addresses out of this block
that
At 22:16 20-11-2012, Geoff Huston wrote:
The guidelines for IP address allocations were documented in RFC2050,
adopted in November 1996 as a Best Current Practice. This document
Some parts of RFC 2050 could be considered as Historic. As a FYI
there is only one IANA policy about IPv6 [1].
Hi,
A possible course of action for the LISP Working Group and the IESG to
consider would be for the existing /32 address be documented as an IANA
Special Purpose Address allocation for use in supporting the current
LISP experiment, and for the LISP advocates to make their case for
From: Geoff Huston g...@apnic.net
I don't have any comment, one way or another, on what seems to be the basic
point of your note (about what role, if any, the IETF should play in
allocation).
However, there was one aspect I wanted to comment on (it's not clear, reading
your note, if this
-eid-block-03.txt (LISP
EID Block) to Informational RFC
The concept, as I understand it, is that there will be no migration out
of [that] allocation, for the simple reason that the entire rationale
of this range of namespace is that it will be processed differently,
i.e. require special casing
From: George, Wes wesley.geo...@twcable.com
I don't think that expecting code to handle two blocks (the
experimental one and the permanent one) is asking too much
We disagree. For me, it's extra code/complexity, and it buys you absolutely
nothing at all.
If a single
Date:Wed, 21 Nov 2012 17:16:58 +1100
From:Geoff Huston g...@apnic.net
Message-ID: 99b9866c-41d6-4784-aa69-cd25e5910...@apnic.net
I have no idea whether the allocation requested is reasonable or not,
I haven't read the draft (and unless it becomes more widely used than
Hi Noel,
I don't think that expecting code to handle two blocks (the
experimental one and the permanent one) is asking too much
We disagree. For me, it's extra code/complexity, and it buys you absolutely
nothing at all.
I don't agree. See below.
If a single permanent allocation that
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Noel Chiappa
If a single permanent allocation that never changes is truly
necessary
Allocation != reservation. Nobody is asking for the entire chunk to be
_allocated_ (i.e. given out), just that it be _reserved_
From: George, Wes wesley.geo...@twcable.com
Allocation != reservation.
You're hairsplitting on semantics in a way that is mostly unhelpful to
the discussion at hand.
I _thought_ that the point of the messages from Geoff and others (who were
questioning about how there were
Make it an allocation for EIDs and ILNP can use it too.
Dino
On Nov 21, 2012, at 12:25 PM, George, Wes wesley.geo...@twcable.com wrote:
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Noel Chiappa
If a single permanent allocation that never changes is truly
A possible course of action for the LISP Working Group and the IESG to
consider would be for the existing /32 address be documented as an IANA
Special Purpose Address allocation for use in supporting the current
LISP experiment, and for the LISP advocates to make their case for
particular
With respect Robert, I disagree with your line of argument and I disagree
with your assertion that a reference to an existing RFC is bogus under
these circumstances
This eid draft does not claim to obsolete or update either the description
of roles and responsibilities in RFC2860 or the
Hi,
We would like to make the following comments in response to the IETF
Last Call on the proposal to publish this draft as an Informational
RFC.
The guidelines for IP address allocations were documented in RFC2050,
adopted in November 1996 as a Best Current Practice. This document
described
Most of what you describe Sander sounds reasonable, and sounds aligned
with what is i the deployment documents.
The WG debated the EID allocation extensively. One could argue that
there is no need for it, that we could merely request that PI
allocations be granted for LISP EID usage
...@joelhalpern.com
Cc: ietf ietf@ietf.org; lisp l...@ietf.org; Brian E Carpenter
brian.e.carpen...@gmail.com
Verschickt: So, 18 Nov 2012 7:22 am
Betreff: Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID
Block) to Informational RFC
But why request the reservation of a /12? Or even a /16
From: Cameron Byrne cb.li...@gmail.com
If LISP succeeds, this results in significant reduction in core table
sizes for everyone.
Not everyone. Only people who carry core tables.
'this results in significant reduction in core table sizes for everyone who
has core tables'
Dino,
+1 In LACNIC, may 6th to 10th 2013 in Medellin Colombia.
Will consider Singapore and Medellin.
I am not the policiy guy but I can get you time in the technical and
policy plenaries and assit you in the discussion.
Also, if you plan to write some text about the
Sent from ipv6-only Android
On Nov 17, 2012 9:12 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote:
From: Cameron Byrne cb.li...@gmail.com
If LISP succeeds, this results in significant reduction in core
table
sizes for everyone.
Not everyone. Only people who carry core
From: Cameron Byrne cb.li...@gmail.com
So it has transferred costs for communicating with site X from
'everyone with a core table, everywhere in the entire network' to
'just the people who are actually trying to communicate with site X'.
This is bad... how?
I didn't see
But why request the reservation of a /12? Or even a /16 for that matter?
If the LISP experimental deployers have filled a /32 with /48 prefixes then
should this imply that the experiment is all over over and its time to recast
this not as an experiment but as an application which requires
On 16/11/2012, at 7:24 AM, Dino Farinacci farina...@gmail.com wrote:
Secondly, you appear to assume these allocations to EID can simply use
current RIR practices. The problem is that you need to understand what
needs-based and justification means in process terms: Hostmasters in the RIR
s/12/16/ wrt 2002: doh. the principle stands. 2002://16 did not imply a
reservation to a /12 and would have been given less than a /16 if the
technology had allowed it.
-G
On 15/11/2012 22:41, Sander Steffann wrote:
...
b) as a user of that EID space I would be at the mercy of
PITR operators that I don't even know
You are at the mercy of a lot of infrastructure components
today. This is no different.
Yes it is. *please*please*please* study what happened to
Hi Dino,
George:
Maybe this is something you could come to an RIR meeting and present on or
discuss? We've got an APNIC/APRICOT coming up early in 2013 and I am sure
you'd be welcomed to submit some content. Its good to talk about these
things.
+1
Let's make it official :-)
It would be
Dino,
+1 In LACNIC, may 6th to 10th 2013 in Medellin Colombia.
I am not the policiy guy but I can get you time in the technical and
policy plenaries and assit you in the discussion.
Also, if you plan to write some text about the allocation mechanics let
me know, I will
On Tue, Nov 13, 2012 at 3:45 PM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
draft-ietf-lisp-eid-block-03.txt as Informational RFC
The IESG plans to make a
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Brian E Carpenter
*please*please*please* study what happened to 6to4 and the
2002::/16 prefix before continuing this discussion.
The problem there was that the design of 6to4 assumed, and relied on,
altruistic
From: rog...@gmail.com
the routing integration between none-LISP and LISP internet, how are
that going to work? The current document isn't clear enough on that as
I see it.
The way the routing will work would take a couple of PhD theses to fully
cover (I know of one that's
It is a fair question to ask whether the allocation strategy and polices
need to be spelled out at the time of the reservation. Possibly we made
the wrong call on keeping them separate. Part of the issue is that fo
current experimentation having the block is more important, but for
longer
Joel,
On 16/11/2012 16:00, Joel M. Halpern wrote:
...
With regard to interworking and deployment, there are a number of
documents that deal with that. They discuss what the currently
understood deployment incentives are, and what paths are currently seen.
(As Noel noted, this is an
Luigi,
On 15/11/2012 12:33, Luigi Iannone wrote:
On 15 Nov. 2012, at 10:43 , Sander Steffann san...@steffann.nl wrote:
Hi,
I have to ask, who can request an netblock from this address space and
from where?
I might be blind but I couldn't find it mentioned anywhere.
Good question.
Dino,
But who are the registries? The RIRs? Large ISPs? IANA? I think you
should specify clearly either: what a registry is or that is not defined
yet.
Yes, nothing has to change in terms of who and how PI addresses are allocated.
Point taken on This draft is purely a draft to
One thing we have to be very careful with here is that EIDs are not directly
allocated/assigned to end sites from this block. That will cause everyone to
independently find (different) PITRs for their space, which will make a mess
of the global IPv6 routing table...
Thanks,
Sander
I
Hi,
How are you going to allocate space to ISPs?
This is PI space. The registries will take portions of this space to
allocate to end devices.
Are you thinking about the existing RIRs here? If so: it might be a good idea
to notify them that this is coming.
Nothing is coming. Nothing
And you do not want to tie addresses to topological entities. Or you will lose
the mobility capabilities that Locator/ID separation can bring.
Dino
On Nov 15, 2012, at 12:21 PM, Paul Vinciguerra pvi...@vinciconsulting.com
wrote:
One thing we have to be very careful with here is that EIDs are
Hi Dino,
Nothing is coming. Nothing really needs to change.
But if there is anything written up to define allocation procedures, the
RIRs can review such a document.
The main motivation for this prefix is to optimize ITRs so they know that a
destination is in a LISP site. This COULD
Hi,
The main motivation for this prefix is to optimize ITRs so they know that
a destination is in a LISP site. This COULD eliminate a mapping database
lookup for a destination not in this range. Meaning, if a packet is
destined to a non-EID, you may know this by inspecting the address
Dino, to come back on topic. I understand the drafts purpose is to request a
block of IPv6 address be delegated for this specific purpose, from IANA. The
request is to the IAB. So, its a request for architectural aspects of
addressing, facing an experiment.
Sure.
a /12 is a very large
So, I had originally thought that the reason for this was to change the
characteristics of a new flow with a cache-hit from the ..!!! that we see to a
!
But even if you know that the destination is an EID, you still need to lookup
the RLOCs, so how does this help? If the destination is a
Why does any operator have a reason to carr any routes other than their
paying customers? Because it provides connectivity for their customers.
If we get this block allocaed, then it results in 1 extra routing entry
in the global routing table to support LISP inter-working.
An entry that some
Hi Terry,
I posted a message [1] about draft-ietf-lisp-eid-block-03 and asked
about the write-up. Is there a write-up for
draft-ietf-lisp-eid-block, and if so, where can I find it?
BTW, I don't see my comments being addressed. Would it be possible
to add a note for the Area Director about
Hi Joel,
Why does any operator have a reason to carr any routes other than their
paying customers? Because it provides connectivity for their customers.
If we get this block allocaed, then it results in 1 extra routing entry in
the global routing table to support LISP inter-working.
An
On Nov 16, 2012 9:27 AM, Joel M. Halpern j...@joelhalpern.com wrote:
Why does any operator have a reason to carr any routes other than their
paying customers? Because it provides connectivity for their customers.
If we get this block allocaed, then it results in 1 extra routing entry
in the
Good points Joel. I completely agree.
Dino
On Nov 16, 2012, at 9:26 AM, Joel M. Halpern j...@joelhalpern.com wrote:
Why does any operator have a reason to carr any routes other than their
paying customers? Because it provides connectivity for their customers.
If we get this block
I think this document isn't ready for IETF last call.
I think the context of an experimental assignment which heads to
distributing IPv6 addresses to end-entities, even if the experiment
is not intended to be globally routable, poses questions about how
the address management function is going to
On Tue, Nov 13, 2012 at 3:45 PM, The IESG iesg-secretary at ietf.org wrote:
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
draft-ietf-lisp-eid-block-03.txt as Informational RFC
The IESG plans to
Hi Roger,
On 14 Nov. 2012, at 10:42 , Roger Jørgensen rog...@gmail.com wrote:
On Tue, Nov 13, 2012 at 3:45 PM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
Hi,
thanks for the comments. Few answers inline.
On 14 Nov. 2012, at 12:19 , SM s...@resistor.net wrote:
At 06:45 13-11-2012, The IESG wrote:
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
On 15 Nov. 2012, at 10:43 , Sander Steffann san...@steffann.nl wrote:
Hi,
I have to ask, who can request an netblock from this address space and
from where?
I might be blind but I couldn't find it mentioned anywhere.
Good question. Will there be a central registry, or will parts of the
Hi George,
On 15 Nov. 2012, at 11:50 , George Michaelson ggm+i...@apnic.net wrote:
I think this document isn't ready for IETF last call.
We are open to any suggestion to make the document ready for it. ;-)
I think the context of an experimental assignment which heads to
distributing
Hi Bert,
On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF) berti...@bwijnen.net wrote:
[snip]
So it is not asking just a /16 but also asking for reservation of a /12.
Pretty big space.
And in the list of reasons, I mainly read that it is sufficiently large,
but not much about why it needs
Nice to try and keep it short.
But I was hoping for some more detail and explanation.
I have not followed the discussions (if any) in the WG
so I may be missing the reasons why you need this much
space. I would hope that the WG (if they have consensus
(which may be something different than the
Hi,
I have to ask, who can request an netblock from this address space and
from where?
I might be blind but I couldn't find it mentioned anywhere.
Good question. Will there be a central registry, or will parts of the space be
delegated to i.e. LISP based ISPs?
- Sander
Hi,
no central registry has been ever discussed, was more about delegated the
space to LISP ISPs.
Glad to hear that!
Sander
On 15 Nov. 2012, at 10:43 , Sander Steffann san...@steffann.nl wrote:
Hi,
I have to ask, who can request an netblock from this address space
and from where?
I might be blind but I couldn't find it mentioned anywhere.
Good question. Will there be a central registry, or will parts
Hi Luigi,
At 06:32 15-11-2012, Luigi Iannone wrote:
thanks for the comments. Few answers inline.
Thanks for the response.
Well, if we go along that road we should put the whole document in a
single IANA Considerations Section. ;-)
Yes. :-)
Actually the current IANA Considerations section
In Section 6:
It is suggested to IANA to temporarily avoid allocating any
other address block the same /12 prefix the EID /16 prefix
belongs to. This is to accommodate future requests of EID
space without fragmenting the EID addressing space.
Shouldn't that be under IANA
Hi,
So there will be a pool of addresses that the RIR's can allocate out of for
EIDs? If that's the case, what is the additional value to an ISP who would
conceivably have to pay the RIR for another block of V6 addresses
specifically for use as EIDs, when most likely they are already
Luigi,
On 15/11/2012 12:33, Luigi Iannone wrote:
On 15 Nov. 2012, at 10:43 , Sander Steffann san...@steffann.nl wrote:
Hi,
I have to ask, who can request an netblock from this address space and
from where?
I might be blind but I couldn't find it mentioned anywhere.
Good question. Will
Dino,
But who are the registries? The RIRs? Large ISPs? IANA? I think you
should specify clearly either: what a registry is or that is not defined
yet.
Point taken on This draft is purely a draft to REQUEST space. There
will need to be a deployment guide on how to allocate EIDs,
Hi,
How are you going to allocate space to ISPs?
This is PI space. The registries will take portions of this space to allocate
to end devices.
Are you thinking about the existing RIRs here? If so: it might be a good idea
to notify them that this is coming.
This draft is purely a draft
Hi Dino,
But who are the registries? The RIRs? Large ISPs? IANA? I think you
should specify clearly either: what a registry is or that is not defined
yet.
Yes, nothing has to change in terms of who and how PI addresses are allocated.
Sorry, but if the RIRs are going to allocate from
Hi,
One thing we have to be very careful with here is that EIDs are not directly
allocated/assigned to end sites from this block. That will cause everyone to
independently find (different) PITRs for their space, which will make a mess
of the global IPv6 routing table...
Thanks,
Sander
Hi Dino,
Nothing is coming. Nothing really needs to change.
But if there is anything written up to define allocation procedures, the RIRs
can review such a document.
The main motivation for this prefix is to optimize ITRs so they know that a
destination is in a LISP site. This COULD
Hi,
And you do not want to tie addresses to topological entities. Or you will
lose the mobility capabilities that Locator/ID separation can bring.
Well, it is a business model. I am providing exactly such a service to a few
test users now. I now hand out EID space from my PA block. If
Hi,
The main motivation for this prefix is to optimize ITRs so they know that a
destination is in a LISP site. This COULD eliminate a mapping database
lookup for a destination not in this range. Meaning, if a packet is
destined to a non-EID, you may know this by inspecting the address
Dino, to come back on topic. I understand the drafts purpose is to request a
block of IPv6 address be delegated for this specific purpose, from IANA. The
request is to the IAB. So, its a request for architectural aspects of
addressing, facing an experiment.
a /12 is a very large amount of
Whatever else is going on, LISP EIDs do not have geographic
significance. They do not have IP Routing topological significance.
The are not aggregateable.
They are intended to beused by a site as a single prefix. Hence, the
desired behavior (within the /16) is exactly the same as that
Hi,
But I think it comes down to
COULD ignore that certain EIDs are in the mapping system and always route
them legacy-style
No, I don't think so. You just avoided doing LISP to the destination site
that wants multi-homing.
That's what I said (or at least meant :) )
I wouldn't agree
Joel,
I think that George raised a very valid concern and he explained very
well the RIR machinery to perform address allocation.
Saying that it is just PI simple does not help.
As an example of our concerns (or at least mine), the policy to
allocate PI in lacnic is:
On Tue, Nov 13, 2012 at 3:45 PM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
draft-ietf-lisp-eid-block-03.txt as Informational RFC
The IESG plans to make a
At 06:45 13-11-2012, The IESG wrote:
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
draft-ietf-lisp-eid-block-03.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
draft-ietf-lisp-eid-block-03.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
79 matches
Mail list logo
