Marc,
I am in favor of better routing which can only be accomplished if all holy IETF-paradigms are allowed to be questioned. Almost ten years ago I showed the rtgwg group how to do better than "not via"-routing, but my algorithm was completely ignored. It not only would enable successful unicast routing as long as there exists a (though several times detouring) route, respectively recognize the dead-end situation. It was in vain, instead the TTL-mechanism, which is embarrassingly poor, is still in place (and is adopted by LISP - of course), Or : Traffic congestion is a network layer issue, and not a TCP issue !!! Traffic congestions can only be avoided ( resp. resolved) by proper balancing the routes to be taken. Or take Multicast. Why is state-less multicast not an objective ? Imagine state-less multicast whereby the sender is mobile, just like the receivers ! Imagine a MIP such that all users can be mobile, i.e. without the need of any immobile home-agent or care-of-address server! Or take Anycast. Defined by IPv6 without scoping (which in return can't be provided anyway with the network layer being WHERE-agnostic). Why must intra- and inter-domain routing be such contraversal? Why DV, given that since Pythagoras (570 B.C.) the earth is known being a ball rather than a disc? Why collecting millions of routes, although millions of millions of routes could be supported without storing a single one? You are right, this critic is not LISP-specific, instead it is IETF-specific. Getting back to LISP: A while ago I was jealous on LISP because I had indidepndently the same idea with the "default mapping" i.e. that a TARA-router might advertise a prefix of length zero as to attract packets (just like Fuller proposed it for LISP). Hereby a TARA-router nearby the ingress would have acted as a proxy i.e. enquired the DNS for being returned the destinations's TARA-Locator. But meanswhile this mini-extra-feature is nothing compared with the immense IPv4-address space extension achieved by starting TARA-forwarding at the source user, or at least there where the mapping of the destination's FQDN to its IPv4 address+LOCATOR can be induced. Meanwhile I think that the IPv4 deletion issue is even more challenging and more severe than the scalability issue, isn't it ? Heiner -----Ursprüngliche Mitteilung----- Von: Marc Binderberger <[email protected]> An: heinerhummel <[email protected]> Cc: Sharon <[email protected]>; lisp <[email protected]> Verschickt: Mi, 10 Jul 2013 10:24 am Betreff: Re: [lisp] No LISP meeting for Berlin Hello Heiner, I have to say your emails are difficult to parse. Anyway, I get the impression you talk about two different things. If you want a hierarchical address space for better scale or a global view of your routing with respect to congestion etc. then LISP is not solving this. LISP may help to decouple existing end point infrastructure from your transport network though. This allows you to introduce new schemes in the EID or RLOC space, including TARA if you wish. If you feel disappointed that IPv6 is "more of the same" you are not alone - but that's another story, not LISP. LISP is pragmatic, the separation opens the door for a new transport if needed - no more, no less. My $0.02 Regards, Marc On Tue, 9 Jul 2013 05:46:43 -0400 (EDT), [email protected] wrote: > Indeed, there are immensely many useful capabilities provided that > addressing would serve routing which is about the WHERE, WHERE-TO and > WHERE-FROM. > Consider E.164 : There are country codes and inside which ever > country where Siemens EWSD switches were deployed each rotary dialed > digit did select link after link electro-mechanically !!! down to the > destination. Inside Germany the leading digit "3" was spared for the > Eastern part while most the Western politician had given up hope for > the reunion and all of the Eastern part did everything to prevent it. > > > Whereas IP addressing is as WHERE-agnostic as is MAC-addressing or AS > numbering. No WHERE-knowledge nowhere. Conex doesn't recognize areas > of congestion, multi-homing is a "let's try the other link"-game as > to await what might happen. Columbus-Routing (knowing that the earth > is a ball) is out of question being against the holy DV-doctrine. > DiffServ is proud to operate without any knowledge about what is > beyond the waiting queues for incoming packets. IPv6 defines an > Anycast address space without scopes that limited the area of being > advertised. Examples: A Anycast-destination "free parking lot" might > only be disseminated inside the own city i.e. not outside of it. A > Anycast-destination "gas station" might only be disseminated over > some area whose radius corresponds with the remaining miles indicated > by a warning display to the driver.Etc.Etc. But such scope > is not intended at all and wouldn't even help because IPv6 is as > WHERE-agnostic as is IPv4. > > > With the upcoming of the loc-id-split paradigm I saw the chance for a > change and indeed TARA, being a loc-id-split solution, would end this > WHERE-agnosticism. > LISP however keeps up with it. As well as IPv6 :-( > > > Heiner > > > > -----Ursprüngliche Mitteilung----- > Von: Sharon Barkai <[email protected]> > An: heinerhummel <[email protected]> > Cc: farinacci <[email protected]>; lisp <[email protected]> > Verschickt: Mo, 8 Jul 2013 1:14 pm > Betreff: Re: [lisp] No LISP meeting for Berlin > > > > really don't want to interrupt this great dialog, just one comment. > > > don't think is about a bigger address space for routing, > but rather combining 2 completely different lookup schemes. > > > Step1: you lookup the routing location of Mr. Smith, or Mr. Li, or > Herr Meier or Mr. Dupont in a huge ID "phone book" a (secure) > distributed database lookup problem, strictly overlay not a routing > problem. > > > Step 2: you insert the letter into an outer envelope with a > postal-service (routable) address, leverage whatever hop to hop > routing lookup solution you have at the moment scale, cost, > efficiency wise. FedEx, ups etc. > > > Lots of use cases and benefits. > > > > > --szb > > On Jul 8, 2013, at 13:11, "[email protected]" > <[email protected]> wrote: > > > > See my notes starting with HH inside. > Heiner > > > > -----Ursprüngliche Mitteilung----- > Von: Dino Farinacci <[email protected]> > An: heinerhummel <[email protected]> > Cc: damien.saucez <[email protected]>; lisp <[email protected]> > Verschickt: So, 7 Jul 2013 8:59 pm > Betreff: Re: [lisp] No LISP meeting for Berlin > > > > "...But I would like to think we live in a world where people help > things that serve. " > > > > > Dino,really? > > > > Yes - really. When you post an email like you did (and you do it > repeatedly with little technical data), I have to respond that way. > > > HH: Here is all technical detail: > http://www.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/77501 > > By our last dispute a while ago I learnt that LISP does NOTHING to > ease the IPv4 > > > > And it never claimed to solve this problem. It you know what? It > does help because you can use other address spaces to help the > allocation of devices. So you can use IPv6 EIDs for site devices > versus IPv4 addresses. Allowing more IPv4 addresses to be used for > RLOCs and therefore be able to address more sites. > > > HH: But anyone who sees that the IPv4-address is enhanced by another > 4 octets locator is tempted to assume that uniqueness is provided by > some unique combination of IPv4 address + locator. Just as if a > postal letter is sent to some Mr. Smith, or Mr. Li, or Herr Meier or > Mr. Dupont. And btw, I am not sure whether that wasn't an initial > argument in favor of LISP, otherwise I would have brought up this > issue years earlier. > > > > adress depletion issue (well, it rather eats up some extra addresses). > While by involving the user as well as the DNS (i.e. by mapping a > FQDN to IPv4 > > > > How is LISP involving the user? > > > HH: LISP is not involving the user, that is my reproach. If there > were no IPv4 address depletion issue then it would be a pro-argument > not to involve the user. But a) we are used to getting WINDOW-updates > every now and then, and b) by expanding the IPv4 address space by > O(2^32) that pro-argument is overruled by far. (TARA would even > provide an IPv4-address space extension of O(2^40) !!! ) > > > > address + Locator) the IPv4 address space could easily do for another > thousand years (all it takes is to ensure that any IPv4-address is > unique per associated locator) LISP-DDT prevents that for good, and > you make us believe that LISP would be of any service to IPv4 ?! > > > > LISP-DDT is a database to move Map-Request around. It says nothing > about how and how much address is allocated. > > > HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had > once been better . > > > > The bad thing is that very very precious time goes by while (naive) > people/observers trust in LISP on this respect. > > > > Because it is becoming proven in their experience. > HH: I never doubted that LISP would just work as you have had it in > your mind, nor that you would be able to adjust it such that it suits > all existing forwarding mechanisms. > > > > > Just like myself when I argued that LISP-DDT cannot work assuming > that LISP were after a 4+4 octet unicast address space extension. > > > But you let all up to NAT. This is really not a serve. > > > > I cannot parse the above. > > > Dino > > > > > > Sorry, > Heiner > (having nothing said about the dooming malicious/political problems yet) > > > > > > > > > > > -----Ursprüngliche Mitteilung----- > Von: Dino Farinacci <[email protected]> > An: Damien Saucez <[email protected]> > Cc: heinerhummel <[email protected]>; lisp <[email protected]> > Verschickt: Sa, 6 Jul 2013 8:01 pm > Betreff: Re: [lisp] No LISP meeting for Berlin > > > > There are servers everywhere. Even not on the Internet. We leave in a > world of abuse. But I would like to think we live in a world where > people help things that serve. > > > Dino > > > > On Jul 6, 2013, at 4:21 AM, Damien Saucez <[email protected]> wrote: > > > > > > On 06 Jul 2013, at 11:58, [email protected] wrote: > > > My "Mass" for the LISP beer garden meeting: > > The LISP's dependency on special servers (DDT, formerly ALT) is a > perfect invitation for abuse - > either by malicious hackers or by malicious owners, or the alliance > of both. Who is able to control these servers is able to control > internet forwarding. > I can imagine that the RSA would like LISP very much. > > > > > > Don't worry, before you traffic to be encapsulated by LISP you will > use DNS... > > > Damien Saucez > > > > > > Heiner > > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > > > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > > > > > > > > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
