Hi Eliot, Thanks for your reply, in which you wrote:
>> Eliot developed a similar "anycast ITRs in the core" approach >> for LISP-NERD. > > This has been ascribed to me before, and either I misspoke or was > misunderstood. You didn't use the term "anycast", but you wrote an alternative approach to two proposals I made, both of which have problems, and which I think were the only alternatives to "anycast ITRs in the core". http://psg.com/lists/rrg/2007/msg00260.html > I think I would handle this differently. Prior to withdrawing > 20.0.0.0/20 there should be a reasonable number of ITRs in SP > environments. So far I think this is the standard LISP approach of relying on there being enough networks with ITRs that the unreachability of 20.0.0.0/20 from networks without ITRs would somehow not be a problem when this prefix is no longer advertised in BGP. The trouble is that even a few hosts in networks without ITRs is probably a completely unacceptable problem for anyone contemplating using this address space. > At that point it makes sense for those to at least locally > propagate a NOEXPORT route along the lines of 20.0.0.0/8. This is not exactly anycast, but I understand it involves multiple border routers of multiple ISPs acting as multiple ITRs and advertising the same prefix to neighbouring ISPs - with NOEXPORT preventing those ASes (or is it those routers?) from propagating the route to this prefix any further. So the neighbouring ASes which do not yet have ITRs would have their hosts able to reach hosts in the LISP-mapped prefix 20.0.0.0/20. NOEXPORT ensures that those neighbouring ISPs would not transit traffic from their neighbours to this prefix. Depending on AS topology and how many ASes didn't yet have ITRs, this would marginally reduce the number of ASes in which hosts could not send packets to 20.0.0.0/20. So it is not a complete solution. > One could go further and say that it should be a 0.0.0.0/1 and > 128.0.0.0/1. That would make each border router in a LISP-upgraded AS (each one is implicitly an ITR as well) attract packets for all otherwise unadvertised address space from its neighbouring ASes. This would collect all the packets from neighbouring ISPs which need to go to an ITR, when the neighbouring ISP has no ITRs. > At that point you can have multiple ITRs doing this for > redundancy's sake, and you're doing it with very few routes. > Maybe 200-300 at most. The key points you make include having multiple ITRs advertising the same prefix. To me, this is anycast. However, as long as they all advertise with NOEXPORT, maybe this isn't quite the same as "anycast". I don't see the purpose in limiting the range of packet collection with NOEXPORT. Still, it was close enough for me to regard it as "similar" to "anycast ITRs in the core". I wrote about this to the list because it was at a time when no-one else involved in LISP had said anything positive about my "anycast ITRs in the core" proposal. > I believe Dino early on recognized that anycast > could be a useful scaling mechanism for LISP. I myself have not > explored anycast in any substantial way. I have, however, > pondered transitions, but I have not devoted as much "ink" to > transition as perhaps you and others have. Our early exchange > you quote below refers to multiple announcements and not anycast. I don't see how "multiple announcements" - multiple ITRs in the DFZ advertising the same prefix is different from "anycast", as I use the term or as it is used in the new ID: http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt unless your use of NOEXPORT is regarded as such as difference. Normal BGP practice is to have one router advertising a particular prefix. If two or more do, I think it is reasonably described as "anycast". The principles are the same whether it is 2 or 20,000 routers advertising the same prefix. >> It seems, from the language with which [Eliot] expressed his >> ideas, that he developed this independently of whatever he >> might have known about Ivip. He acknowledged that his approach >> resembles mine: >> >> http://psg.com/lists/rrg/2007/msg00260.html >> http://psg.com/lists/rrg/2007/msg00264.html >> http://psg.com/lists/rrg/2007/msg00288.html > > As I said, I was told there were similarities, probably by you. Yes - as much as I understand what you wrote, it seems to be very similar in principle to "anycast ITRs in the core/DFZ", which is in Ivip and draft-lewis-lisp-interworking-00. I recognise that what you wrote was in a mailing list message rather than an ID, but you were providing information on the possible future direction of LISP-NERD and helping to show how it could be incrementally deployed. > Also, I have not been focusing on transition but longer term > matters. Although it may appear the case by company name, we are > not all at Cisco of one mind, and sometimes our best > coordination occurs at IETF, IRTF, and similar places. LISP IDs are written by quite a number of people and I don't assume you all think alike or work closely together. The basic LISP architecture can be used with various mapping systems. NERD takes the middle road in terms of speed for a push system - faster than eFIT-APT and slower than Ivip's ambitious "few seconds" goal. I think push to the ITRs (and/or push to local query servers, as is possible with Ivip and as is the basic architecture of eFIT-APT) is better than relying on a global query system as does LISP-CONS and TRRP. That global query system is bound to be slow and unreliable - and also costly and potentially complex, as is LISP-CONS or LISP-ALT. > And to be fair, I do not have a full understanding of iVIP. I didn't suggest you understood Ivip, or what I wrote to the RAM list starting on 2007-06-15. I guess you developed it independently - though I was arguing the inevitability of "anycast ITRs in the core" in list discussions at the time. > Finally, please understand that with such a fast moving field, > and a -00 draft out, I think figuring out who did what first has > not been foremost on people's minds. I personally try not to be > original about anything ;-) > > All the best, > > Eliot Who thought if this first and who wrote in public about it first are minor matters compared to the importance of acknowledging that a mechanism Y in scheme X is similar or identical to mechanism B in scheme A. We owe that to the readers of our IDs. This field is difficult enough without people writing up the same thing, as if it was a new and different approach to what has already been publicly proposed in another scheme. There is a strong tradition in science, engineering and the IETF of correctly attributing the source of ideas - or at least any prior publication of similar or identical ideas. I do try to be original. I come into this field with less experience of networking than most people on this list. That is an obvious disadvantage - but one advantage is I see may things in a fresh light. There is an adage about never asking an expert to do something which is "impossible", because they know it can't be done. If I propose 10 things and only one of them turns out to have long-term value, I figure this is worthwhile. Few people seem to think it is practical to do what I intend with Ivip - fan relatively simple mapping data out around the world to a few hundred thousand (later millions?) ITRs in a few seconds. I reckon it can be done. If not, there are plenty of other ideas in Ivip and IPTM which I think might have long-term value. If it can be done, then the ITR-ETR scheme can be simpler and support mobility in efficient ways not previously dreamed of by mobile IP people - because they never considered that something like a global ITR scheme could be justified just for mobility. Since we have to build a global ITR scheme, I say lets make it fast and simple from the start. If LISP was built, in any form, people would soon be trying to soup it up to get the mapping data to the ITRs faster. Cheers - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
