Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
+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 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 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 ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to i...@ietf.org 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. 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. ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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 ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to i...@ietf.org 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. 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. ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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? 2000::/3 for our current model of Internet with our current style of allocation/assignment of address space to ISP/end users ::/3 for future modells, LISP/EID, ILNP and others? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 IPv6 block than 2000::/3 for the two above mention usage? 2000::/3 for our current model of Internet with our current style of allocation/assignment of address space to ISP/end users ::/3 for future modells, LISP/EID, ILNP and others? I've been relatively relaxed for many years about allocation policy in 2000::/3, precisely because that leaves most of the total address space free in case we turn 2000::/3 into a swamp. 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. Brian
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational 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 stay relatively permanent to a device that sources packets from this address. The address has no dependency on the topology the device connects to, the number of interfaces the device has connected to the network, or even if the device is connected at all to the network. So this proposal doesn't have to be associated with LISP or any other mechanism being used. This block could be used today as simply a PI block if no new mechanism is deployed. And if a sub-block of this prefix is used for LISP purposes, then so be it. And I don't think we have to jump in with 2 feet and allocate a very coarse prefix for this. Dino
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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]. 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. Yes. 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. 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. 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 was clear in your minds): It is noted that the LISP experiment already makes use of a /32 prefix ... If the LISP experiment fills this /32 prefix to such a level of utilisation ... 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? 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 in the code in various places; something like: if ((dest EIDSPACEMASK) == EIDSPACEALLOCATION) process_one_way(); else process_another_way(); That being the case, the last thing one would want is either i) changing the block that is handled specially, or ii) having a number of smaller blocks, allocated over time, as either one would require much more complex code to handle: you'd have to have some sort of config file, which could hold multiple blocks, code to read it, the code to process packets (above) would have to be able to handle multiple blocks, yadda-yadda. (Changing the block is the same as having multiple blocks, because past a certain point you're too big for a flag day, which would be the only way to avoid having multiple blocks in use at the same time.) It's that that's driving the suggested reservation, and the smaller actual allocation: the code would handle any address inside the _reservation_ with the special processing, but the bulk of the space would be left _unallocated_, for future allocation in some yet-to-be-determined process (one which would presumably be set up by the existing namespace allocation entities), while a small chunk would be allocated to the experiment, for now. I suspect (I haven't communicated with them directly) that the people who are involved with this scheme don't really care _who_ allocates the space, and how - all they care about is that it's all in one chunk - for the reason laid out above. Noel
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Noel Chiappa Sent: Wednesday, November 21, 2012 8:49 AM To: ietf@ietf.org; l...@ietf.org Cc: j...@mercury.lcs.mit.edu; jcur...@arin.net; pwil...@apnic.net; i...@ietf.org Subject: Re: [lisp] Last Call: draft-ietf-lisp-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 in the code in various places; something like: if ((dest EIDSPACEMASK) == EIDSPACEALLOCATION) process_one_way(); else process_another_way(); That being the case, the last thing one would want is either i) changing the block that is handled specially, or ii) having a number of smaller blocks, allocated over time, as either one would require much more complex code to handle: you'd have to have some sort of config file, which could hold multiple blocks, code to read it, the code to process packets (above) would have to be able to handle multiple blocks, yadda-yadda. (Changing the block is the same as having multiple blocks, because past a certain point you're too big for a flag day, which would be the only way to avoid having multiple blocks in use at the same time.) [WEG] Then the draft needs to say some variant of the above - why it can't migrate, why a flag day won't work, and why it needs that size block right now for an experimental technology, including some justification about the size of the block. If the allocation justification is not going to be done within the RIR community, then it needs to be done here. Noel, you specifically complained about IETF not allowing experiments to proceed while some details are still a little hand-wavey [1], but you seem to want it both ways. If this is to be permanent space, then permanent justification and level of detail is required. If it's to be an experiment, then it should expect that there will be at least one renumber as it transitions from experiment to production. I don't think that expecting code to handle two blocks (the experimental one and the permanent one) is asking too much, nor is it expecting too much to require a line in the sand to ensure that the transition between experiment and production happens before you're too big for a flag day. If a single permanent allocation that never changes is truly necessary, putting a sunset date on the allocation from IANA seems a reasonable solution to me, but no one really responded to that in my last mail [2]. If the experiment is wildly successful and leads to a permanent deployment, then the currently experimental RFCs get updates written to elevate them to proposed standard, and while we're at it, we remove the sunset date from the IANA allocation. If the experiment ends up being a science project and doesn't gain wide deployment, this reclaims the space to prevent it from being another Class E space that is essentially stranded by an allocation that is no longer used. I suspect (I haven't communicated with them directly) that the people who are involved with this scheme don't really care _who_ allocates the space, and how - all they care about is that it's all in one chunk - for the reason laid out above. [WEG] and the people who are involved in number allocation have clearly told the people involved in this scheme that they do care who allocates the space and how, especially if the experiment has no bounded end. I think a compromise is doable, but saying it's not important right now probably isn't going to make the problem go away. Thanks, Wes George [1] http://www.ietf.org/mail-archive/web/ietf/current/msg75920.html [2] http://www.ietf.org/mail-archive/web/ietf/current/msg75919.html 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.
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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_ for this use. Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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_ for this use. But if I understand correctly it's going to be hard-coded somewhere. That will mean that everything that is reserved now will be unusable for anything else ever. I'm not *that* worried about wasting IPv6 addresses, but I do worry about any hard-coding of prefixes. What for example if LISP is such a success that the block is too small? Wouldn't it be better to have a bootstrap method that is more flexible? The DDT root servers know which prefixes are delegated, so we might extend the DDT protocol to return that list of prefixes. I write code myself, so I know it's a lot more work to implement something like that properly. I'm worried about the consequences of making this hard-coded though. We can't foresee all the possibilities at this point in time (if ever). Another benefit of making this flexible is that multiple models of LISP deployment can be used. It doesn't matter anymore if IANA reserves a special block, RIRs assign from separate blocks, or even if ISPs offer LISP based solutions to their customers (which happens to be what I am doing). You get all that, but yes: it does make the code more complex. On the other hand: LISP implementations know how to talk to DDT servers and probably also have prefix-list-matching code already, so it shouldn't be too difficult to get a list of prefixes and match against it. - Sander
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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_ for this use. [WEG] You're hairsplitting on semantics in a way that is mostly unhelpful to the discussion at hand. Reserving the block for LISP means that it cannot be used for anything else. Whether that's an IANA reservation or an RIR allocation is really immaterial to the point I was making, which is that if you truly believe we have to identify a block once and for all for LISP that is the correct size to be used permanently and indefinitely, you need a better justification than you've given, and using experimental as a justification for not having the details worked out isn't going to be acceptable. Regards, 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.
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 no details in the document of how the allocation would work) was about _how_ the space was to be handed out - to which the allocation/reservation distinction _is_ important. Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 necessary Allocation != reservation. Nobody is asking for the entire chunk to be _allocated_ (i.e. given out), just that it be _reserved_ for this use. [WEG] You're hairsplitting on semantics in a way that is mostly unhelpful to the discussion at hand. Reserving the block for LISP means that it cannot be used for anything else. Whether that's an IANA reservation or an RIR allocation is really immaterial to the point I was making, which is that if you truly believe we have to identify a block once and for all for LISP that is the correct size to be used permanently and indefinitely, you need a better justification than you've given, and using experimental as a justification for not having the details worked out isn't going to be acceptable. Regards, 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. ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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. 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. regards, John Curran, Paul Wilson, and Geoff Huston Thanks guys. Dino
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 On 22/11/2012, at 6:09 AM, Robert Elz k...@munnari.oz.au wrote: 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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, 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 g...@apnic.net An: Joel Halpern Direct jmh.dir...@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 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 jmh.dir...@joelhalpern.com 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, 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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' sounds a bit tautological, no? That is LISP twist, it transfers cost from a few cores to many edges. If you define 'many' is 'people who are actually trying to communicate with a given site', yes. 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? (When I first quickly read your message, I thought you were making a point about the routing overhead of EIDs being carried in the global routing tables for use by legacy sites, which is an interesting point, but not the one that you make here.) Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. Thanks for the offer. Dino Regards, as On 16/11/2012 08:18, Sander Steffann wrote: 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 tables. 'this results in significant reduction in core table sizes for everyone who has core tables' sounds a bit tautological, no? No. Most networks dont carry full bgp routes. Most networks is an odd definition. So, I will say my network does not carry full bgp routes. That is LISP twist, it transfers cost from a few cores to many edges. If you define 'many' is 'people who are actually trying to communicate with a given site', yes. 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 am not a LISP expert (ILNP sounds better to me, but we are already way OT), LISP has never passed my smell test. But the only thing I have gleaned of it is that dfz caps in size while edge sites have to buy more routers with newer functions. Which sounds good for tier 1 operators who are on the hook for dfz scaling and for router vendors who are on the hook for selling more routers. There might even be something in it for folks who who are nostalgic for ATM SVCs. There are a lot of ways to shrink the dfz. LISP, imho, is unlikely to succeed due to the economic incentives not being aligned. It requires action at edge sites for problems edge sites don't have (dfz scaling). CB (When I first quickly read your message, I thought you were making a point about the routing overhead of EIDs being carried in the global routing tables for use by legacy sites, which is an interesting point, but not the one that you make here.) Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 an answer to this question (which is not at all LISP-specific - rather, it's a general observation about the allocation of overhead costs in a network). Why should site B, which _never_ talks to X, have to pay, so that site A can talk to X? edge sites have to buy more routers with newer functions. Each vendor will have its own answer to this question, but the LISP software suites I know of are new loads for existing router hardware. Do you know of a LISP package which only comes with new hardware? Noel
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 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 jmh.dir...@joelhalpern.com 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, 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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. 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). 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. 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 On 16/11/2012 08:18, Sander Steffann wrote: 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the 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... :-) -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. [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.
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 already underway). So it's not really a topic that can be covered in this ID. Adding to the complexity is that if LISP becomes widely deployed, how the routing works will likely change over time; in the early stages, when there are small islands of LISP, it'll be one thing; later on, when there are islands of legacy stuff, it'll be totally different. Etc, etc. Address these thing somehow in the document, even just mention that it's subject for other document and I'm happy... :-) The IETF used to have this concept of 'rough consensus and _running code_'; i.e. we tried stuff out to see if it works. When did we change into an organization that had to have every 'i' dotted, and every 't' crossed, before we could move an inch? (Saying 'just refer to the document where it is covered' doesn't help, if the other document isn't written yet.) All this ID is trying to do is allocate a rather modest chunk (~ one quarter of one tenth of one percent - .025% - if I've done the math right) of address space for an experiment; exactly how it will be best used, and what the best allocation process is, is to some degree part of that experiment. Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 On 11/16/2012 6:57 AM, Roger Jørgensen 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' 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 ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the 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... :-)
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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. 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. 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? Registries will track allocations to end sites. 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. 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 ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. I agree the wording in the abstract and introduction should be a bit stronger and/or more direct. 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. Sure, good comment. Dino Regards as On 15/11/2012 16:25, Dino Farinacci wrote: 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 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. 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. 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. 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? Registries will track allocations to end sites. 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. 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 ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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.
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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. Right. 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, Why not? which will make a mess of the global IPv6 routing table... And why do you think you need to assign PITRs per sub-block? Dino Thanks, Sander
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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.
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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... That is why I capitalized COULD. 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. Right. 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, 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... You have all the PITRs in the world advertise only the one /12 into underlying routing. 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 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. 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. ;-) 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 Dino
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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... 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 No, I don't think so. You just avoided doing LISP to the destination site that wants multi-homing. 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 can configure a device to be more restrictive. And this would be the case in the non-capital I internet. 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... 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 I'm sorry, it can work and people will WANT to do this. Infrastructure providers do want to attract traffic. a) they would have to pay all the bandwidth cost for users of that EID space that they have no business relation with 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). 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. c) See all the arguments about why 6to4 is unreliable. They'll apply here too Then you deploy an ITR at your site. You will want to for other reasons, so you kill the problem you think you have. 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 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? 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. 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 Don't change the context of this discussion. We are talking PITRs. PETRs are something completely different. 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. Dino
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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). Okay. 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. No, I am not making any assumptions either way. How allocation gets done is subject to more work. 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). 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. 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. What Joel said. 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. 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. I don't understand why you think they look different or need to be treated differently. So you have to do the explaining. ;-) 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. 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? Dino cheers -George
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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?
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 On 11/16/2012 11:35 AM, Brian E Carpenter wrote: 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 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 fails, this is a small cost to find out. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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 Yours, Joel On 11/16/2012 11:35 AM, Brian E Carpenter wrote: 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 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. 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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 On 11/16/2012 11:35 AM, Brian E Carpenter wrote: 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 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. 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 ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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' 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 ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to i...@ietf.org 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? 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 -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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 l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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 cheers -George
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
Hi, no central registry has been ever discussed, was more about delegated the space to LISP ISPs. Glad to hear that! Sander
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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 paying for a block that can be used for either purpose? Paul
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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? 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 paying for a block that can be used for either purpose? Good point. I am currently using my whole /32 allocation from RIPE NCC as EID space. I run multiple PxTRs in an BGP based anycast setup to route to/from the non-LISP internet. What would be the use of requesting another prefix? I would have to put it in the global routing table to route traffic for it (unless other people start running PITRs for the whole /12, but then we get the 3rd party relay dependencies we know so well from 6to4...) (PS: my PxTRs do map-requests for anything in ::/0 using DDT, so everything in DDT is already sent to a locator if possible, and they forward traffic natively otherwise) Met vriendelijke groet, Sander Steffann
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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. 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 Luigi - Sander ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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: 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 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. 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. 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. 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? Registries will track allocations to end sites. 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. 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 ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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... 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. Right. 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, 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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... 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? 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... 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 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 On 11/15/2012 5:24 PM, George Michaelson wrote: 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 ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 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 can configure a device to be more restrictive. And this would be the case in the non-capital I internet. Ok 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... 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 I'm sorry, it can work and people will WANT to do this. Infrastructure providers do want to attract traffic. a) they would have to pay all the bandwidth cost for users of that EID space that they have no business relation with 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. 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 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. c) See all the arguments about why 6to4 is unreliable. They'll apply here too Then you deploy an ITR at your site. You will want to for other reasons, so you kill the problem you think you have. 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 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? 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. 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 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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: 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 On 11/15/2012 5:24 PM, George Michaelson wrote: 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
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
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 decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to i...@ietf.org 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 rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
