Subject: Re: [lisp] No LISP meeting for Berlin

From: [email-masked]
Date: Fri, 12 Jul 2013 03:09:28 -0400 (EDT)

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-masked]>
An: heinerhummel <[email-masked]>
Cc: Sharon <[email-masked]>; lisp <[email-masked]>
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-masked] 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-masked]>
> An: heinerhummel <[email-masked]>
> Cc: farinacci <[email-masked]>; lisp <[email-masked]>
> 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-masked]" 
> <[email-masked]> wrote:
> 
> 
> 
> See my notes starting with HH inside.
> Heiner
> 
> 
> 
> -----Ursprüngliche Mitteilung-----
> Von: Dino Farinacci <[email-masked]>
> An: heinerhummel <[email-masked]>
> Cc: damien.saucez <[email-masked]>; lisp <[email-masked]>
> 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-masked]>
> An: Damien Saucez <[email-masked]>
> Cc: heinerhummel <[email-masked]>; lisp <[email-masked]>
> 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-masked]> wrote:
> 
> 
> 
> 
> 
> On 06 Jul 2013, at 11:58, [email-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/lisp
> 
> 
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
> 
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Jul 2013 09:29:21 -0700

> It was in vain, instead  the TTL-mechanism, which is embarrassingly poor, is still in place (and is adopted by LISP - of course),

Let me make a technical point.

Let's say we have MAC addresses as EIDs. Let's say we have MAC addresses that are also RLOCs. If an ITR receives a MAC frame from a host and encapsulates to an RLOC, do you realize in this scenario LISP is in use but there is no TTL decrement anywhere?

Why is that? Because 802 frame does not have a TTL.

If the EID space is using a protocol that has rules to be obeyed, LISP will obey those rules. Hence, an IPv4 packet with a TTL is being decremented because that is what IP routers do. After they do that and LISP kicks in, LISP defines how encapsulation should be performed.

So it is not true in either case above that LISP has adopted a TTL-mechanism.

Dino

---

From: [email-masked]
Date: Sun, 14 Jul 2013 05:09:57 -0400 (EDT)

Certainly, LISP just tries to comply with what exists. I can understand this, and yes, I would even have blamed LISP if it requested to look into the inner (IP-) header and to decrement there the TTL-counter.

The TTL-poorness is an rtgwg-issue and hereby an intra-domain issue. Correct me, if I am wrong saying that the TTL-counter is re-initialized when SP-borders are traversed :-(

Its poorness stems from the belief that endless loops can occur.  With TARA however you can validate/use ALL adjacent links (for forwarding) i.e. incl.the incoming link ( crank back link). Detouring routes are either imposed with restricting rules, or, some links may be recognized as entrance to some dead-end area. In this case, as well as if the imposed restriction cannot be complied with, the packet is discarded.

Heiner   

-----Ursprüngliche Mitteilung----- 
Von: Dino Farinacci <[email-masked]>
An: heinerhummel <[email-masked]>
Cc: marc <[email-masked]>; lisp <[email-masked]>
Verschickt: Fr, 12 Jul 2013 6:29 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

> It was in vain, instead  the TTL-mechanism, which is embarrassingly poor, is 
still in place (and is adopted by LISP - of course),

Let's say we have MAC addresses as EIDs. Let's say we have MAC addresses that 
are also RLOCs. If an ITR receives a MAC frame from a host and encapsulates to 
an RLOC, do you realize in this scenario LISP is in use but there is no TTL 
decrement anywhere?

If the EID space is using a protocol that has rules to be obeyed, LISP will obey 
those rules. Hence, an IPv4 packet with a TTL is being decremented because that 
is what IP routers do. After they do that and LISP kicks in, LISP defines how 
encapsulation should be performed.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 14 Jul 2013 08:01:56 -0700

> The TTL-poorness is an rtgwg-issue and hereby an intra-domain issue. Correct me, if I am wrong saying that the TTL-counter is re-initialized when SP-borders are traversed :-(

In ITR copies the inner header's TTL to the outer header's TTL if the inner and outer headers have a TTL field.

Dino