Subject: Re: [rrg] MIP in a future routing architecture

From: [email-masked] (Noel Chiappa)
Date: Wed, 25 Nov 2009 18:46:29 -0500 (EST)

> From: [email-masked]

    > Whenever I mentioned, how badly MIP is handled by all models of the
    > well-positioned RRG-contributors, the response was silence. In the
    > LISP[ mailling-list] discussion this issue is officially
    > deferred.

Assuming that by "MIP" you mean 'mobile', and not 'multicast' or
'multihomed', this is in good part due to the fact that mobility is
explicitly outside the scope of the LISP WG charter; the WG's charter was
the result of some fairly tense negotiation, and I gather the Area
Director would look unfavourably at both i) the WG straying outside its
charter, and ii) diverting into other topics rather than making sure it
gets its listed deliverables done promptly, and on schedule. Having
said that...

    > Bottom-line: Let's push LISP as it is and let's think about MIP
    > later, when LISP is well anchored.

This is in fact not true, as Dino has pointed out: a fair amount of
thought has gone into how LISP could support mobility, and there is
a draft.

	Noel

---

From: [email-masked]
Date: Thu, 26 Nov 2009 04:17:37 EST

In einer eMail vom 26.11.2009 02:28:51 Westeuropäische Normalzeit schreibt  
[email-masked]:

Lixia  pointed out that mobility is a fundamental requirement but not  a
fundamental component.  For any proposal RRG have come up with,  there
are at least several ways to support mobility.  RRG's focus is  rightly
on routing and addressing architecture.  There is reason for  confidence
that whatever we nail down for routing and addressing, we can  build
mobility on top of it.

Scott,
Yes, of course. But how to do the adjustment ! We used to joke:  Koflach, 
the ski boot being that hard, that every foot will adjust to it. I  think the 
other way around would be more convenient.
 
Why not design the routing architecture such that you don't need a home  
agent or care-of-address server !
And, in particular situations, that you might find your destination  
although you have only a vague idea about its current location ?!!!
 
Heiner

---

From: [email-masked]
Date: Fri, 27 Nov 2009 18:31:58 EST

In einer eMail vom 27.11.2009 22:09:22 Westeuropäische Normalzeit schreibt  
[email-masked]:

>  Dino,
> Having read the Meyer-draft, I realize that "mobile node" does  not  
> mean "mobile router" but rather "mobile user (handset)". I  assumed  
> it means mobile router, which wrt LISP would mean  mobile RLOC.

Right, the LISP mobile node implements a simple version of  an ITR and  
ETR and acts like an entire LISP site. So all the  multi-homing  
features are available to the mobile-node.

And  when it roams, /32 host routes are not injected into the  
underlying  routing system.

> The draft mentions that it supports IP mobility  without a home-agent.
> Well , the truth is, a mn may proxy the  home-agent to some limited  
> extent.

The Map-Server is  where the roaming LISP mobile-node registers to when  
its locators  change. That *could* be viewed as a home-agent, but  
packets don't  flow through the Map-Server like they would for a MIP  
home  agent.

The stretch from LISP MN to LISP-site CN is 1. Which means  the  
shortest path between the two locators is taken.

>  This is not what I am talking about. My vision: If the DNS can  
>  provide the geographical coordinates (RFC 1712 experimental) we  
>  could route to the respective egress router, and in case this geo- 
>  information is pretty vague (due to roaming within some scope of   
> geographical neighborhood) we can make a well-scoped  search.

You want to route based on topological closeness and not  geographical.  
But more to the point you want to forward packets on a  path that has  
less total queuing in each hop. That is reduce the  number of hops.
I want to do next hop forwarding based on knowing the internet's topology,  
however well reduced so that  links between far remote nodes aren't  
contained - but certainly links from some node inside my own geo-patch (or  inside 
my nearby geo-path cluster) to some node at the other half of the globe.  
If, by DNS, users are assigned their DFZ-routers' geographical coordinates, 
then  that DFZ-router or any other one which however is closest to it (and 
which has  been determined to show up e.g. in the world map )  would be taken 
as the  destination node towards which a route can be computed and the 
respective first  hop taken.  
 
There are many many more routes than just shortest routes which are  
loop-free (and even more than that, e.g. crankback routes whereby endless  looping 
can be avoided certainly).
I could even envision time-of-day routing !!! 
It could be a new dawn in routing technology i.e. the work base  for 
generations of IETF-goers to come.
 
Heiner

> By other words: Abolishing the scalability problem is  just a side  
> effect for better routing capabilities.
> he  fundamental difference is: All IP folks consider IP-addresses  
>  routable although it is only mappable (as are MAC-addresses, too).   
> Wheras addresses, derived from the geographical coordinates  have  
> always a well-known scope.

Are you saying locator  addresses are always geographical? And if so,  
if a node roams where  its location changes geographically, does the  
address change? And is  this address stored for end-point socket state?

Dino

> In  einer eMail vom 27.11.2009 19:21:12 Westeuropäische Normalzeit  
>  schreibt [email-masked]:
> > Thank you, Dino, for updating me wrt  LISP&mobility and for sending
> > the Meyer-draft.
> > I  do understand the organizational arguments with the LISP-charter.
> >  But wrt RRG, the mobility issue should have highest priority.
> >  Obviously, you can cater for mobility on top of whichever routing
> >  architecture. Proof: MIP4.
> > But in search of a future routing  architecture you can also come up
> > with something that doesn't  depend on a home-agent and  which is
> > also most appropriate  for mobile nodes, i.e. some other than a
> > mobility-jack-up  solution.
>
> Well, yes, if you are going to build a scalable  architecture, it has
> to scale with the type of devices that Internet  plans to deploy in the
> coming decade. And we all know mobile phones  will be ubiquitous.
> Yes. That's why TARA is the best solution for it.  You don't have to  
> disseminate where the geographical  coordinates (x,y) are located:-)
>
> Regards,
>  Heiner
>
>
> Dino
>
> >
> >  Heiner
> >
> >
> > In einer eMail vom 26.11.2009  00:13:54 Westeuropäische Normalzeit
> > schreibt  [email-masked]:
> > Dave Meyer presented LISP-MN in the IETF Friday  morning LISP WG
> > meeting. The ID is enclosed. Dave can forward the  slides he used to
> > present.
> >
> > Dino
>  >
> >
> >
> >
> >
> >
>  > On Nov 25, 2009, at 3:09 PM, [email-masked] wrote:
>  >
> > >  LISP-mailinglist discussion this issue is officially
> >  deferred.Bottom-
> > > line: Let's push LISP as it is and let's  think about MIP later,  
> when
> > > LISP is well  anchored.
> > >
> > > It seams to me that inside  RRG  this issue isn't handled
> > differently.
> >  >
> > > Heiner
> > >  _______________________________________________
> > > rrg mailing  list
> > > [email-masked]
> > >  http://www.irtf.org/mailman/listinfo/rrg
> >
>  >
>

---

From: [email-masked]
Date: Fri, 27 Nov 2009 18:52:45 EST

In einer eMail vom 27.11.2009 22:14:40 Westeuropäische Normalzeit schreibt  
[email-masked]:

> In  einer eMail vom 27.11.2009 19:28:17 Westeuropäische Normalzeit  
>  schreibt [email-masked]:
> > In einer eMail vom 26.11.2009 02:35:49  Westeuropäische Normalzeit
> > schreibt [email-masked]:
> >  Did anyone indicate if multicast was a fundamental requirement or
> >  fundamental component?
> >
> > Dino
> >
>  >
> > Multicast: It strikes me that multicast has never been a  topic for
> > RRG discussion, although it is mainly a routing  issue.
>
> I would like to know if the RRG is going to recommend  an architecture
> that explicitly says it won't include multicast, or it  will implicitly
> include it but lack any reference to how it will  scale. But I do think
> "multicast" is "routing".
> Totally in  sync.
>
>
> > State-less multicast would be a valuable  topic, I thought 3 years
> > ago when I tried to launch a respective  EU-ICT project which was
> > rated to be "very poor" (not only simple  "poor" as was NIRA).
> >
> > However, state-less multicast  can be done by changing the multicast
> > philosophy. Multicast must  adjust, and not the routing architecture.
> > Will say, it can be  accomplished with the current BGP as well.
> > Nevertheless, the  combination "state-less multicast + location-based
> > routing" might  be even more beneficial. E.g. inspire future research
> > work as to  minimize the hereby accepted disadvantages/costs.
>
> What the RRG  could recommend is that we don't support a native
> multicast  architecture in the core but the edges could run multicast
> as defined  today but the edges would perform "replicated unicast".
> Yes,  replicated unicast ! My idea was: building a cascade tree of  
>  unicasts for sake of multicasting towards millions of receivers in a   
> most economical way:
> To catch the basic idea: the sender  sends the data to 10 receivers  
> (or their proxies), which in  return send them to 10 further  
> receivers etc.
> Given  that each party gets the same list of participants it will be  
>  able to identify its 10 successors based on its own position inside   
> this list.
> Furthermore: the degree 10 might not be sufficient  if there are only  
> m branching-capable nodes while n>>m  receivers are to be serviced.So  
> I was able to compute the  adequate "degree of cascading" and also to  
> compute the adequate  positions of the branching-capable nodes inside  
> this list of  participants.
> Effectively, there is only unicast between any two  branching capable  
> nodes, and let's say 90 % of the receivers  are stupid ones being  
> leaves of the cascade  tree.
>
> Disadvantage: via the same physical link several copies  of the same  
> packet might be forwarded.
> Advantage:  states are required just at a minority of branching- 
> nodes.Combined  with location-aware routing the disadvantage might be  
> reduced  eventually upon further study.

I think we should try to use multicast  where it is available but not  
require it end-to-end or else we'll  never have a solution deployed.  
This is already evidence from the  IPv4 multicast Internet, where is is  
available in many places but  can't be trusted to be everywhere.

You refer to an important point:
Assume there are 1 Mio. receivers and among them there were enough  which 
are able to "cascade-branch" such that cascade-degree = 10 is sufficiently  
high.
Then 1+10+100+1000+10000 +100 000 = 111 111 nodes must be knowledgable,  
while 888 889 dumb ones could assume to get plain unicast data. Also, for any  
transit router, it's pour unicast as well.
 
Also unicast requests within a narrow time-window might be served in  this 
way, too.  DoS attacks would fail !
 
Heiner

The  point is that the routing folks should deliver a "multi-recipient"   
service to the applications so app writers can assume there is end-  
point multicast capability (i.e. joining groups, send 1 packet from   
the app to the group, etc).

And how we, at the routing layer, get  those packets to all recipients  
is open for architectural  discussions. One example is doing AMT over  
LISP-Unicast versus doing  LISP-Multicast.

Dino

> I provide references to a "replicated  unicast" at the network layer as
> well as attaching doing core based  native replication as in LISP-
> Multicast.
>
>  Dino
>
>
>
> I will read the sent draft in the coming  days.
>
> Heiner
>

---

From: [email-masked]
Date: Sat, 28 Nov 2009 03:30:10 EST

In einer eMail vom 28.11.2009 02:08:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

Replicated unicast is simply not multicast and 
clearly does not  scale.

Tony

...unless you  provide a (most) scalable replicated unicast  model.
Scalability in the following sense:
a) classic unicast at any transit router
 
b) classic unicast for most of the participants 
   (Examples with 1 Mio. receiving participants:
    Cascade-degree-10: 
    1+10+100+1000+10 000+ 100 000 = 111 111 participants  with states, 888 
889 without (=classic unicast)
    Cascade-degree-100:
    1+100+10000= 10101 participants with states, 989 899  without (=classic 
unicast).
 
c) The work load per stateful participant is well limited by the selected  
cascade-degree.

Heiner

---

From: [email-masked]
Date: Sat, 28 Nov 2009 16:24:40 EST

In einer eMail vom 28.11.2009 20:50:31 Westeuropäische Normalzeit schreibt  
[email-masked]:

Well if  multicast proper is not on the requirements for scaling the  
routing  architecture, how can we set our sights higher?

Do you expect multicast  route scaling to be solved in some other forum  
like perhaps  SAMRG?

Dino

Next to IP-Mobility, scalable multicast to multiple millions of receivers  
should be on the radar screen, too.
All multicast holy cows should be tabled: E.g. the multicast address as  
such. A different protocol type plus the sender's source address may entirely  
replace it (and free a lot of IPv4-addresses).
 
Cascade tree routing could be used for p2mp (=multicast) as well as  mp2mp.
 
Because it can even be combined with today's BGP, I do not see an impact on 
 any model for a future scalable routing architecture.Multicast itself has 
to  change, imho.
 
I have gone over the AMT-draft roughly. I know that the authors are able  
to adapt its basic idea to pim-ssm.
Neither here nor with my Cascade Tree Routing branching/relaying can be  
done at the receiver devices (uploading takes more time than downloading due 
to  the asynchron DSL). So I see shared problems, which btw can be worked out 
by  others than me much better.
 
Heiner