Weekly posting summary for ietf@ietf.org
Total of 148 messages in the last 7 days. script run at: Fri Nov 16 00:53:02 EST 2012 Messages | Bytes| Who +--++--+ 6.76% | 10 | 5.99% |68144 | san...@steffann.nl 6.08% |9 | 5.97% |67932 | arturo.ser...@gmail.com 5.41% |8 | 4.72% |53729 | melinda.sh...@gmail.com 4.73% |7 | 4.75% |54068 | s...@resistor.net 4.73% |7 | 4.44% |50498 | aser...@lacnic.net 4.73% |7 | 4.32% |49148 | d...@dcrocker.net 4.73% |7 | 4.21% |47897 | carlosm3...@gmail.com 0.68% |1 | 7.67% |87301 | f...@cisco.com 3.38% |5 | 3.88% |44170 | brian.e.carpen...@gmail.com 4.05% |6 | 3.05% |34682 | jo...@taugh.com 3.38% |5 | 3.13% |35659 | g...@gigix.net 2.70% |4 | 3.45% |39268 | daedu...@btconnect.com 2.70% |4 | 2.93% |33343 | abdussalambar...@gmail.com 2.03% |3 | 2.19% |24972 | y...@checkpoint.com 2.03% |3 | 2.02% |22964 | b...@nostrum.com 2.03% |3 | 1.92% |21896 | joe...@bogus.com 2.03% |3 | 1.85% |21067 | c...@tzi.org 2.03% |3 | 1.83% |20850 | tglas...@earthlink.net 2.03% |3 | 1.68% |19071 | berti...@bwijnen.net 1.35% |2 | 1.68% |19087 | framefri...@gmail.com 1.35% |2 | 1.68% |19083 | wesley.geo...@twcable.com 1.35% |2 | 1.22% |13919 | ggm+i...@apnic.net 1.35% |2 | 1.21% |13808 | vinay...@gmail.com 1.35% |2 | 1.14% |13021 | wor...@ariadne.com 1.35% |2 | 1.13% |12811 | bob.hin...@gmail.com 1.35% |2 | 1.04% |11795 | a...@anvilwalrusden.com 1.35% |2 | 1.02% |11623 | adr...@olddog.co.uk 1.35% |2 | 1.01% |11479 | swm...@swm.pp.se 1.35% |2 | 0.97% |11069 | n...@inex.ie 1.35% |2 | 0.96% |10973 | stephen.farr...@cs.tcd.ie 1.35% |2 | 0.88% |10021 | ra...@psg.com 0.68% |1 | 1.00% |11430 | s...@internet2.edu 0.68% |1 | 0.90% |10225 | nar...@us.ibm.com 0.68% |1 | 0.83% | 9502 | j...@joelhalpern.com 0.68% |1 | 0.75% | 8559 | hsan...@isdg.net 0.68% |1 | 0.74% | 8480 | ted.i...@gmail.com 0.68% |1 | 0.72% | 8251 | mary.ietf.bar...@gmail.com 0.68% |1 | 0.70% | 7989 | i...@ietf.org 0.68% |1 | 0.70% | 7931 | t...@att.com 0.68% |1 | 0.66% | 7466 | gmail.sant9...@winserver.com 0.68% |1 | 0.65% | 7440 | spen...@wonderhamster.org 0.68% |1 | 0.65% | 7413 | petit...@acm.org 0.68% |1 | 0.60% | 6874 | d3e...@gmail.com 0.68% |1 | 0.59% | 6754 | randy_pres...@mindspring.com 0.68% |1 | 0.58% | 6598 | mcr+i...@sandelman.ca 0.68% |1 | 0.55% | 6307 | rog...@gmail.com 0.68% |1 | 0.54% | 6183 | azurem...@gmail.com 0.68% |1 | 0.53% | 6013 | d...@xpasc.com 0.68% |1 | 0.52% | 5943 | p...@frobbit.se 0.68% |1 | 0.51% | 5856 | l...@cisco.com 0.68% |1 | 0.51% | 5830 | g...@apnic.net 0.68% |1 | 0.50% | 5725 | r...@gsp.org 0.68% |1 | 0.50% | 5673 | hartmans-i...@mit.edu 0.68% |1 | 0.50% | 5646 | pvi...@vinciconsulting.com 0.68% |1 | 0.47% | 5317 | dcroc...@bbiw.net 0.68% |1 | 0.44% | 4960 | bortzme...@nic.fr 0.68% |1 | 0.41% | 4661 | i...@meetecho.com +--++--+ 100.00% | 148 |100.00% | 1138374 | Total
Re: Newcomers [Was: Evolutionizing the IETF]
> Shall we move on? Sure. Since we agree that there is no way to pay for the extra costs involved in meeting in places where there are insignificant numbers of IETF participants, it won't happen, and we're done. That was simple, wasn't it?
Re: Newcomers [Was: Evolutionizing the IETF]
On 15/11/2012 21:01, John R Levine wrote: >> Comparing with the ITU who does tour the world, organizing workshops in >> far away places, I really think we should be trying a little harder to >> be more open. > > The IAOC has often noted that holding meetings in more exotic places is > considerably more expensive, the hotels and other services just charge > more. > > Keeping in mind that the IETF is paid for by a combination of conference > fees and an annual grant from ISOC, not governments, who were you > expecting to pay the increased costs? > > Also, why do you believe that people people need to go to meetings in > person rather than joining the mailing lists where the bulk of the > IETF's work gets done? > That has been answered: http://www.ietf.org/mail-archive/web/ietf/current/msg75890.html Shall we move on? > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. Regards, as
Re: Newcomers [Was: Evolutionizing the IETF]
Comparing with the ITU who does tour the world, organizing workshops in far away places, I really think we should be trying a little harder to be more open. The IAOC has often noted that holding meetings in more exotic places is considerably more expensive, the hotels and other services just charge more. Keeping in mind that the IETF is paid for by a combination of conference fees and an annual grant from ISOC, not governments, who were you expecting to pay the increased costs? Also, why do you believe that people people need to go to meetings in person rather than joining the mailing lists where the bulk of the IETF's work gets done? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
Re: [lisp] Last Call: (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. W
Re: [lisp] Last Call: (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
Re: [lisp] Last Call: (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: (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: Newcomers [Was: Evolutionizing the IETF]
Hi, On 11/15/2012 5:19 PM, Dave Crocker wrote: > > On 11/15/2012 9:43 AM, Carlos M. Martinez wrote: >> Comparing with the ITU who does tour the world, organizing workshops in >> far away places, I really think we should be trying a little harder to >> be more open. > > > It's important to distinguish between a 'workshop' and a 'working > meeting' where decisions are made. > > As I understand the ITU's operation, all of the ITU-T formal decisions > are made in Geneva. Any meetings held before that and seeming to make > decisions can be reversed during a Geneva session, in my direct > experience. > > Also, ISOC actually seems to do a pretty good job of showing up in > many places around the world, on the IETF's behalf, including events > that can be called workshops. > I agree, but I´m talking about perceptions and how these things can be manipulated against us. If we don´t care, that´s fine, but we shouldn´t be surprised afterwards if something we do not like comes out of WCIT. > d/
Re: Newcomers [Was: Evolutionizing the IETF]
They are doing a great job, but I wouldn't said that all of that is on IETF behalf. They are there because that is ISOC's mission, not to represent us in the majority of their work. If we want representation, we need to do it ourselves. ISOC would support us, I am sure, but we need to at least show up. Regards as On 15/11/2012 17:19, Dave Crocker wrote: > > Also, ISOC actually seems to do a pretty good job of showing up in many > places around the world, on the IETF's behalf, including events that can > be called workshops.
Re: [lisp] Last Call: (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: (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: (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: (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: Newcomers [Was: Evolutionizing the IETF]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/15/2012 11:59 AM, Tony Hansen wrote: > On 11/15/2012 4:45 AM, t.p. wrote: >> I started, some years ago, with a meeting, because the culture that I was >> used to was that conferences, be they annual or triannual, were where >> things really happened and that e-mail filled in the gaps in between (and >> I think that this remains the case in other, related, fora). That >> attendance showed me that most of the IETF meeting was a waste of time, >> that it was e-mail that was the main vehicle for work, and I think that >> the IETF web site has it about right when it says >> >> "People interested in particular technical issues join the mailing list >> of a WG and occasionally attend one or more of the three IETF meetings >> held every year." and "After participating by email for a while, it may >> be time to attend your first meeting." >> >> which is not exactly sellling the idea of attending meetings:-) But as I >> say, I think that that is the nature of the IETF. > > I've always felt that: between the meetings, four months worth of work > gets done, and then during the meeting, another four months worth of work > gets done. > > I've found this to be true over and over. My experience is that during the meeting, 2 hours of work gets done (per WG), and then between the meetings, another 2 hours of work gets done. - -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQpVHPAAoJECnERZXWan7EJn0QAIZuJ2PX3d0U1EWtKoxDlz3k Y0eShE+G4rMa82xBJ4RHdNnyNymXdebcvQlFeH6ecep8nm1++r9KQ8kWeo/FEPRN eK+q8jEMABy4IVSTIgOjMJcA4834FdCnW+oFaP8t8J0ufCMenoKkRfz2pDx6VFOh 7mHmfU4lfFuYNVbVRHinkSZqtklGwLwrIaJ/zpjQX5dTJRpMeakeSRKiurSzIK9u Nd2P8TY5V2M332g5TreEZAQh2+bS1Wuhvx4FV69SnpPGMpFqsMzcbRVyQfkFuMJ7 +Ol4evJL5DNfPNZSX7EENvyxK+lXNkok2vA4TEa3eQvb5c2PfEYx4xE39l3Jj9+H XBw4swRLIfWKyJ50E8w9alEJYa4tAL2eCSZuMpSXNp37XbGPZ2glpWQUNZXFRhgY oXjzflI84rzGPCNzGyg70JEYz3GJ5SS9K5kF4dqmVu1+OS9vfJKNSkce0IhNbc+I Tl+fK6LEXnzCresRwnOP28Mw9QzbHih7nC+d2iQHUI5jq2II254VBddrEaHRfSFm tCtNWIgDXDxuB5losK91+9IkU0IbUOZXmOpb5vqlXJujEbcxgnceb5+5zhsD/6Mp pSTwyzs8Bz7xUrli2UTsQSEbT4DC8bPon7uy4dyzCe+x2Z/D+4BJVHAtMI/TVdfY N8qSqkqp2PrCXLgr2qU2 =/ibP -END PGP SIGNATURE-
Re: [lisp] Last Call: (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: Newcomers [Was: Evolutionizing the IETF]
On 11/15/2012 4:45 AM, t.p. wrote: I started, some years ago, with a meeting, because the culture that I was used to was that conferences, be they annual or triannual, were where things really happened and that e-mail filled in the gaps in between (and I think that this remains the case in other, related, fora). That attendance showed me that most of the IETF meeting was a waste of time, that it was e-mail that was the main vehicle for work, and I think that the IETF web site has it about right when it says "People interested in particular technical issues join the mailing list of a WG and occasionally attend one or more of the three IETF meetings held every year." and "After participating by email for a while, it may be time to attend your first meeting." which is not exactly sellling the idea of attending meetings:-) But as I say, I think that that is the nature of the IETF. I've always felt that: between the meetings, four months worth of work gets done, and then during the meeting, another four months worth of work gets done. I've found this to be true over and over. Tony Hansen
Re: [lisp] Last Call: (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: Newcomers [Was: Evolutionizing the IETF]
On 11/15/2012 9:43 AM, Carlos M. Martinez wrote: Comparing with the ITU who does tour the world, organizing workshops in far away places, I really think we should be trying a little harder to be more open. It's important to distinguish between a 'workshop' and a 'working meeting' where decisions are made. As I understand the ITU's operation, all of the ITU-T formal decisions are made in Geneva. Any meetings held before that and seeming to make decisions can be reversed during a Geneva session, in my direct experience. Also, ISOC actually seems to do a pretty good job of showing up in many places around the world, on the IETF's behalf, including events that can be called workshops. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Newcomers [Was: Evolutionizing the IETF]
Note that I didn't say 'give back in terms of attendees' , I wrote 'give back in terms of participation', in my mind, participation *can* be remote, although as I mentioned in an earlier email the IETF needs to improve remote access facilities a lot. However, the perception of almost everyone I've spoken with is that if you really want to push a document (not being a reviewer, not being a 3rd or 4th co-author), you need to be there in person. I'm sure I will be pointed to exceptions to this rule, but that seems to be the general perception. regards, Carlos On 11/15/12 4:00 PM, Melinda Shore wrote: > On 11/15/12 8:47 AM, Carlos M. Martinez wrote: >> I do believe that regions wanting to have an IETF meeting should also >> give back in terms of active participation, I agree with that. > > I really think there's an enormous disconnect here. I'm really unclear > on how this is supposed to work: if someone thinks they need to attend > a meeting in order to participate in the work and there's only one > meeting in their region in some large number of years, it's difficult > to see how that one meeting is going to lead to active participation. > Arguing that IETF openness is a function of meeting location is > totally missing the point. Clearly we could be making that point > better, but it seems to me that privileging meetings as a more > important part of the process of producing documents very clearly works > against an open participation model. > > The main benefit, it seems to me, is not geographic but that we > are woefully short on participation by operators and that many of the > folk in developing or less affluent countries work for operators, > registrars, regulators, etc., and we may benefit from one-off > participation from them. > > Melinda >
Re: [lisp] Last Call: (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 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: (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 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: Newcomers [Was: Evolutionizing the IETF]
On 11/15/12 8:47 AM, Carlos M. Martinez wrote: > I do believe that regions wanting to have an IETF meeting should also > give back in terms of active participation, I agree with that. I really think there's an enormous disconnect here. I'm really unclear on how this is supposed to work: if someone thinks they need to attend a meeting in order to participate in the work and there's only one meeting in their region in some large number of years, it's difficult to see how that one meeting is going to lead to active participation. Arguing that IETF openness is a function of meeting location is totally missing the point. Clearly we could be making that point better, but it seems to me that privileging meetings as a more important part of the process of producing documents very clearly works against an open participation model. The main benefit, it seems to me, is not geographic but that we are woefully short on participation by operators and that many of the folk in developing or less affluent countries work for operators, registrars, regulators, etc., and we may benefit from one-off participation from them. Melinda
Re: [lisp] Last Call: (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: (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: Newcomers [Was: Evolutionizing the IETF]
Hello, On 11/15/12 6:11 AM, Brian E Carpenter wrote: > On 15/11/2012 03:43, Melinda Shore wrote: > > We'd reached 50 attendees from China at IETF 63 before we even > started seriously negotiating the Beijing meeting. It seems to > me that the causality is mainly in the opposite direction: > participation causes meetings, not meetings cause participation. > Having a metric for considering having a meeting in a give region would be really nice, so we can stop arguing over smoke. If 50 is a magic number, well, we Latin America are not that far, I'm confident we'll be there in a few meetings. I do believe that regions wanting to have an IETF meeting should also give back in terms of active participation, I agree with that. > (IMHO, there is some value to the IETF in having one-off > attendees who don't subsequently participate: they learn what > the IETF is and hopefully tell others about it. This can't be a > bad thing, but it's definitely secondary.) Agreed. > >Brian >
Re: Newcomers [Was: Evolutionizing the IETF]
On 11/15/12 3:15 PM, John R Levine wrote: >> As Arturo says, having people that traditionally go to an IETF meeting >> travel to (for them) far away places and (for them) new cultures, do >> definitely open their eyes to how large our world is. > > I think that learning about other parts of the world is swell, but I > don't think the IETF should be a travel agent. > Comparing with the ITU who does tour the world, organizing workshops in far away places, I really think we should be trying a little harder to be more open. So far this entire thread would provide a nice argument for those proposing more government involvement as clearly the multistakeholder approach is failing the less developed economies. Given that WCIT is starting in a few days, and that every country has one vote in that thing, I think this kind of attitude is not helping us. This is not my personal view, but that is how some may read it: the IETF attendees are a bunch of 'ivory tower' engineers who can't be bothered to fly routes with more than one connection or who firmly believe that the business district in Sao Paulo is more dangerous/menacing than the area around the Atlanta Hilton. I want the IETF and the governance model it represents to succeed, I firmly believe in it. However I'm not that blind and I seriously believe we need to fix some things at home, or we are going to be easy prey for those seeking to control the Internet. regards ~Carlos > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly.
Re: Newcomers [Was: Evolutionizing the IETF]
On Nov 15, 2012, at 17:04, Dave Crocker wrote: > I'm saying that your point lacks an empirical basis Yes. I'm not even arguing that the IETF spend effort on obtaining that empirical basis (hint: there is probably a great PhD thesis in organizational marketing waiting to be written). My hypothesis is mainly based on my perceptions of changes in reception of the IETF in the German corporate technology and research environments right after both Amsterdam (1993) and Munich (1997). I'm well aware that perception of mine may, of course, be all based on confirmation bias. I still strongly believe I have seen the effect. I'm also quite skeptical that this experience will reliably transfer to any other market. I still believe that the potential benefits from repeating the experiment in some of them would be worth a *small* increase in inconvenience for IETF's regular attendees. I trust the IAOC to choose a reasonable value of "small". I probably don't need to point out that we regularly meet in venues that are ridiculously inconvenient to completely inaccessible for a sizable fraction of our regular contributors. I don't think we have very good numbers on this effect, either (I don't think we track citizenship or blacklist name matches). Just to throw another unfounded hypothesis in the air: in the working groups where I'm active, this might block access to 10 to 15 % of the contributors, and it cools down the potential interest of some more. We make a lot of our decisions on bad data like this. > and, worse, that it can hurt the primary requirement for meeting venues. Which, again, is not a useful way to falsify my hypothesis. I don't think that there is any danger to the IAOC's "prime directive" in site selection (convenience for regulars) from bringing a couple of important, but secondary concerns to the table. Grüße, Carsten
Re: Last Call: (LISP EID Block) to Informational RFC
Hi Luigi, At 06:32 15-11-2012, Luigi Iannone wrote: thanks for the comments. Few answers inline. Thanks for the response. Well, if we go along that road we should put the whole document in a single "IANA Considerations" Section. ;-) Yes. :-) Actually the current IANA Considerations section 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. Ok. It refers to the IANA allocation policies. May be it could be changed in the following way: If in the future there will be need for a larger EID Block the address space adjacent the EID Block could be allocate by IANA according to its current allocation policies." Would that work? Not yet. :-) You did not answer my question about which IANA allocation policies the draft is referring to. I agree that this point has been not discussed thoroughly, the idea is not to create any new "manager", rather to make ISPs (or whoever interested in deploying LISP) to request an EID address sub-block as they do with usual prefixes. I'll comment below. Well, this is standard, to have a reserved space we have to go through the (now called) "IETF Review", which is what we are doing ;-) What the draft is doing is reserving address space. According to Section 10 address blocks from that reserved address space (the /16) will be assigned through IETF review. I read the previous comment as meaning that the EID address block will be assigned to ISPs by RIRs. There isn't any mention of that in the draft. Even if it was mentioned it is doubtful that ISPs would be able to get that address space assigned through RIRs at present. The issue was mentioned in the AD review [1]. I didn't find any discussion of that in the LISP mailing list archives. According to the LISP Charter the document is to request "address space to be used for the LISP experiment as identifier space". The draft is reserving a /16 and there is scope to have that extended to a /12 in future. This goes beyond the usual experiments. There isn't any discussion of how the ip6.arpa delegation will be handled. There isn't any discussion of how long the experiment will last. I understand that IPv6 is not a scare resource. However, that is not a reason for handing out address space and leaving it to someone in future to figure out what to do if this becomes a problem. I haven't seen anyone asking why the document is not a BCP. If the aim is to have: "Routers in the Legacy Internet must treat announcements of prefixes from the IPv6 EID Block as normal announcements, applying best current practice for traffic engineering and security." I think that the document might have to be a BCP. It would be good to be clear about whether the address space should be listed in the IANA IPv6 Special Purpose Address Registry. Section 5 mentions that "The working group reached consensus on an initial allocation". Could the document shepherd upload the write-up and provide some details about that? Regards, -sm 1. http://www.ietf.org/mail-archive/web/lisp/current/msg03848.html
Re: Newcomers [Was: Evolutionizing the IETF]
As Arturo says, having people that traditionally go to an IETF meeting travel to (for them) far away places and (for them) new cultures, do definitely open their eyes to how large our world is. I think that learning about other parts of the world is swell, but I don't think the IETF should be a travel agent. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
RE: [lisp] Last Call: (LISP EID Block) to Informational RFC
> On 15 Nov. 2012, at 10:43 , Sander Steffann 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: (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: (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: Newcomers [Was: Evolutionizing the IETF]
Carsten, et al, On 11/14/2012 11:08 PM, Carsten Bormann wrote: My comment was not about getting work done, but about impact of this work. OK. So the choice of venue is supposed to serve two goals: * Being useful for the workers developing IETF documents. * Promoting that work to (potential) consumers of it. The first bullet is the operational one of choosing venues that are convenient and useful for attendees doing the work. It's important to note that it is difficult to service this one requirement. Adding more increases the challenges and risks. Concerning the second bullet an example would be that by showing up in South America, we will get more use of IETF work in South America. Or is the view broader that our showing up in SA, we will get more use elsewhere also? I believe that it is better accomplished by doing work that has more community involvement and more operational relevance. ... If we do that, it won't matter where we hold our meetings. And I was pointing out that this isn't true. It may not matter nearly as much as the quality of the work, but there is an effect. The second bullet is about marketing the IETF brand. Your position is that we will have better use of IETF output if we choose locations to increase awareness, mindshare, and the like. The importance of brand awareness is well established in marketing. The question is how much the particular choice of venue affects IETF brand awareness. In terms of marketing theory, your premise is reasonable. Unfortunately, many marketing theories are reasonable but wrong. So what I do not understand is its empirical basis for the specific case of the IETF. The fact that we have been wandering around the globe for 20 years ought to have provided us with that empirical basis. In addition, we should be able to compare our own history with that of standards groups that do /not/ wander around, or who wander less than we do, and we should see a history of better mindshare and better uptake of work for the IETF. As popular as IETF work is, I don't see that less 'mobile' standards groups are suffering by comparison. Or, at least, not due to their being less mobile. To the extent that one disagrees with my assertion, I'll claim that any differences in mindshare are readily explained by the quality or relevance of the work, not the choice of meeting venue. In other words, I appreciate your firm "this isn't true" but ask you to substantiate it empirically. Otherwise, we are making an expensive, risky, strategic decision based on an unfounded belief. It's a popular belief, I admit, but that doesn't make it valid. Increasing visibility and mindshare, in particular at level 9, can very much help enabling involvement. So the fact that we haven't been showing up in South America or Africa or the Middle East should mean that the IETF's work has less mindshare there and less adoption, especially compared with other standards groups that do go to those regions. Another example of an empirical test could be that that folk from such venues, who have shown up on our many mailing lists, choose not to continue working with the IETF because we don't go to their countries. In other words, I would have that our relevance is determined more by the quality and utility of our work than by the marketing effects of meeting venue. I certainly subscribe to that. Again, finding meeting venues that work well for an IETF venue is quite difficult. When we add other goals, such as marketing the IETF to the community, we make venue selection especially difficult. Again, you are trying to argue against my point by saying your point is more important. That is certainly so, but doesn't make my point wrong or irrelevant. I'm saying that your point lacks an empirical basis and, worse, that it can hurt the primary requirement for meeting venues. There is a very real and cost to your point and only a theoretical benefit. The real cost is that it increases the aggregate /in/convenience to /existing/ IETF workers and it /increases/ the barrier to participation for people from the regions that are already supplying workers. Our current model is to distribute the travel pain. One time, more convenient for North Americans. Another time, more convenient for Eastern Asians. That is, the goal is fairness among current workers. The choice of the 3 regions we vary among has been based on actual participation. We increased the desired proportion of meetings in East Asia as we saw a strong trend of increased participation from that region. This was a /reactive/, not /proactive/, change. (Our failure to maintain the model has been due to logistical problems, not a change in the model.) To the extent that going elsewhere increases the pain, cost, operational risk, or the like for current workers, this theoretical marketing benefit hurts actual work. Showing up in venues th
Re: Last Call: (LISP EID Block) to Informational RFC
Nice to try and keep it short. But I was hoping for some more detail and explanation. I have not followed the discussions (if any) in the WG so I may be missing the reasons why you need this much space. I would hope that the WG (if they have consensus (which may be something different than "the WG felt")) could elaborate or summarize the discussions that lead to the conclusion that this amount of space is needed and makes sense. Pointers to the WG mlist discussions where the pros and cons of various prefixes sizes are discussed or summarize would also be welcome. Bert On 11/15/12 3:46 PM, Luigi Iannone wrote: Hi Bert, On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF) wrote: [snip] So it is not asking just a /16 but also asking for reservation of a /12. Pretty big space. And in the list of reasons, I mainly read that it is "sufficiently large", but not much about why it needs to be this big. Why would a smaller allocation not be sufficient? Well, to keep it short, the WG felt that /16 is the "right size", and that if the growth of LISP would be so important as to need a bigger space would be nice to have it contiguous (so implementations can just change the prefix length). Luigi Bert
Re: Last Call: (LISP EID Block) to Informational RFC
Hi Bert, On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF) wrote: [snip] > > So it is not asking just a /16 but also asking for reservation of a /12. > > Pretty big space. > > And in the list of reasons, I mainly read that it is "sufficiently large", > but not much about why it needs to be this big. Why would a smaller > allocation not be sufficient? > Well, to keep it short, the WG felt that /16 is the "right size", and that if the growth of LISP would be so important as to need a bigger space would be nice to have it contiguous (so implementations can just change the prefix length). Luigi > Bert
Re: [lisp] Last Call: (LISP EID Block) to Informational RFC
Hi George, On 15 Nov. 2012, at 11:50 , George Michaelson 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: (LISP EID Block) to Informational RFC
On 15 Nov. 2012, at 10:43 , Sander Steffann 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: Last Call: (LISP EID Block) to Informational RFC
Hi, thanks for the comments. Few answers inline. On 14 Nov. 2012, at 12:19 , SM wrote: > At 06:45 13-11-2012, The IESG wrote: >> The IESG has received a request from the Locator/ID Separation Protocol >> WG (lisp) to consider the following document: >> - 'LISP EID Block' >> 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 > > The document does not clearly define how the address space will be managed. > This might end up being problematic in future. > > In Section 4: > > "Too guarantee reachability from the Legacy Internet the prefix could" > > There is a typo for "Too". thanks, will fix. > > 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 > > "If in the future there will be need for a larger EID Block the > address space adjacent the EID Block could be allocate by IANA > according to the current policies." > > Which policies does the above refer to? > It refers to the IANA allocation policies. May be it could be changed in the following way: If in the future there will be need for a larger EID Block the address space adjacent the EID Block could be allocate by IANA according to its current allocation policies." Would that work? > In Section 10: > > "This document instructs the IANA to assign a /16 IPv6 prefix for use > as the global LISP EID space using a hierarchical allocation as > outlined in [RFC5226]." > > Who will be the delegated managers? I agree that this point has been not discussed thoroughly, the idea is not to create any new "manager", rather to make ISPs (or whoever interested in deploying LISP) to request an EID address sub-block as they do with usual prefixes. > > "Following the policies outlined in [RFC5226], such space > will be assigned only upon IETF Review." > Well, this is standard, to have a reserved space we have to go through the (now called) "IETF Review", which is what we are doing ;-) ciao Luigi > The previous sentence mentions hierarchical allocation and the above sentence > mentions IETF Review. It is not clear how assignments from this space will > be made. > > Regards, > -sm
Re: [lisp] Last Call: (LISP EID Block) to Informational RFC
Hi Roger, On 14 Nov. 2012, at 10:42 , Roger Jørgensen wrote: > On Tue, Nov 13, 2012 at 3:45 PM, 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' >> 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: [mpls] Last Call: (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
More thoughts inline three times (and apologies for the slow response). - Original Message - From: "Mach Chen" To: "t.p." ; Sent: Wednesday, November 07, 2012 12:24 PM Hi Tom, Many thanks for your comments! Please see my reply inline with [Mach] Best regards, Mach From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] on behalf of t.p. [daedu...@btconnect.com] Sent: Saturday, November 03, 2012 2:05 To: ietf@ietf.org I worry about the allocation of sub-TLVs in this I-D. It calls for "The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for "Target FEC Stack", and TLV Type 21 for "Reply Path"." and it is the Type 21 that worries me. [Mach] Since draft-ietf-mpls-return-path-specified-lsp-ping has already defined the rule and policy on how to inhirent the sub-TLVs from type 1 TLV, IMHO, here it may be no need to explicitly mention how to registry the sub-TLVs for Type 21. So, how about this: "The following Sub-TLV changes, which comprise three updates and two additions, are made for TLV Type 1." I do not see this rule defined in draft-ietf-mpls-return-path-specified, at least, not for any sub-TLVs that may be defined in future for Type 1 TLVs, that is, that I-D covers the present but not the future and that is what I worry about. The ipv6 I-D as initially written did not take account of return-path-specified and vice versa, so I expect this situation to recur and do not see a good solution to it. IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. [Mach] As Loa pointed out, the current IANA registry for Type 21 TLV is not reflecting the proposal in [draft-ietf-mpls-return-path-specified-lsp-ping]. Yes, and my reading is that the removal of temporary allocations is (yet another) duty of the WG chair, so doubtless that will be taken care of:-) I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely " According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated." so quite what this I-D will do to that I-D worries me. [Mach] This is intended for the Type 21 TLV to have a common part code range shared with Type 1 TLV and a TLV specific code range for its own dedicaed sub-TLV. I think we should have an agreement on this solution :-) Yes, we have long had agreement on the general idea of the solution but it is not clear to me that the current wording got that message across, for example to the AD, in which case we need better wording. I realise that this has come up on the MPLS list but I am unsure what the proposed wording now is. In fact, I am unclear whether the change proposed in return-path-specified is intended to apply to all TLVs, present and future - I think that it should, for safety, but the wording is unclear to me on that point Which point is of course nothing to do with the IETF Last Call of ipv6, no need to mention it there, but it seems better to keep it on one thread for the moment. Best regards, Mach And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: "The IESG" To: "IETF-Announce" Cc: Sent: Wednesday, October 24, 2012 9:31 PM > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' >as Proposed Standard > > 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-09. 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 > >Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping >and traceroute mechanisms are commonly used to detect and isolate >data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. >The PW LSP Ping and traceroute elements, however, are not specified >for IPv6 address usage. > >This document extends the PW LSP Ping and traceroute mechanisms so >they can be used with IPv6 PWs, and updates RFC 4379. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp
Re: Last Call: (LISP EID Block) to Informational RFC
On Tue, Nov 13, 2012 at 3:45 PM, 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' >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 at ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be > sent to iesg at 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. Mmm... In section 5 it states: The working group reached consensus on an initial allocation of a /16 prefix out of a /12 block which is asked to remain reserved for future use as EID space. The reason of such consensus is manifold: So it is not asking just a /16 but also asking for reservation of a /12. Pretty big space. And in the list of reasons, I mainly read that it is "sufficiently large", but not much about why it needs to be this big. Why would a smaller allocation not be sufficient? Bert
Re: [lisp] Last Call: (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: Newcomers [Was: Evolutionizing the IETF]
- Original Message - From: "Brian E Carpenter" To: "Melinda Shore" Cc: Sent: Thursday, November 15, 2012 8:11 AM > On 15/11/2012 03:43, Melinda Shore wrote: > ... > > Right, I understand that (better than you might think - I live in > > Alaska). But. I'm trying to understand the value in having people > > attend one meeting. I've asked about that several times. > > There are people who have attended one, or a very small number, > of meetings and who participate actively in IETF work. That's > certainly the case for a few people in Australia and New > Zealand, for example. I have a co-author on a current draft who > attended IETF 83 in Paris, because he happens to live there and > doesn't have business justification for the time and money for > longer trips. I think people in this class do get a lot out of > occasional participation - enough to encourage them to > participate remotely. I've gone through phases of attending one > meeting a year, and that's definitely enough to stay in touch. > > However, that is very different from meetings in unusual places > *attracting* new participants who stay with us. Would we get a > cohort of new active participants if we met in Anchorage? > > We'd reached 50 attendees from China at IETF 63 before we even > started seriously negotiating the Beijing meeting. It seems to > me that the causality is mainly in the opposite direction: > participation causes meetings, not meetings cause participation. I started, some years ago, with a meeting, because the culture that I was used to was that conferences, be they annual or triannual, were where things really happened and that e-mail filled in the gaps in between (and I think that this remains the case in other, related, fora). That attendance showed me that most of the IETF meeting was a waste of time, that it was e-mail that was the main vehicle for work, and I think that the IETF web site has it about right when it says "People interested in particular technical issues join the mailing list of a WG and occasionally attend one or more of the three IETF meetings held every year." and "After participating by email for a while, it may be time to attend your first meeting." which is not exactly sellling the idea of attending meetings:-) But as I say, I think that that is the nature of the IETF. Tom Petch > (IMHO, there is some value to the IETF in having one-off > attendees who don't subsequently participate: they learn what > the IETF is and hopefully tell others about it. This can't be a > bad thing, but it's definitely secondary.) > >Brian > >
Re: Newcomers [Was: Evolutionizing the IETF]
On 15/11/2012 03:43, Melinda Shore wrote: ... > Right, I understand that (better than you might think - I live in > Alaska). But. I'm trying to understand the value in having people > attend one meeting. I've asked about that several times. There are people who have attended one, or a very small number, of meetings and who participate actively in IETF work. That's certainly the case for a few people in Australia and New Zealand, for example. I have a co-author on a current draft who attended IETF 83 in Paris, because he happens to live there and doesn't have business justification for the time and money for longer trips. I think people in this class do get a lot out of occasional participation - enough to encourage them to participate remotely. I've gone through phases of attending one meeting a year, and that's definitely enough to stay in touch. However, that is very different from meetings in unusual places *attracting* new participants who stay with us. Would we get a cohort of new active participants if we met in Anchorage? We'd reached 50 attendees from China at IETF 63 before we even started seriously negotiating the Beijing meeting. It seems to me that the causality is mainly in the opposite direction: participation causes meetings, not meetings cause participation. (IMHO, there is some value to the IETF in having one-off attendees who don't subsequently participate: they learn what the IETF is and hopefully tell others about it. This can't be a bad thing, but it's definitely secondary.) Brian
