Subject: [RRG] Stretch in case of LISP+ALT

From: "Heinrich Hummel" <[email-masked]>
Date: Tue, 02 Sep 2008 12:00:07

Although I always cautioned when ANY hierarchical routing was accused to cause a stretch ratio =3, I would be curious to hear from stretch experienced researchers what they think about the stretch ratio in case of LISP/ALT. 
( I cautioned because of a different and btw really virtual topology in mind; LISP/ALT employs a real and not virtual topology of tunnels).
Could a relationship between stretch and mapping churn exist like:
The less ETRs, the less mapping churn, but the greater the stretch ratio!
Resp. a smaller stretch value can only be achieved by more ETRs and more EID-RLOC propagation, i.e. more update churn, i.e. less solving the scalability problem ?

Heiner

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Sep 2008 09:49:14 -0700

> Although I always cautioned when ANY hierarchical routing was  
> accused to cause a stretch ratio =3, I would be curious to hear from  
> stretch experienced researchers what they think about the stretch  
> ratio in case of LISP/ALT.
>

Does it matter what the stretch ratio is for Map-Requests? Are you  
thinking about Data Probes and the effect on packet delivery  
performance?

> ( I cautioned because of a different and btw really virtual topology  
> in mind; LISP/ALT employs a real and not virtual topology of tunnels).
>

Please elborate. The LISP+ALT topology is supported by a set of routes  
advertised and learned in another BGP process reflecting the  
addressing and configuration of a tunnel topology.

It's "virtual" (even though this term is way overloaded) because two  
eBGP speakers don't have a direct physical link between them in most  
cases. The have a GRE tunnel between them and the eBGP peering  
addresses are the addresses configured on the tunnel (and are not the  
tunnel endpoint addresses which are out of RLOC space).

> The less ETRs, the less mapping churn, but the greater the stretch  

Well in my mind the number of ETRs is relative to the number of  
connections a site has to the Internet. You can't and probably don't  
want to reduce that because it's necessary for the site's multihoming  
ability.

The mapping churn will be dominate on how long you keep mappings cached.

> Resp. a smaller stretch value can only be achieved by more ETRs and  
> more EID-RLOC propagation, i.e. more update churn, i.e. less solving  
> the scalability problem ?
>

Smaller stretch can occur if you can map the tunnel topology closer to  
the physical topology.

Dino

--
to unsubscribe send a message to [email-masked] 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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 02 Sep 2008 22:54:47

-------- Kabel E-Mail Reply ---------------
From: [email-masked]
To : [email-masked]
Date: 02.09.2008 18:49:20

HH:I guess, for those who researched by watching and emphasizing the stretch ratio, the resulting detour of the packet  flow  matters, independent of how the  detour  has been caused (Map-Request or Data Probe).

HH:Well, as you know, my vision is that each router acquires a very sparsed image of the internet topology  which is more appropriate to be called "virtual" (but this is only playing with words).

HH:Yes.

HH:Maybe I do not properly understand where there is a hierarchy of tunnels. 

Heiner

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Sep 2008 13:57:52 -0700

> HH:I guess, for those who researched by watching and emphasizing the  
> stretch ratio, the resulting detour of the packet  flow  matters,  
> independent of how the  detour  has been caused (Map-Request or Data  
> Probe).
>

There is no detour of packet when a Map-Request is sent because it is  
dropped by the ITR. A feature actually and not a bug.

Dino