Re: [lisp] Last Call: (LISP EID Block) to Informational RFC
Good points Joel. I completely agree. Dino On Nov 16, 2012, at 9:26 AM, "Joel M. Halpern" 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: Newcomers [Was: Evolutionizing the IETF]
Hi Carlos. On Nov 16, 2012, at 3:25 PM, Carlos M. Martinez wrote: > Hello, > > On 11/16/12 1:27 AM, John Levine wrote: >>> 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. >> > > I don't remember when I agreed with that. In fact I believe quite the > opposite holds. If there was a will there would be ways. However, what I > read here is a lot of refusal, denial and roadblocking. There may be ways. But what you are suggesting requires more money. The way the IETF is run now, it's a very frugal organization. Read the budget slides from any meeting, those numbers are small when compared with many of the organizations that participants come from. One of the great aspects of the IETF's openness is that anyone can participate for the cost of an Internet connection (I had my first RFC published before ever attending a meeting), and for a relatively small amount (when compared to other bodies) they can also attend meetings. This makes it possible for small companies and even individual consultants to attend, participate, and even chair working groups. We even have some people who are salaried employees, but for whatever reasons, their companies are not interested in funding them, and they pay their own way. With increased meeting fees and/or travel budget this goes away, and the IETF becomes the domain of large companies and governments. At least the meetings. > I can't speak for other regions, but from ours, there are at least four > organizations which manage significant budgets, have been in the > conference organization business for more than 10 years, and which would > be very interested in having an IETF in Latin America. Then they should propose to host a meeting. I don't think the IAOC would deny them. There is the question or airfare and flight availability, but as long as the meeting is at or near a big enough hub, such as Mexico City, Rio de Janeiro, Buenos Aires, or Sao Paolo, the IETF is not exactly choosy. > Moving the IETF forward will involve reaching out to other peoples, > other regions, and yes, travel farther away once in a while. I also > understand that we need to do our part in terms of fostering and > increasing the contribution of our region. I said this in an earlier > email and I stand by it. Yes, there are people the IETF should reach out to, people who are missing from our meetings and our mailing lists. But I don't think that group is defined geographically. There are segments of our industry that are not represented or not represented enough in the IETF, like web developers and big website operators. We need some of those, regardless of where in the world they live. Yoav
Re: [lisp] Last Call: (LISP EID Block) to Informational RFC
On Nov 16, 2012 9:27 AM, "Joel M. Halpern" 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: (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: (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: (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: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard
According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING state and attempts to contact any possible server. '? Best Regards, Leaf -Original Message- From: Maglione Roberta [mailto:roberta.magli...@telecomitalia.it] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@ietf.org Cc: softwi...@ietf.org; WG Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwi...@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwi...@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' 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-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. ___ Softwires mailing list softwi...@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list softwi...@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto ques
Re: Newcomers [Was: Evolutionizing the IETF]
Sure. Since we agree that there is no way to pay for the extra costs I wouldn't say that we agreed on that. We do not want to look how to pay the extra cost, we are simply not interested. We agree on this. Oh, sorry, I didn't realize this was a purely hypothetical argument. Never mind. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
RE: [lisp] Last Call: (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: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard
Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwi...@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' 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-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. ___ Softwires mailing list softwi...@ietf.org https://www.ietf.org/mailman/listinfo/softwires
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. 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: (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: (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: (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 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: (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: (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: (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 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? 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
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: (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 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. 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? 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. 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: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard
Leaf, In my opinion current text is fine and inline with RFC2131, while the text you are proposing is not completely accurate because it does not clarify "which DHCP Server" has not replied. 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING state and attempts to contact any possible server. ' Sheng, As original author of this text, what do you think? Thanks, Roberta -Original Message- From: Leaf Yeh [mailto:leaf.yeh@gmail.com] Sent: Friday, November 16, 2012 2:58 PM To: Maglione Roberta; ietf@ietf.org Cc: softwi...@ietf.org; dh...@ietf.org Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING state and attempts to contact any possible server. '? Best Regards, Leaf -Original Message- From: Maglione Roberta [mailto:roberta.magli...@telecomitalia.it] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@ietf.org Cc: softwi...@ietf.org; WG Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwi...@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwi...@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' 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-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radiu
Re: [lisp] Last Call: (LISP EID Block) to Informational RFC
> From: > 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: (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: Newcomers [Was: Evolutionizing the IETF]
Hello, On 11/16/12 1:27 AM, John Levine wrote: >> 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. > I don't remember when I agreed with that. In fact I believe quite the opposite holds. If there was a will there would be ways. However, what I read here is a lot of refusal, denial and roadblocking. I can't speak for other regions, but from ours, there are at least four organizations which manage significant budgets, have been in the conference organization business for more than 10 years, and which would be very interested in having an IETF in Latin America. The feeling I kept receiving here is that there is a kernel of IETFers who still believe that IETF is some kind of ivory tower that exists by itself, for itself and is self-sufficient. Big news: this is no longer the case. For bad but, IMO, mostly for good. The IETF is one more component of the complex ecosystem of Internet governance. A critical one, but not the only one. If you reach out to the balcony of the ivory tower, you will see that the IETF has plenty of enemies, but, also plenty of friends and allies. Moving the IETF forward will involve reaching out to other peoples, other regions, and yes, travel farther away once in a while. I also understand that we need to do our part in terms of fostering and increasing the contribution of our region. I said this in an earlier email and I stand by it. Reach out to your friends and allies. We all want the whole multi-stakeholder approach to succeed, we are all on the same boat and we definitely need to move the IETF forward in order to do that. Don't get me wrong: I get where most of this resistance is coming from, and I sort of agree that newcomers need to prove themselves. But instead of roadblocking and refusal I would have hoped to see something along the lines of: - What is a reasonable goal in terms of participation, so that having a meeting in Latin America is actually meaningful?: "X attendees from the region and Y people actively participating in mailing lists and contributing text" - After that, set the goal: "The IETF will hold a meeting in Latin America in the next four to five years" - What does the IETF to do that?: "The IETF needs partners to pledge X $ in sponsorship funds", or whatever else. - Reach out to your allies in the region. If we could agree on a basis set of participation principles, on metrics and on development goals, we will be a much stronger organization. regards, ~Carlos > That was simple, wasn't it? >
RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard
Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > > at time T1 has not responded, the DHCP client enters the REBINDING state > > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwi...@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwi...@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' 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-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. ___ Softwires mailing list softwi...@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list softwi...@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Re: [lisp] 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@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? 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. 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: Newcomers [Was: Evolutionizing the IETF]
On 16/11/2012 01:27, John Levine wrote: >> Shall we move on? > > Sure. Since we agree that there is no way to pay for the extra costs I wouldn't say that we agreed on that. We do not want to look how to pay the extra cost, we are simply not interested. We agree on this. > 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? > Yes, disappointing but simple. Regards, as
Re: [lisp] Last Call: (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: (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: (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: (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: (LISP EID Block) to Informational RFC
On 16/11/2012, at 7:24 AM, Dino Farinacci 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,
