[rbridge] Draft problem statement

[Aidan Williams]

Erik Nordmark wrote:
>  >   The "multilink" proposal at the time had scope to become more than an
>  > ARP/ND proxy.  It was heading toward "IP bridging".  Work had been done
>  > looking at IS-IS as the underlying routing mechanism ("host routes") and
>  > on getting DHCP to work.
> 
> Was this the ND-proxy-based multilink subnet work, or was there
> some other body of work that you are thinking of?
> 

It was the thinking that was going on around (perhaps prior) to the 
ND-proxy-based multilink subnet work.

I think (expired) drafts
   draft-thaler-ipngwg-multilink-subnets-0[012].txt
are worth a read because they list some design goals and three 
approaches to a solution.

What ended up being pushed forward in the ipv6 wg was the ND-proxy approach.

>  > On the other hand, an "IP-bridging" solution would better handle
>  > incompatible L2 links (ie links with different MAC address formats and
>  > MTUs).
> 
> I suspect that there can be many potential requirements here.
> While I haven't thought much about it, it might be that one can
> come up with robust solutions that provide 2 out of 3 (but not all 3 of):
>  - handle different MAC address formats
>  - invisible to the hosts e.g. not decrementing the IP ttl
>  - not restricted to sending data packets along a spanning tree
> 
> I certainly haven't seem something which claims to handle all 3, which is
> why I think we should be careful about not overconstraining the problem.
> 

I agree that there are many potential requirements.
I'm still thinking about the "not decrementing IP ttl" requirement.

> Personally I think that working across L2 links with different MAC address
> formats is lower priority than the other two above, but I'm interested in what
> others think about this.
> 

I think supporting differing MAC address formats is a worthwhile design 
goal.  If we had IP bridging we could bridge IP datagrams directly to 
Bluetooth devices, Firewire, IRDA, [insert new L2] and avoid the 
redundant ppp or ethernet encapsulation cruft that gets added.  Having 
worked in the home networking space in my previous job, I think it would 
be a boon.

Because the home is an environment where people will plug stuff together 
in wierd ways, robust loop prevention is very important.  Having some 
things that do ND-proxy/ARP-proxy without loop detection/prevention 
feels like a disaster waiting to happen.

- aidan