[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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








-------- Kabel E-Mail Reply ---------------
From: dino@cisco.com
To : heinerhummel@kabelmail.de
Date: 02.09.2008 18:49:20

> 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?

 

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).

> ( 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.

 

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).

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).

 

HH:Yes.

> Could a relationship between stretch and mapping churn exist like:
>
> The less ETRs, the less mapping churn, but the greater the stretch
> ratio!
>

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.

 

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

 

Heiner