Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

From: Roger Jørgensen <[email-masked]>
Date: Wed, 14 Nov 2012 10:42:26 +0100

On Tue, Nov 13, 2012 at 3:45 PM, The IESG <[email-masked]> 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 solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-11-27. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This is a direction to IANA to allocate a /16 IPv6 prefix for use
>    with the Locator/ID Separation Protocol (LISP).  The prefix will be
>    used for local intra-domain routing and global endpoint
>    identification, by sites deploying LISP as EID (Endpoint IDentifier)
>    addressing space.

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.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: SM <[email-masked]>
Date: Wed, 14 Nov 2012 03:19:14 -0800

>[email-masked] mailing lists by 2012-11-27. Exceptionally, comments may be

The document does not clearly define how the address space will be 
managed.  This might end up being problematic in future.

In Section 4:

  "Too guarantee reachability from the Legacy Internet the prefix could"

There is a typo for "Too".

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 Considerations?

   "If in the future there will be need for a larger EID Block the
    address space adjacent the EID Block could be allocate by IANA
    according to the current policies."

Which policies does the above refer to?

In Section 10:

   "This document instructs the IANA to assign a /16 IPv6 prefix for use
    as the global LISP EID space using a hierarchical allocation as
    outlined in [RFC5226]."

Who will be the delegated managers?

   "Following the policies outlined in [RFC5226], such space
    will be assigned only upon IETF Review."

The previous sentence mentions hierarchical allocation and the above 
sentence mentions IETF Review.  It is not clear how assignments from 
this space will be made.

Regards,
-sm

---

From: George Michaelson <[email-masked]>
Date: Thu, 15 Nov 2012 11:50:03 +0100

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 work. Can the working
group be asked to discuss how this is meant to be interpreted in
the light of RFC2050 based processes? It might avoid future pain
if its clear how the IAB and the RIR understand these addresses and
their management.

The experiment has all the attributes of a general, wide-ranging
address distribution and management activity. I haven't seen any
substantive discussion of this in the WG mailing lists, and I'm
worried this hasn't been documented, or understood.

cheers

-George

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Nov 2012 14:22:50 +0100

Hi Roger,

> I have to ask, who can request an netblock from this address space and

Who: whoever is willing to deploy LISP.

Where: your RIR? 

> I might be blind but I couldn't find it mentioned anywhere.

The purpose of the document is not to create a new way to distribute prefixes with its own policies, rather to use the existing "process" but just creating a code point specific for LISP.

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Nov 2012 15:32:06 +0100

Hi,

 thanks for the comments. Few answers inline.

On 14 Nov. 2012, at 12:19 , SM <[email-masked]> wrote:

> The document does not clearly define how the address space will be managed.  This might end up being problematic in future.
> 
> In Section 4:
> 

thanks, will fix.

> Shouldn't that be under IANA Considerations?

Well, if we go along that road we should put the whole document in a single "IANA Considerations" Section. ;-)

Actually the current IANA Considerations section states the same request but does not specify "/12".
You are right that it should be clearly stated, to make the document coherent. Will fix. thanks

> Which policies does the above refer to?

It refers to the IANA allocation policies. May be it could be changed in the following way:

	If in the future there will be need for a larger EID Block the
  	address space adjacent the EID Block could be allocate by IANA
  	according to its current allocation policies."

Would that work?

> Who will be the delegated managers?

I agree that this point has been not discussed thoroughly, the idea is not to create any new "manager", rather to make ISPs (or whoever interested in deploying LISP) to request an EID address sub-block  as they do with usual prefixes. 

>   will be assigned only upon IETF Review."

Well, this is standard, to have a reserved space we have to go through the (now called) "IETF Review", which is what we are doing ;-)

ciao

Luigi

> The previous sentence mentions hierarchical allocation and the above sentence mentions IETF Review.  It is not clear how assignments from this space will be made.
> 
> Regards,
> -sm

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Nov 2012 15:33:36 +0100

On 15 Nov. 2012, at 10:43 , Sander Steffann <[email-masked]> wrote:

> Good question. Will there be a central registry, or will parts of the space be delegated to i.e. LISP based ISPs?
> 

Hi Sander,

no central registry has been ever discussed, was more about delegated the space to LISP ISPs.

Luigi

> - Sander
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Nov 2012 15:38:54 +0100

Hi George,

> I think this document isn't ready for IETF last call.

We are open to any suggestion to make the document ready for it. ;-)

> worried this hasn't been documented, or understood.

Well, clearly I am missing something. WOuld you mind be a bit more specific? Are you asking to have rough consensus on specific points? Which points?

thanks

Luigi

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 10:43:29 +0100

Hi,

- Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 15:45:30 +0100

Hi,

> no central registry has been ever discussed, was more about delegated the space to LISP ISPs.

Glad to hear that!
Sander

---

From: SM <[email-masked]>
Date: Thu, 15 Nov 2012 09:08:08 -0800

Hi Luigi,
>  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. :-)

>You are right that it should be clearly stated, to make the document 
>coherent. Will fix.

Ok.

>         according to its current allocation policies."

Not yet. :-)  You did not answer my question about which IANA 
allocation policies the draft is referring to.

>I agree that this point has been not discussed thoroughly, the idea 
>is not to create any new "manager", rather to make ISPs (or whoever 
>interested in deploying LISP) to request an EID address 
>sub-block  as they do with usual prefixes.

I'll comment below.

>Well, this is standard, to have a reserved space we have to go 
>through the (now called) "IETF Review", which is what we are doing ;-)

What the draft is doing is reserving address space.  According to 
Section 10 address blocks from that reserved address space (the /16) 
will be assigned through IETF review.  I read the previous comment as 
meaning that the EID address block will be assigned to ISPs by 
RIRs.  There isn't any mention of that in the draft.  Even if it was 
mentioned it is doubtful that ISPs would be able to get that address 
space assigned through RIRs at present.  The issue was mentioned in 
the AD review [1].  I didn't find any discussion of that in the LISP 
mailing list archives.

According to the LISP Charter the document is to request "address 
space to be used for the LISP experiment as identifier space".  The 
draft is reserving a /16 and there is scope to have that extended to 
a /12 in future.  This goes beyond the usual experiments.  There 
isn't any discussion of how the ip6.arpa delegation will be 
handled.  There isn't any discussion of how long the experiment will 
last.  I understand that IPv6 is not a scare resource.  However, that 
is not a reason for handing out address space and leaving it to 
someone in future to figure out what to do if this becomes a problem.

I haven't seen anyone asking why the document is not a BCP.  If the 
aim is to have:

   "Routers in the Legacy Internet must treat announcements of prefixes
    from the IPv6 EID Block as normal announcements, applying best
    current practice for traffic engineering and security."

I think that the document might have to be a BCP.  It would be good 
to be clear about whether the address space should be listed in the 
IANA IPv6 Special Purpose Address Registry.

Section 5 mentions that "The working group reached consensus on an 
initial allocation".  Could the document shepherd upload the write-up 
and provide some details about that?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/lisp/current/msg03848.html

---

From: Geoff Huston <[email-masked]>
Date: Fri, 16 Nov 2012 04:58:44 +1100

> You are right that it should be clearly stated, to make the document coherent. Will fix. thanks

it would be very helpful for the document to clearly show the basis for the calculation of a /12. Why a /12 and not any other size? What are the underlying estimates here? Why do they lead to the conclusion of a /12?

I am uncomfortable with the rather vague nature of the justification being shown here, and I don't think that this document as it stands is ready for publication. 

Geoff

---

From: Arturo Servin <[email-masked]>
Date: Thu, 15 Nov 2012 16:13:59 -0200

Luigi,

> no central registry has been ever discussed, was more about delegated the space to LISP ISPs.

	How are you going to allocate space to ISPs?

	Who is going to track the allocations made to ISPs, how are they going
to be published, what are the requirements to ask for space, what data
needs to be registered, where I can see allocations data?

	You asked George why the document is not ready to be published. Well,
the undocumented rules on how the space is going to be managed is one
important reason IMHO.

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Thu, 15 Nov 2012 16:47:20 -0200

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, in general."
But then it should be written somewhere in the document.

	Although it could be enough only to clearly say that a deployment guide
would define allocation guides in the future; for the sake of clarity
and usefulness (now, after the space is allocated by IANA it will be
there left unused because there is not a clearly indication how is going
to be used) I would recommend to discuss how the space is going to be
allocated.

Regards
as

On 15/11/2012 16:25, Dino Farinacci wrote:
> This is PI space. The registries will take portions of this space to allocate to end devices.  This is endpoint ID space. ISPs will continue to allocate addresses for LISP RLOCs. And they will have to allocate orders of magnitude less address space now.
> 
> Registries will track allocations to end sites.
> 
> This draft is purely a draft to REQUEST space. There will need to be a deployment guide on how to allocate EIDs, in general.
> 
> Dino
> 
>>
>> Regards,
>> as
>> 	
>>
>>>
>>> Luigi
>>>
>>>
>>>> - Sander
>>>>

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 20:51:30 +0100

Hi,

> 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 to REQUEST space. There will need to be a deployment guide on how to allocate EIDs, in general.

And if the RIR system is used every RIR will develop its own policy for allocating EIDs independently (hopefully based on the recommendations in such a deployment guide). It will have to be very clear whose responsibility it is to allocate from this space, and when assigning responsibility it might be a good idea to make sure they accept that responsibility too.

Note that I am not opposing the idea. I'm just trying to make sure this address space doesn't disappear into a black hole because nobody takes the responsibility to manage it.

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

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 21:03:58 +0100

Hi Dino,

> 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 this space then that is not the IETFs decision to make. That responsibility lies with the policy-making community in the RIR's region. And in the RIPE region there is ongoing work to write a policy that removes the distinction between PA and PI for IPv6. So don't make any assumptions here.

Also: if they are handed out as PI addresses there is still the question of who is going to run the PxTRs for that space. No operator will route the whole /12 or /16 for free. Besides the cost, that would put us back to the 6to4 mess: being dependent on (possibly unknown) 3rd-party relays that you have no business relationship with. Assigning the addresses as PI would mean that every block has to be routed separately, which will fill up the routing table. PA would make aggregation possible but tie the end-user to one LISP-ISP, and that ISP might then just use their existing PA block anyway (without using up an extra BGP routing table slot).

I think it should be clear who is going to manage the address space before requesting it.
Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 22:26:52 +0100

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
> 
> I don't think that (by definition) there is any way to cleanly aggregate PI space.  Legacy advertisements are going to be done by their LISP provider and will have to match the endpoint's PI allocations.

Yeah, so RIR policy-making communities might want to allow for LISP-PA space for example. I don't think we can make assumptions about that here. The other side of this is then: why not use 'normal' address space? If it is going to be announced in the legacy global BGP table anyway by some LISP provider I can't see why an end-site would choose for the LISP block instead of the more flexible regular block (which can then also be used as EID space)...

Thanks,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 22:31:59 +0100

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 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 rather than asking the mapping system.

I don't agree. For example: I'm using regular space for LISP EIDs now, so you can't assume that if it's not in this block that it's not in the mapping system...

> Right.
>> 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,
> 
> Why not?

Because the RIR communities will probably just refuse to allocate from this space if it means that all those routes end up in the BGP table... They are already plenty of people that don't like regular PI policies...

>> which will make a mess of the global IPv6 routing table...
> 
> And why do you think you need to assign PITRs per sub-block?

I hope that is not necessary, but if addresses are assigned to end-sites directly in a PI-like way then who is going to provide PITR services for the users? Someone has to pay the bandwidth cost for operating a PITR... And the users of that space want reliability, so they are not going to rely on the goodwill of some unknown 3rd parties. There is too much bad experience with 2002::/16 for that.

If you see another way that I am missing please let me know! I want this to work, I just don't see how...
- Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 22:34:34 +0100

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 someone wants to be provider independent I'll route their PI space for them as well. I'm just hoping that we can avoid any BGP routing table mess...

Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 22:48:42 +0100

Hi,

> That is why I capitalized "COULD".

Ok :-)

But I think it comes down to
  COULD ignore that certain EIDs are in the mapping system and always route them legacy-style

I wouldn't agree with
  COULD know if certain addresses are EIDs or not by looking at the prefix
because any address space can be used as EIDs now. Or are you proposing to deprecate the use of all other address space as EIDs?

> You have all the PITRs in the world advertise only the one /12 into underlying routing.

ROFL. No sorry, that's not going to work
a) they would have to pay all the bandwidth cost for users of that EID space that they have no business relation with
b) as a user of that EID space I would be at the mercy of PITR operators that I don't even know
c) See all the arguments about why 6to4 is unreliable. They'll apply here too

>> I hope that is not necessary, but if addresses are assigned to end-sites directly in a PI-like way then who is going to provide PITR services for the users? Someone has to pay the bandwidth cost for operating 
> 
> PITR services are provide for non-LISP sources to send to these sites. If you have a well-known defined /12 that all PITRs advertise, then when you allocate sub-blocks, you don't have to change, reconfigure, or touch the 1000s of PITRs deployed.

What makes you think that all those PITRs will pay the cost for routing all that traffic?

>> a PITR... And the users of that space want reliability, so they are not going to rely on the goodwill of some unknown 3rd parties. There is too much bad experience with 2002::/16 for that.
> 
> We do that all the time on the Internet unless you sent this email on a source-route to me. ;-)

No, sorry. I now pay my ISP to make sure my connectivity works. In your example I'm going to rely on some unknown PETR for outbound traffic and on whatever PITR is closest to the other side for my inbound traffic. I might be able to control the PETR, but not the PITR because that depends on the routing from the other side. We have been here before with 2002::/16. Don't repeat that huge mistake!

- Sander

---

From: George Michaelson <[email-masked]>
Date: Thu, 15 Nov 2012 23:24:57 +0100

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 space. This demands rigour in the process to apply, even a reservation requires a sense of why, and justification. "we think its about right" isn't appropriate and the document needs more work to specify why a 16, and why a /12, and what the implications are of eg a smaller allocation under a /16 reservation, or some other size (a /32 even, for which there are both precedents, in experimental allocations, and an existing process inside the RIR address management framework).

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 system try very hard not to be placed in a position of making arbitrary subjective decisions: they have processes which are designed to ask for objective justifications to specify why an allocation should take place, and at what scale. Those objective criteria face addresses as addresses. not EID.

For an example: IPv6 address allocation process currently is implemented using sparse allocation (binary chop with some modifications) in the APNIC region. This maximises space around allocations to equalise the distribution of free blocks such that the commons, the unallocated space, remains as usefully large as possible and when the next binary stride is entered, there is some understanding its going to be applied in common to all occupants of that region of space (in terms of the size of hole around them, which is not a reservation per se, but provides for risk-management of future growth to the largest extent).

We're really quite proud of sparse: its extended the life of the /12 we occupy quite markedly. What impact will EID have on this? Is sparse an appropriate allocation engine to use for EID? What if eg you have expectations of almost-geographic aspects of address management in EID. Doesn't that require documentation as a process? And, you may be specifying a cost on the RIR system, to engineer support for the new allocation logic. If it doesn't logically fit in sparse allocation, we need to know. And we need to know why.

EID are not going to be used like 'normal' addresses. So, the normal justifications don't look entirely appropriate to me from 10,000ft. The document needs to say "maybe we need to understand the allocation processes that the RIR should objectively apply" or maybe you need to step outside of draft space and engage inside the RIR policy process and seek a global policy which can document the process.

To ask for an IANA allocation without having undertaken this process looks wrong to me. So, I stand by my concern the document isn't ready for IETF last call: it hasn't addressed substantive issues around the process and expectations of address/registry function, to manage the /16, and it hasn't documented the basis of asking for a /16 in the first place, or a /12 reservation.

cheers

-George

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Nov 2012 17:39:31 -0500

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 needed to 
respond to a PI request.

Yours,
Joel

---

From: Sander Steffann <[email-masked]>
Date: Thu, 15 Nov 2012 23:41:43 +0100

Hi,

> 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 :) )

> You can configure a device to be more restrictive. And this would be the case in the non-capital I internet.

Ok

> I'm sorry, it can work and people will WANT to do this. Infrastructure providers do want to attract traffic.
> 
> If you have enough PITRs spread around the Internet, it works no differently than a set of boxes at a public inter-connect that advertises the same prefix (to say google).

Yes, but there is a big financial incentive for Google to maintain that.

> 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 6to4 and the 2002::/16 prefix before continuing this discussion.

> You are at the mercy of your DNS server, are you not? It is the same thing. So let's not make things more complicated.
> 
> Then you deploy an ITR at your site. You will want to for other reasons, so you kill the problem you think you have.
> 
> Pay the cost? The cost is the bandwidth that is already provision to come into those boxes. And infrastructure providers do want to attract traffic.

That assumes that *everybody* runs such a PITR... Otherwise the company running the PITR will attract traffic from other's and pay for the bandwidth.

>> No, sorry. I now pay my ISP to make sure my connectivity works. In your example I'm going to rely on some unknown PETR for outbound traffic and on whatever PITR is closest to the other side for my inbound
> 
> Don't change the context of this discussion. We are talking PITRs. PETRs are something completely different.

Yes, and I explicitly mention below that you *can* control those.

>> traffic. I might be able to control the PETR, but not the PITR because that depends on the routing from the other side. We have been here before with 2002::/16. Don't repeat that huge mistake!
>> 
>> - Sander
> 
> This is now off topic. The draft has nothing to do with PITR deployment.

*you* are the one suggesting that PITRs will be deployed that handle the /12 or /16 that is being proposed in this draft. Getting this EID address accessible from non-LISP sites needs PITRs, so it is very much on topic.

Please read up on the mess that RFC 3056 caused. There is a good reason that RFC 6724 depreferenced 2002::/16. It explicitly says (although it contains an error, it says 2002::/32 when 2002::/16 is meant): "Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 connectivity is less reliable today (and is expected to be phased out over time, rather than becoming more reliable)." The EID prefix has the same problems as the 6to4 prefix.

Before requesting address space for EIDs I think we need to know how it's going to be distributed (RIRs, separate registry (actually doesn't have to be a bad idea!)) and how it's going to be routed (like PI space is today with every end-site a separate entry in the global BGP table, like, PA space where a LISP-ISP provides aggregation, like 6to4 is with the whole prefix anycast by open relays, ...)

Please understand that I am u huge fan of LISP (my home network and lab networks are all using LISP). I am just not very sure if we really need this EID prefix. I am afraid it will do a lot of harm if defined, distributed and routed badly.

- Sander

---

From: Arturo Servin <[email-masked]>
Date: Thu, 15 Nov 2012 20:48:51 -0200

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:

"
4.5.4.1. Direct assignment of portable IPv6 addresses to End Sites
having portable IPv4 addresses previously assigned by LACNIC
LACNIC will assign portable IPv6 address blocks directly to end sites if
they hold portable IPv4 addresses previously assigned by LACNIC.
In case of announcing the assignment on the Internet inter-domain
routing system, the receiving organization shall announce the block
maintaining de-aggregation to a minimum in accordance with the
announcing organization's needs.
Assignments will be made in blocks smaller than or equal to a /32 but
always greater than or equal to a /48.
Where possible, subsequent allocations will be made from an adjacent
address block, but only if duly documented and justified.

4.5.4.2. Direct assignment of portable IPv6 addresses to End sites not
having portable IPv4 addresses previously assigned by LACNIC
LACNIC will assign portable IPv6 address blocks directly to end sites
that satisfy the following requirements:
Not be an LIR or ISP.
In case of announcing the assignment on the Internet inter-domain
routing system, the receiving organization shall announce the block
maintaining de-aggregation to a minimum in accordance with the
announcing organization's needs.
Provide detailed information showing how the requested block will be
used within the following three, six and twelve months.
Submit addressing plans for at least a year, and host numbers on each
subnet.
Submit a detailed description of the network topology.
Prepare a detailed description of the network routing plans, including
the routing protocols to be used as well as any existing limitations.
Assignments will be made in blocks smaller than or equal to a /32 but
always greater than or equal to a /48.
Where possible, subsequent allocations will be made from an adjacent
address block, but only if duly documented and justified.
"

	So, are you expecting these to be the rules over the /16 that you are
requesting?

	As I said to Dino, you are free to leave the rules for later
definition, but that IMHO would demerit the request making the space
basically useless.

Regards,
as

On 15/11/2012 20:39, Joel M. Halpern wrote:
> significance.  They do not have IP Routing topological significance. The
> are not aggregateable.
> 
>> 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 space. This demands rigour in the
>> process to apply, even a reservation requires a sense of why, and
>> justification. "we think its about right" isn't appropriate and the
>> document needs more work to specify why a 16, and why a /12, and what
>> the implications are of eg a smaller allocation under a /16
>> reservation, or some other size (a /32 even, for which there are both
>> precedents, in experimental allocations, and an existing process
>> inside the RIR address management framework).
>>
>> 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 system try very hard not to be placed in a position of making
>> arbitrary subjective decisions: they have processes which are designed
>> to ask for objective justifications to specify why an allocation
>> should take place, and at what scale. Those objective criteria face
>> addresses as addresses. not EID.
>>
>> For an example: IPv6 address allocation process currently is
>> implemented using sparse allocation (binary chop with some
>> modifications) in the APNIC region. This maximises space around
>> allocations to equalise the distribution of free blocks such that the
>> commons, the unallocated space, remains as usefully large as possible
>> and when the next binary stride is entered, there is some
>> understanding its going to be applied in common to all occupants of
>> that region of space (in terms of the size of hole around them, which
>> is not a reservation per se, but provides for risk-management of
>> future growth to the largest extent).
>>
>> We're really quite proud of sparse: its extended the life of the /12
>> we occupy quite markedly. What impact will EID have on this? Is sparse
>> an appropriate allocation engine to use for EID? What if eg you have
>> expectations of almost-geographic aspects of address management in
>> EID. Doesn't that require documentation as a process? And, you may be
>> specifying a cost on the RIR system, to engineer support for the new
>> allocation logic. If it doesn't logically fit in sparse allocation, we
>> need to know. And we need to know why.
>>
>> EID are not going to be used like 'normal' addresses. So, the normal
>> justifications don't look entirely appropriate to me from 10,000ft.
>> The document needs to say "maybe we need to understand the allocation
>> processes that the RIR should objectively apply" or maybe you need to
>> step outside of draft space and engage inside the RIR policy process
>> and seek a global policy which can document the process.
>>
>> To ask for an IANA allocation without having undertaken this process
>> looks wrong to me. So, I stand by my concern the document isn't ready
>> for IETF last call: it hasn't addressed substantive issues around the
>> process and expectations of address/registry function, to manage the
>> /16, and it hasn't documented the basis of asking for a /16 in the
>> first place, or a /12 reservation.
>>
>> cheers
>>
>> -George

---

From: George Michaelson <[email-masked]>
Date: Fri, 16 Nov 2012 09:38:13 +0100

On 16/11/2012, at 7:24 AM, Dino Farinacci <[email-masked]> wrote:
> No, I am not making any assumptions either way. How allocation gets done is subject to more work.

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.

> There is no special semantics of EIDs that require you to change this. EIDs are just addresses that do not get injected into the underlying routing system. Other than that, they are just like any other address an RIR allocates.

But by not being injected in the routing system they've already got a qualification against normal allocations, which are for globally routed addresses. So if under current criteria, somebody fronts to the RIR system and asks for a unique address assignment NOT to be globally routed, what do you think happens?

We try not to 'just make it up on the fly' -If there is going to be an EID space, shared footprint, with this behaviour, it will need to be documented in RIR policy.

> What Joel said.

4.  Expected use

   Sites planning to deploy LISP may request a prefix in the IPv6 EID
   Block.  Such prefix will be used for routing and endpoint
   identification inside the site requesting it.  Mappings related to
   such prefix, or part of it, will be made available through the
   mapping system in use or registered to one or more Map Server(s).
   Too guarantee reachability from the Legacy Internet the prefix could
   be announced in the BGP routing infrastructure by one or more
   PITR(s), possibly as part of a larger prefix, AGGREGATING several
   prefixes of several sites.

[my emphasis]

7.  Routing Considerations

   In order to provide connectivity between the Legacy Internet and LISP
   sites, PITRs announcing large AGGREGATES of the IPv6 EID Block could
   be deployed.  By doing so, PITRs will attract traffic destined to
   LISP sites in order to encapsulate and forward it toward the specific
   destination LISP site.  Routers in the Legacy Internet must treat
   announcements of prefixes from the IPv6 EID Block as normal
   announcements, applying best current practice for traffic engineering
   and security.

[my emphasis]

thats in the 03 draft. So, naievely, I read that as meaning global unicast Aggregation. If it refers inside LISP only and is not implying aggregatable assignment to end entities holding EID, if EID are unique only and can be sparse and disjoint, Thats good to know.

>> EID are not going to be used like 'normal' addresses. So, the normal justifications don't look entirely
> 
> Define how a 'normal address" is used.

globally routable (normally) for starters. With assignment dynamics which relate an end-site to a customer, so with some scaling which reflects demand and the depth of network complexity to achieve it. Which is specified at time of assignment and tracked for subsequent reallocation/growth. 

Address management has costs btw. I expect many people in this community are concerned by that and there are times quite unpleasant language is used about the RIR process and its cost recovery needs, but it can't be avoided. So in that context, did you expect EID allocation and address management to be free? Its got to reflect its societal costs like other addresses is a possible position.

> 
>> appropriate to me from 10,000ft. The document needs to say "maybe we need to understand the allocation processes that the RIR should objectively apply" or maybe you need to step outside of draft space and engage inside the RIR policy process and seek a global policy which can document the process.
> 
> The working decided that this draft is solely for request purposes. We could use help from RIRs to write a document on how to allocate EIDs. But I am pretty sure it would look like documents that already exist.

Yes, but the conversation would be useful. So why not come into RIR policy development process and kick off a conversation about global address policy (which this clearly is)

Seriously: this could be talked about.

> 
> I don't understand why you think they look different or need to be treated differently. So you have to do the explaining.  ;-)

Cute. I'd like this document to explore the need for work in the area and say its for further study, and observe the IAB/IANA instruction might be pending that further work, because assigning a block without objective criteria and a global policy in RIR Process is not a good idea.

I really don't think the IAB should simply give the /12 on the basis of this document. If another document needs to be spun then this one can sit at IETF last call and share fate.

> Here is a real world example we have been using on the LISP beta network. It is so simple that it really needs no more explanation than what I am going to explain below:
> 
> (1) We have 2610:00d0::/32 allocated for EIDs.
> (2) Each site on the LISP beta network gets a /48 out of that.
> (3) Each site xTRs register their /48 with the mapping system using RLOCs that are PA addresses they use to attach to the Internet.
> 
> That is it. So I am not getting why there are so many issues. Can't we keep this simple and experiment please?

Ok. So work with me on this a bit Dino. I realize you are very busy, but I want to understand.

1) how many /48 have been allocated thus far from this experimental /32? it has 65,000 of them. The dynamics of the rollout would be very interesting.

I'm really interested in this number. Its pretty fundamental to an address application/reservation facing the IAB/IANA and I expect you will be asked it more formally anyway (not by me. I dont do this stuff, but its forseeable). Bearing in mind that Sander Steffan has already shown global-unicast can be used for EID, I don't expect it to be equivalent to the count of EID visible in LISP routing.
t
Anyway, even with that caveat 65,000 is quite a lot. If you've achieved high density, the experiment has very interesting scaling and we need to know. In particular, I would suggest that its possibly less an experiment, and more a product. If its in production, then applying under experimental criteria is a bit of a concern for me.

2) how many /48 do you foresee being allocated in a 1,2,5 year footprint heading to the /16 horizon? There are 4 billion /48 in a /16 

3) how many /48 do you foresee being allocated in the 5,10,20 year footprint heading to the /12 horizon? 

I have to say that to achieve 2) I do not believe this could be in any real sense "an experiment" except to the extent the entire IPv4 network we have is an 'experiment' because 2^32 is looking like a very large amount of EID, equivalent to the entire IPv4 space.

So from here, I can't grasp the /16, let alone the /12. If this is an experiment, then I think we should be having a conversation about what size above a /32 achieves your goals. If there is to be a reservation, we should understand the scoping it can grow to, which begins to look more like the /16 than the /12, although I suspect its a lot smaller than the /16 and more like a /22

[I am not a hostmaster and this is most definitely not an APNIC position: its my personal view]

BTW, comparisons to the /12 of 2002: are very unhelpful to your case. Firstly, it was a transition technology, in the main an automatic tunnelling mechanism and not structured, and the sub assigns in the space reflected their global routing via the IPv4 label embedded.

Secondly, there were very real administrative issues facing 2002: in terms of reverse-DNS, and the over-reach of an ISPs routing footprint and intrusion of services.

I think the /12 reflected the needs of the format to embed the server,client pairs into the footprint of address. Since you have demonstrated your EID is in /48, the size of the parent above that in global routing does not need to be the same as 2002 which depended on totally ad-hoc server IPs and the anycast cloud instance as fallback. 

I may be wrong, but I suspect if the 2002 protocol spec had been written not to need the /12 it would not have been assigned a /12.

I think in hindsight the Teredo footprint of a single /32 in 2001:0: is equally instructive. Microsoft deployed this into their core technology worldwide. clearly, a single /32 can scale to an entire global Internet for this class of tunnel. I appreciate that EID is a different kind of tunnel, but the difference tends to less EID doesn't it?

cheers

-george

---

From: George Michaelson <[email-masked]>
Date: Fri, 16 Nov 2012 09:42:00 +0100

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Nov 2012 09:05:26 +0000

On 15/11/2012 22:41, Sander Steffann wrote:
...
> Yes it is. *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 cooperation between operators, to ensure
that there was a useable route to 2002::/16 *everywhere* in the
IPv6 network. That assumption was naive and led to black holes.

My main concern with LISP deployment is whether there will be
a useable route to EID space *everywhere* in the (non-LISP)
network. If that also relies on altruism, I would share Sander's
concern.

     Brian

---

From: Sander Steffann <[email-masked]>
Date: Fri, 16 Nov 2012 11:18:15 +0100

Hi Dino,

> George:

+1

Let's make it official :-)

It would be very good to discuss this idea in the RIR communities. I think both the LISP community and the RIR communities can learn from each other. As co-chair of the RIPE Address Policy Working Group I would really appreciate it if you could come to the next RIPE meeting to discuss this. I'll make sure that there is a slot on the working group agenda. RIPE 66 will take place from 13-17 May 2013 at the Burlington Hotel in Dublin.

Thanks,
Sander

---

From: Arturo Servin <[email-masked]>
Date: Fri, 16 Nov 2012 08:51:03 -0200

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 be happy to help to review, comment and even write some
text if that is useful for lisp.

Regards,
as

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 16 Nov 2012 12:57:32 +0100

> beginning of the Subject line to allow automated sorting.

I think LISP is an important factor in the future of Internet and I do
support the idea of having different IP block for LISP based network.

However, I can not support the publication of this document, it has
some unclear issues that need good answers first.

Anyhow, I see two issues that need to be addressed better

1.) How should the address space be administrated, RIR structure or
something else closer to 6bone? I support the suggested idea of
discussing this part with the different RIRs to look more into how
this are going to work in practice.
And as Dino said, "No, I am not making any assumptions either way. How
allocation gets done is subject to more work." the document should
state this.

2.) The interaction between none-LISP and LISP Internet. This problem
has two sub-problems within it

a.) Why is there a need for a special LISP block. This is partly
answered in section 3.  Rationale and Intent. Is this the entire
reason?

<start copy'n'paste>
   With the current specifications, if an ITR is sending to all types of
   destinations (i.e., non-LISP destinations, LISP destinations not in
   the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the
   only way to understand whether or not to encapsulate the traffic is
   to perform a cache lookup and, in case of cache-miss, send a Map-
   Request to the mapping system.  In the meanwhile, packets can be
   dropped.
<end copy'n'paste>

b.) 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. Are there
an assumption that some ISPs will announce the entire LISP space (/16
are mention) for free ?
If each and every EID space holder (/32 or similiar) each have to
connect to Internet and get their address space routed, then it's
nothing different than regular RIR allocated /32's.

Address these thing somehow in the document, even just mention that
it's subject for other document and I'm happy... :-)

--

---

From: "George, Wes" <[email-masked]>
Date: Fri, 16 Nov 2012 08:26:50 -0500

> From: [email-masked] [mailto:[email-masked]] 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 cooperation between operators, to ensure that there was a
> useable route to 2002::/16 *everywhere* in the

[WEG] The other problem with 6to4 is that by the time we tried to shut it down because we determined that it wasn't working acceptably and/or had fatal flaws in its design, there was a small (but extremely vocal) group of people who basically said "you can have 6to4 back when you pry it from my cold, dead fingers!!" -- perhaps we can kill two birds with one stone if you can convince those same people to let you repurpose the 2002::/16 space for LISP?

*ducks* :-)

More seriously:

I echo the concerns that others have raised about the questionable justification for a /12 or /16, the limited details around how allocation and management might work, and the recommendation to go talk to the RIRs and learn how address allocation might work so that you can give them helpful recommendations when (and if) it comes time to write RIR policy to manage this space. I'd rather this not be deferred to a later document, because there is little incentive to complete such a document once the allocation is already made. Either you know how this will be used and can articulate it, or you don't. If you don't, you aren't ready to request it.

Additionally: The LISP documents are classified as experimental (though this one is not...). Therefore I see two possible solutions that don't appear to have been discussed yet:
1) the RIRs have existing policy regarding experiments (e.g. https://www.arin.net/policy/nrpm.html#eleven ). You might consider looking at those policies to see if getting a direct allocation from one or more RIRs for your experiment would be a workable solution, rather than locking space into this via IANA.
2) Request the space (with improvements to the request as stated above and elsewhere in this thread) but include a sunset date for the allocation from IANA. If the experiment is successful, the expectation is that you will write proposed standard drafts refine the implementation and to make it not experimental, and you can make the IANA allocation permanent at the same time. If the experiment is not successful and this space is no longer needed in a few years, we don't have to fight a small vocal minority to shut it down. (c.f. RFC3701). While I'm *less* worried about us "wasting" IPv6 space, it's not infinite, and I'm having visions of the IPv4 Class E space, where we have this sizable chunk of addresses allocated for a special purpose that 10 years from now could (and should) be used for something else, and inertia means that they never do, filed under "it seemed like a good idea at the time..."

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Nov 2012 11:00:19 -0500

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 term experiments, and for implications on other parties, the 
allocation policies matter more.

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 experiment, and one should expect that the 
actual path will be different from the expectation.)  Given that 
interworkng dives are data plane devices, altruism is clearly not a 
sufficient incentive to get this to scale, and the models do not depend 
upon that.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Nov 2012 16:35:51 +0000

Joel,

On 16/11/2012 16:00, Joel M. Halpern wrote:
...
> sufficient incentive to get this to scale, and the models do not depend

My concern with this allocation request was not about scaling
but about black holes. What are the incentives for operators not
very interested in LISP to carry the routes that make it work?
That's the root of many of the problems with 6to4 (and, I think,
many of the problems of the MBONE, for those with long memories).

Regards
    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 10:25:56 -0800

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 11:27:21 -0800

> But then it should be written somewhere in the document.

I agree the wording in the abstract and introduction should be a bit stronger and/or more direct.

> to be used) I would recommend to discuss how the space is going to be

Sure, good comment.

Dino

---

From: Paul Vinciguerra <[email-masked]>
Date: Thu, 15 Nov 2012 20:21:56 +0000

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 13:24:18 -0800

Right.

Why not?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 13:25:35 -0800

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 13:36:38 -0800

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 14:04:22 -0800

> 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. You are at the mercy of your DNS server, are you not? It is the same thing. So let's not make things more complicated.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Nov 2012 22:24:08 -0800

> 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 fo…

Sure.

> a /12 is a very large amount of space. This demands rigour in the process to apply, even a reservation requires a sense of why, and justification. "we think its about right" isn't appropriate and t…

Okay.

What Joel said.

Dino

---

From: Paul Vinciguerra <[email-masked]>
Date: Fri, 16 Nov 2012 13:06:02 +0000

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 non-LISP endpoint, and there is a cache-miss, isn't the packet forwarded to the destination, hoping that the packet can be delivered unencapsulated because it is not and EID, or that there is a legacy aggregate being announced that knows the destination to deliver the encapsulated packet until the xTR's cache populates? 

Section 3 states:

By defining an IPv6 EID Block [, it] is possible to configure the router so
   to natively forward all packets that have not a destination address
   in the block, without performing any lookup whatsoever.

This reads as if the intent is to set a policy that would only allow LISP encapsulation to IPv6 destinations within this new block and to remove the existing ability to encapsulate to existing v6 EID's in the DDT.  The implication to me is that if I have existing v6 space, I must provide legacy transit through my own PxTR's, almost as a second class citizen as I will be assured a suboptimal path.

Do I have this wrong?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Nov 2012 12:26:48 -0500

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 of their customers may use, whether the operator 
carrying it knows that or not.

In fact, it would take significant extra work for the operator to 
somehow block this aggregate.

If LISP fails, this is a small cost to find out.
If LISP succeeds, this results in significant reduction in core tabl 
sizes for everyone.

Yours,
Joel

---

From: SM <[email-masked]>
Date: Fri, 16 Nov 2012 09:36:02 -0800

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 discontent? :-)

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg75881.html

---

From: Sander Steffann <[email-masked]>
Date: Fri, 16 Nov 2012 22:12:53 +0100

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 entry that some of their customers may use, whether the operator carrying it knows that or not.
> 
> In fact, it would take significant extra work for the operator to somehow block this aggregate.
> 
> If LISP succeeds, this results in significant reduction in core tabl sizes for everyone.

That still assumes the altruistic routing of the prefix. And I am afraid that if the usage of this block gets a bad reputation that all LISP usage will share that reputation. I really like LISP but I am still not convinced that it's a good idea. If we can find a way to get the EID prefix routed in a reliable way then I would love it!

I really care about LISP and I am afraid that: people see unreliable routing for EID /16 => assume LISP is unreliable. That is why I am pushing so hard to get this sorted out.

Hmmm. What about the following strategy:
- Start with the EID prefix being handed out like PI
  - Either through the RIRs if they are willing to take the responsibility
  - Or from a separate registry
- Some altruistic /16 PITRs might show up in the global BGP table
- A holders of a (assume) /48 from the EID prefix can arrange PITRs for their own space
  - And announce it as a separate route in the global BGP table (for now)
  - Keep the routing and reliability under their own control
- If the experiment is a success we advise ISPs to:
  - Install their own PITRs for the /16
  - Filter out the /48s at their border

The filtering of the more-specifics once they have their own PITRs will make sure that they use those PITRs and that they will use the most optimal path to the locators as soon as possible. It will also keep their routing table smaller. If enough big transit providers offer /16 PITRs to their customers then the more-specifics might be filtered on a larger scale.

So, summary:

The ways to reach a PITR would be
a) Run your own PITR (big networks, LISP users)
b) Use one from your transit(s) (smaller networks that don't have their own)
c) Use an altruistic one as last resort

As long as (a) and (b) aren't a reality the LISP users who don't want to rely on (c) can run/rent/etc a PITR for their own space. I think the routing community would really appreciate it if all those more-specific routes would be temporary until wide deployment of (a) and (b) make them unnecessary.

And if this doesn't become a success we have a bunch of /48 prefixes to the separate PITRs in the BGP table. It won't be much, otherwise we would have declared success. So the risk of messing the BGP table up is very limited. And when can tell people: if you are bothered by those more-specifics in your routing table you can always deploy your own PITRs and filter the more-specifics at your border. That might keep everyone happy.

What do you think?

Thanks,
Sander

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 16 Nov 2012 13:33:12 -0800

sizes for everyone.

Not everyone. Only people who carry core tables.  That is LISP twist, it
transfers cost from a few cores to many edges. Associated pros and cons
exist.

CB

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Nov 2012 18:19:42 -0800

Good points Joel. I completely agree. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 17 Nov 2012 09:51:54 -0800

> 	+1 In LACNIC, may 6th to 10th 2013 in Medellin Colombia.

Will consider Singapore and Medellin.

> text if that is useful for lisp.

Thanks for the offer.

Dino

---

From: Geoff Huston <[email-masked]>
Date: Sun, 18 Nov 2012 17:20:58 +1100

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 global unicast address allocations, and proceed along those grounds?

Indeed if the entire point of this experimental use allocation request is on the basis that at the time when deployment numbers are sufficiently large (orders of millions of end sites presumably) then this block allocation will have some beneficial effects. But thats NOT an experimental justification.

So what is this request? Experimental? Planning for large scale deployment?

If its the latter than I do not understand how this draft, calling for a allocation from the IANA special purpose address registry on the grounds of supporting an IETF experimental activity, can be supported by the existing processes. The IANA Special purpose address registry and RFC 4773 do not encompass the allocation of address blocks for use in a global unicast address context in the context of large scale deployment activities.

If its the former then the scale of the allocation is unwarranted. The broad characterisation of the experiment allocation is to test concepts, and if that's the case then once the "test" is over what are the plans to migrate OUT of the "test" allocation and support unicast global address allocations in the context of LISP under the general framework of RFC2860 and RFC 2050? What is the scale of this "test"? When would the "test" be completed?

I think this draft is not well thought through and the draft's proposals for address allocation from the IANA Special Purpose Address Registry  is inconsistent with the processes we use for management of addresses in the IETF. I do not support the publication of this draft.

regards,

   Geoff

On 17/11/2012, at 8:19 AM, Joel Halpern Direct <[email-masked]> wrote:

> 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 individually.  The WG felt that if we could get all IPv6 LISP EID allocations from a single block that was not used for anything else, that would simplify avoiding lookups in the mapping system that were inevitably going to fail.  Thus the allocations request.
> 
> Yours,
> Joel
> 
> On 11/16/2012 4:12 PM, Sander Steffann wrote:
>> Hi Joel,
>> 

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 16 Nov 2012 16:19:12 -0500

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 individually.  The WG felt 
that if we could get all IPv6 LISP EID allocations from a single block 
that was not used for anything else, that would simplify avoiding 
lookups in the mapping system that were inevitably going to fail.  Thus 
the allocations request.

Yours,
Joel

---

From: [email-masked]
Date: Sun, 18 Nov 2012 03:39:59 -0500 (EST)

And:
LISP does neither describe how to cope with the address depletion issue nor prove that it is able to.

Imho, there is not even the slightest chance not to fail.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Geoff Huston <[email-masked]>
An: Joel Halpern Direct <[email-masked]>
Cc: ietf <[email-masked]>; lisp <[email-masked]>; Brian E Carpenter <[email-masked]>
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

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 global unicast 
address allocations, and proceed along those grounds?

Indeed if the entire point of this experimental use allocation request is on the 
basis that at the time when deployment numbers are sufficiently large (orders of 
millions of end sites presumably) then this block allocation will have some 
beneficial effects. But thats NOT an experimental justification.

If its the latter than I do not understand how this draft, calling for a 
allocation from the IANA special purpose address registry on the grounds of 
supporting an IETF experimental activity, can be supported by the existing 
processes. The IANA Special purpose address registry and RFC 4773 do not 
encompass the allocation of address blocks for use in a global unicast address 
context in the context of large scale deployment activities.

If its the former then the scale of the allocation is unwarranted. The broad 
characterisation of the experiment allocation is to test concepts, and if that's 
the case then once the "test" is over what are the plans to migrate OUT of the 
"test" allocation and support unicast global address allocations in the context 
of LISP under the general framework of RFC2860 and RFC 2050? What is the scale 
of this "test"? When would the "test" be completed?

I think this draft is not well thought through and the draft's proposals for 
address allocation from the IANA Special Purpose Address Registry  is 
inconsistent with the processes we use for management of addresses in the IETF. 
I do not support the publication of this draft.

regards,

   Geoff

On 17/11/2012, at 8:19 AM, Joel Halpern Direct <[email-masked]> 
wrote:

> 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 individually.  The WG felt that if we could get all IPv6 LISP EID 
allocations from a single block that was not used for anything else, that would 
simplify avoiding lookups in the mapping system that were inevitably going to 
fail.  Thus the allocations request.
>>> If we get this block allocaed, then it results in 1 extra routing entry in 
the global routing table to support LISP inter-working.
>> That still assumes the altruistic routing of the prefix. And I am afraid that 
if the usage of this block gets a bad reputation that all LISP usage will share 
that reputation. I really like LISP but I am still not convinced that it's a 
good idea. If we can find a way to get the EID prefix routed in a reliable way 
then I would love it!
>> 
>> I really care about LISP and I am afraid that: people see unreliable routing 
for EID /16 => assume LISP is unreliable. That is why I am pushing so hard to 
get this sorted out.
>> The filtering of the more-specifics once they have their own PITRs will make 
sure that they use those PITRs and that they will use the most optimal path to 
the locators as soon as possible. It will also keep their routing table smaller. 
If enough big transit providers offer /16 PITRs to their customers then the 
more-specifics might be filtered on a larger scale.
>> As long as (a) and (b) aren't a reality the LISP users who don't want to rely 
on (c) can run/rent/etc a PITR for their own space. I think the routing 
community would really appreciate it if all those more-specific routes would be 
temporary until wide deployment of (a) and (b) make them unnecessary.
>> 
>> And if this doesn't become a success we have a bunch of /48 prefixes to the 
separate PITRs in the BGP table. It won't be much, otherwise we would have 
declared success. So the risk of messing the BGP table up is very limited. And 
when can tell people: if you are bothered by those more-specifics in your 
routing table you can always deploy your own PITRs and filter the more-specifics 
at your border. That might keep everyone happy.

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Wed, 21 Nov 2012 17:16:58 +1100

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 the framework of the Internet Registry system, and the roles
and responsibilities of various parties involved in the distribution of
addresses in the Internet. The document was not intentionally related to
any particular routing technology, and addressed guidelines that would
maximise the effective use of address space.

The Memorandum of Understanding between the IETF and ICANN over the IANA
activity, RFC2860, published in June 2000, provides further details of
the address management function. In particular, the document notes that
"assignments of specialised address blocks (such as multicast or anycast
blocks), and experimental assignments are not considered to be policy
issues, and shall remain subject to the provisions of this [document]."

RFC 4773, published in December 2006, provides some guidelines to the
IANA concerning the management of these specialised address assignments
in IPv6: "IANA may undertake IPv6 address designations in support of
special purposes as requested in "IANA Considerations" sections in IESG-
reviewed RFCs, where an address is requested with an intended use of the
designated address block for the purpose of testing or experimental
usage activities initiated by IETF, or for specialised use of the
address block in a context (e.g., anycast) associated with an Internet
Standards track protocol."

In this context the request to IANA to reserve an IPv6 /12 address and
allocate out of it a /16 block for use as an EID space for the
experimental LISP protocol presents some questions.

It is noted that the LISP experiment already makes use of a /32 prefix,
"with more than 250 sites using a /48 sub prefix", as noted in
draft-ietf-lisp-eid-block-03.txt. Even with an overall 50% utilisation
rate of this prefix there is scope in the current /32 address block to
address some 32,000 further sites using a /48 sub prefix.

If the LISP experiment fills this /32 prefix to such a level of
utilisation then there would be reasonable grounds to make the case that
at such a time the LISP activity would no longer be an experimental
effort, as it would be an instance of an application that makes use of
the global unicast address pool. In this case the provisions of RFC
4773, and the applicability of a special purpose address allocation
would not be expected to apply, as this would fall under the terms of
RFC2050 and the address allocation function would be administered by the
Regional internet Registries, according to RFC2860.

If we were to consider this request for the reservation of a /12 and the
allocation of a /16 in the context of support for an experiment, then
the nature of the experiment is unclear. At the scale of a /16 being
capable of supporting a theoretical maximum of some 4.3 billion /48 end
sites, and a /12 supporting a theoretical maximum of 68.7 billion /48
end sites, then the boundary conditions of such an experiment become
challenging to define. How can one define the experiment to have
finished? What are the plans to migrate out of the experimental address
allocation? Would this renumbering out of an experimental address
allocation even be feasible to contemplate if the experiment achieves a
level of deployment that is commensurate with the allocation of /16?

Such large scale deployment activities being undertaken under the
provisions of an experimental activity also raises a number of questions
about the registry services to be provided in support of such a
reservation. Given that this particular experiment is intended to
operate on the global IPv6 Internet it is apparent that some form of
directory (e.g. Whois) and reverse DNS services will be necessary; is
the provision of such services on a large scale (i.e. for potentially
tens of thousands of individual entities) to be performed by the IANA? 
If so then this appears contrary to RFC 4773's statement that the "IANA
will not maintain further sub-registries for any special purpose address
block designated according to this direction."  Further, the
implementation of any large scale directory such as resulting from this
type of experimental reservation would definitely pose serious policy
issues, e.g. trading off operational visibility, privacy, and law
enforcement needs, and by the spirit of the IETF/ICANN MOU on IANA
activities (RFC 2860). It would appear from this perspective that such
an assignment of address resources is not suitable to be made as an
experimental assignment.

The question this draft raises is to identify the basis of the request.
An experimental allocation of this size does not appear to be consistent
with a conventional view of an experiment. The draft's proposals appear
more aligned to the activity of planning for large scale public
deployment of a global routing infrastructure for global unicast
addresses. But if that is indeed the case then the provisions of RFC4773
do not apply, as the special Purpose Address Allocation Registry does
not encompass the allocation of address blocks for use in a global
unicast address context in the context of large scale deployment
activities.

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 requirements in the handling of global unicast address
allocations in IPv6 to the regional addressing communities. This would
allow the existing address policy development process to generate
outcomes that appropriately address the desires and concerns of the
broader community of stakeholders in supporting the potential
requirements of a broad base of deployment of LISP in the Internet's
routing environment.

We do not support the publication of this draft as an Informational RFC.

regards,

  John Curran,
  Paul Wilson, and
  Geoff Huston

---

From: SM <[email-masked]>
Date: Wed, 21 Nov 2012 02:29:24 -0800

>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].

>address some 32,000 further sites using a /48 sub prefix.

Yes.

>Regional internet Registries, according to RFC2860.

There is ample material in the Last Call comments to generate 
DISCUSSes.  The question is how many DISCUSSes will be filed.  It's 
easier to leave the progress of the draft to a matter of IETF 
consensus than to invoke the RFC 4773 or RFC 2860.  IANA is bound to 
follow technical guidance exclusively from the IESG.  It is 
improbable that IANA would invoke the dispute clause.

>allocations in IPv6 to the regional addressing communities. This would

Anything more than a /32 might have to be a global policy 
proposal.  It would likely take over a year to get such a proposal 
through all the RIRs.

Regards,
-sm

P.S. Don't boil the ocean to kill a single fish (credits - Noel Chiappa)

1. 
https://www.icann.org/en/news/in-focus/global-addressing/allocation-ipv6-rirs

---

From: Sander Steffann <[email-masked]>
Date: Wed, 21 Nov 2012 12:16:40 +0100

Hi,

> requirements of a broad base of deployment of LISP in the Internet's

So, if I understand you correctly you say that this should be a (global?) policy proposal in the different RIR regions. Is that correct?

If yes, then that could mean that every region allocates/assigns LISP prefixes from a separate block. Together with the current experimental /32 that would mean 6 prefixes for LISP in total. That's not as ideal as a single prefix, but still very acceptable for the BGP table.

If this wg agrees that this is the way forward then there are a few things that should be done as far as I can see:
- Define when the current experiment with the /32 is successful
- Document a vision of how LISP should be deployed using a few prefixes that cover all the LISP space
  - Advise on how LISP prefixes could/should be assigned
  - Probably also looking at different phases, for example:
    - Early adopters: separate PITRs+BGP routes for each /48?
    - Middle: central PITRs covering the whole LISP space (public? in tier-1 nets?)
    - Long term: LISP PITRs in all major networks
  - Describe a strategy to go from each phase to the next
  - How to deal with the prefixes if LISP isn't as widely accepted as we hope
- Writing a (global?) policy proposal for assignment of LISP prefixes
- Submitting that proposal to all RIR regions and try to get consensus there

I think that if we do the above we can show the operators a possible future where the BGP table isn't cluttered with PI prefixes. Worst case we end up with a prefix in BGP for every LISP end-site, but that's no worst than with current PI assignments. Best case we end up with a much smaller routing table (compared to normal PI) where all those end-sites are covered by a few prefixes. IMHO the most important thing is to plan on how to get there :-)

And yes: of course I volunteer to help writing this stuff :-)
Sander

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Nov 2012 02:09:47 +0700

Date:        Wed, 21 Nov 2012 17:16:58 +1100
    From:        Geoff Huston <[email-masked]>
    Message-ID:  <[email-masked]>

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
currently, might never do so), but I do know that this argument ...

  | The guidelines for IP address allocations were documented in RFC2050,
  | adopted in November 1996 as a Best Current Practice. ...

is totally bogus in these circumstances.

The rules in RFCs and BCPs bind ordinary users making ordinary requests
for address space - were I to approach IANA with a request for address
space to be allocated, a quick denial quoting the relevant RFC would indeed
be the correct response.

But when the IETF publishes an updated RFC, that always overrides any
earlier RFC, and establishes new policy - either for the general case, or
perhaps (as seems to be happening here) just a one off override of the
normal rules.

Doing that is always acceptable, whatever the issue - it is never adequate
to simply refuse to consider such requests upon the basis that they don't
follow the rules and should be done some other way.

Now, when the IETF (via the last call consensus mechanism) consider whether
the proposed RFC should be published, it is perfectly reasonable to point
out the existing policy, and ask for reasons why use of that mechanism would
not be adequate - if the proponents cannnot explain why doing it the way
they are suggesting is required, or at least is better than the normal way,
then the request (to publish the RFC, not just to perform whatever allocation
it requested - that just falls out of the failure to publish the RFC) should
be refused.

On the other hand, if the proponents can convince the IETF that the
procedure they're suggesting is the best way to proceed, then that's
what should happen - and that it isn't being done the way that the
normal allocation rules would suggest it should be done is 100% irrelevant.

If you have an argument against the proposal, please make it upon the
merits of the request, and not based upon some supposed viloation of
address allocation quidelines.

What the result will be I have no idea - I don't know if this allocation
should happen or not.   I might suggest however, that if Noel is correct
about the way this allocation would be used (and Noel usually is correct)
then it may be that an assignment out of the 0::/3 address space (which is
out of the ordinary allocation space for which the guidelines apply)
sounds like it might be the right thing to do - perhaps something like
10f0::/12 (or something near there not currently allocated).

kre

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Nov 2012 14:11:35 -0800

> requirements of a broad base of deployment of LISP in the Internet's

I think this is a reasonable suggestion. I do believe the size of the prefix is less important than having a semantic associated with the prefix.

> We do not support the publication of this draft as an Informational RFC.

Thanks guys.

Dino

---

From: Geoff Huston <[email-masked]>
Date: Thu, 22 Nov 2012 16:50:40 +1100

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 directions to the IANA in 
RFC4773, yet the document's directions to the IANA appear to me to be inconsistent
with those existing procedures and policies.

To claim, if I understand your line of argument correctly, that every 
RFC essentially is an implicit update of all existing RFCs, and every 
RFC does not need to explicitly obsolete or update any other RFC, as 
it does does so by default upon publication of the RFC is not a line
of argument that I find that I could agree with.

For me, it's like proclaiming that: "everything I do is right, and if 
whatever I do contravenes existing processes and procedures then my
actions implicitly update those processes and procedures such that
everything I do is right" I find that I cannot agree with such a 
circular self-referential line of reasoning.

Instead, I believe that the processes and processes that the IETF follow are
deliberative decisions, and that we update and amend those processes and
procedures explicitly, and documents that perform such updates say so
explicitly, and are accepted and published on the basis of explicit
consideration of the processes and procedures and acceptance of the
amendment.

But I appreciate that I am by training a mathematician and not a lawyer,
and you may indeed be making some critical observations about the nature
of the IETF's processes and procedures whose finer points may well have
escaped me. However, it seems to me that it would be more productive
for the IETF to consider that this issue is a distinct issue, and not
confound the consideration of the IETF Last Call of this particular
eid draft with the broader issue of the manner  by which the IETF crafts 
and maintains its own procedures, processes and policies.

regards,

  Geoff

  speaking for myself and noone else

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Nov 2012 22:25:32 +0700

Date:        Thu, 22 Nov 2012 16:50:40 +1100
    From:        Geoff Huston <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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"

That's not what I said - what I said was that relying upon an RFC as
disqualifying a new one was bogus - that's never going to be possible,
nor should it be.   Referencing existing RFCs is of course just fine.

  | This eid draft does not claim to obsolete or update either the description
  | of roles and responsibilities in RFC2860 or the directions to the IANA in 
  | RFC4773,

My guess would be that is because it doesn't intend to do either of
those things (still just a guess, I am not arguing the merits or
correctness of that particular draft).   It is entirely reasonable
to leave existing procedures in place, but override them for a specific
case.   If RFC's had an "Ignores" header, then perhaps this one should
say "Ignores: RFC2860 RFC773" (or perhaps Overrides), but there are
no such headers.

  | yet the document's directions to the IANA appear to me to be inconsistent
  | with those existing procedures and policies.

Yes, that is why it is an RFC, and why it should need IETF consensus to
proceed.   If they were just to follow the existing guidelines, they'd
just get address space the normal way.  Clearly the proponents of this
draft don't believe that is adequate, or they wouldn't have gone to all
the trouble of writing a draft and attempting to publish it as an RFC.

Before someone else raises it, one issue might be that this is apparently
just intended as an Informational RFC, yet the others are BCP or PS or
something.  That's kind of unfortunate, but indicates something of a lack
of categories for RFCs - this is clearly not a BCP (its purpose isn't to
sent any policy, or describe how things should be done, aside from for
this one specific case), nor can it be on standards track (it isn't capable
of multiple independent implementations), Informational is all that is
plausible.  Ideally we'd have a separate cagegory so we can divide the
Info docs that are "This is FYI" (that is agreed useful enough to pubish),
from "this is the IETF's consensus about ..."

That is, for this, Info is correct (as things stand) and that doesn't
have any effect upon my opinions.

  | To claim, if I understand your line of argument correctly, that every 
  | RFC essentially is an implicit update of all existing RFCs,

Of course they are, or at least the ones published as the result of
IETF consensus are.  Each of them adjusts the overall view of the
state of the world, and how things are, or should be done, in some
particular area, and necessarily have some impact on all kinds of
previous specifications.   Where there's a major change, we note that
in order to make it easier to keep track of what's happening, but
whether that happens or not, clearly anything we agree is the right
thing to do is an update.

  | For me, it's like proclaiming that: "everything I do is right, and if 
  | whatever I do contravenes existing processes and procedures then my
  | actions implicitly update those processes and procedures such that
  | everything I do is right" I find that I cannot agree with such a 
  | circular self-referential line of reasoning.

There's nothing circular about it.  We could adopt all kinds of bureaucratic
rules, requiring us to explicitly agree to vary the rules of procedure,
before doing anything that is different than has been done before - but
there's really no point.  If we (the community as a whole) have agreed
that X is the right thing to do, then we will do whatever is necessary to be
done to make X happen (since that is what we want the result to be).
Insisting on lots of meaningless make-work just to get to the result that
will happen anyway is pointless, we all have better things to do.

  | But I appreciate that I am by training a mathematician and not a lawyer,

If you attempt to apply rules of mathematics to this kind of process you
are certainly doomed - the two are nothing at all alike.

Just consider if we did have some rule where earlier RFCs (BCPs or
whatever) must always be followed - and then imagine that at some
point we decided that we're happy with the rules as we have them, and
include in a BCP a rule that says that none of this particular set
of RFCs (including itself) may ever be updated or obsoleted.

How would progress ever be made in the future given that combination
of events?   In mathematics it doesn't matter, what is true is true, and
undisputable once proved.  In other fields, circumstances change, and
what was correct yesterday is incorrect today.

There's a simple way out, which is one of the basic tenets of any
organisation like this - and that is that we cannot bind future
instances of ourselves.   Anything we agree to do, following the
correct procedure to get that agreement (which itself can be altered
if that is so agreed), is always correct, and overrides anything
inconistent that existed earlier (to the extent necessary to give
effect to the new agreement).

  | However, it seems to me that it would be more productive
  | for the IETF to consider that this issue is a distinct issue,

I doubt it needs consideration at all, I doubt it is even really the
kind of thing that can be considered - even if we were to explicitly
say that existing rules apply and can't be overridden, that would be
meaningless.   Attempting to believe that we know better than future
generations is one of the best ways to make a mess - they will just
ignore us anyway.

  | and not confound the consideration of the IETF Last Call of this particular
  | eid draft with the broader issue of the manner  by which the IETF crafts 
  | and maintains its own procedures, processes and policies.

That's fine, and in that case, the IESG should ignore your earlier message
as having almost no relevant content.   And of course, my messages have
(beyond this point) no relevance to the consideration of the draft at all.

If you wanted (and if it is appropriate) you could reasonably request that
the authors of the draft explain why the existing procedures are inadequate,
and that the draft should be updated to include that explanation, and
(or course provided that the pposition is correct, and generally accepted)
that would be a push back on publishing this (and assigning the addr block).

Or (or perhaps later) you could argue that the authors reasons aren't
good ones, and that the existing procedures are adequate.

Or you could explain why the whole experiment is useless and a waste
of time, and that allocating address space to it would be senseless.

Or ...

Just not that "we have rules, this ignores them, so dump it" - that
line of argument is bogus.

kre

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 Nov 2012 08:30:36 -0500

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:
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 28 Nov 2012 09:30:23 +0100

+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 <[email-masked]> wrote:

> 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
>