Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today

From: Acee Lindem <[email-masked]>
Date: Tue, 5 Nov 2013 14:39:09 +0000

Hi Mark,
I attended and the majority of the discussion centered on whether the
problem could be solved with a simpler model such as a FIB per provider.
Fred pointed out that this would not handle overlapping source subnets and
the fact that it was possible to solve the general problem with a Patricia
tree and the installation disambiguating routes. Alvaro also commented
that there are use cases beyond homenet. As you'd expect, the next step
was that there needs to be more discussion on the RTG WG list (copied).
Thanks,
Acee

On 11/4/13 11:05 PM, "Mark Townsley" <[email-masked]> wrote:

>
>Was anyone on this list able to attend the rtgwg meeting today where Fred
>presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed it,
>and would be interested in the reaction, feedback, or next steps (if any).
>
>Thanks,
>
>- Mark
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 5 Nov 2013 15:19:54 +0000

Yes, pretty much. 

>> and would be interested in the reaction, feedback, or next steps (if any).

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Teco Boot <[email-masked]>
Date: Tue, 5 Nov 2013 07:47:58 -0800

I’m happy to confirm recent stable Linux kernel IPv6 subtrees cache problem is fixed. No need to do something special here, just give in some ip -6 route add default from PREFIX [ via ADDRESS ] [ dev STRING ] commands.
Sure we need to have a distribution mechanism having all routers know some form of (source_prefix, exit_link) mapping. If we take the limitation to support only default routes, a simple border router discovery and recursive FIB lookup will do. Select the route to the border router, or, on the border router, use the right exit link.
@Fred: I suggest you add my BRDP proposal in your list of efforts. No code yet. It is the blueprint for MultiSmartGateway for v6 in olrsd2, to replace SmartGateway tunnels which are used in current olsrd.org code.

Teco

---

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Nov 2013 15:26:45 -0800

The derived requirements from draft-baker-rtgwg-src-dst-routing-use-cases (copied below) were based upon the outcome of a meeting at the last IETF in Berlin among the various "source plus destination routing" draft authors. Fred will be presenting this draft tomorrow in homenet. This functionality is fundamental to the operation of a multihomed homenet, so I'd like to get feedback (on list and during the meeting) on whether these are indeed the agreed upon requirements between the two groups.

  o  The routing protocol or mechanism includes a source prefix.  It is
      acceptable that a default source prefix of ::/0 (all addresses)
      applies to routes that don't specify a prefix.

   o  The routing protocol or mechanism includes a destination prefix,
      which may be a default route (::/0) or any more specific prefix up
      to and including a host route (/128).

   o  The FIB lookup yields the route with the most specific (e.g.
      longest-match) destination prefix that also matches the source
      prefix constraint, or no match.

Thanks,

- Mark

---

From: David Lamparter <[email-masked]>
Date: Thu, 7 Nov 2013 00:51:37 +0100

> was that there needs to be more discussion on the RTG WG list (copied).

I disagree that it needs more discussion, at least on this particular
item.  It's an implementation detail.  The way it's currently described
does somewhat imply single-FIB, but it doesn't prescribe it, and in the
end it *is* the match behaviour we want - so, I'd just interpret it as
requirement on the _behaviour_ and if anyone wants to go with multiple
FIBs in their implementation, feel free...

(Yes, trying to put the "implementation detail" lid on the discussion
here.)

If anyone thinks we should have different match behaviour, that's a
different discussion (but I haven't heard anything in that direction.)
Describing the same match behaviour with multiple FIBs per source
doesn't sound easier to me.  I believe the current description is as
simple and down to it as it gets.

-David

P.S.: I'm not even sure if a "FIB per provider" model is actually
simpler, and I'm pretty certain the implementation is more complex.
You'd have to copy most of the FIB content to each of the FIBs,
dynamically create FIBs when upstreams appear/disappear (on remote
routers even), and then there's also the case of an upstream going down
=> its addresses being deprecated => host still using them for old local
connections => router should retain local connectivity for deprecated
prefix => router needs to retain FIB with timer.  Also needs to be done
with routes, but I'd prefer doing it on routes only, and not on routes
and FIBs.

And I almost deleted that PS - really, implementation detail!

---

From: Teco Boot <[email-masked]>
Date: Wed, 6 Nov 2013 17:19:27 -0800

>       to and including a host route (/128).

For homenets and having ingress filtering as BCP, I think ::/0 routes with ::/0 source prefixes shall not be used. Also, for homenets I do not see a use case for non-::0 destination prefixes with non-::/0 source prefixes.

>       prefix constraint, or no match.
I think this needs better specification. Something like:
   o  The FIB lookup yields the route with the most specific (e.g.
      longest-match) destination prefix, and thereafter use the most 
      specific (e.g. longest-match) source prefix.

Or from troan-homenet-sadr:
   First a longest match lookup is done in the routing table for the
   destination address, then for the resulting set a longest matching
   lookup is done for the source address.

This is running code with recent Linux kernel, with enabled CONFIG_IPV6.

Teco

---

From: David Lamparter <[email-masked]>
Date: Thu, 7 Nov 2013 03:06:48 +0100

On Wed, Nov 06, 2013 at 05:19:27PM -0800, Teco Boot wrote:
> For homenets and having ingress filtering as BCP, I think ::/0 routes
> with ::/0 source prefixes shall not be used. Also, for homenets I do
> not see a use case for non-::0 destination prefixes with non-::/0
> source prefixes.

The NTT video service mentioned several times (forgot the name) is a
good example of non-::0 dst with non-::0 src.  Admittedly, you could
drop the source information without too much loss there, but I'm still
hopeful that we can somehow feed that information up into the host to
improve source address selection.

That use case also presents a nice demo of the non-match behaviour
because there will be no (dst ::0 src <videoprefix>) route, yielding an
automatіc unreachable should a host try to go on the internet with its
video address.

-David

---

From: Teco Boot <[email-masked]>
Date: Wed, 6 Nov 2013 23:32:13 -0800

Op 6 nov. 2013, om 18:06 heeft David Lamparter <[email-masked]> het volgende geschreven:

> good example of non-::0 dst with non-::0 src.  

Why would ::/0 from SOURCE_PREFIX not work? It enables access to whatever prefix of the video service infrastructure.

Same model applies to VPN tunnel to enterprise network. It is a waste of energy to flood enterprise prefixes to VPN client. Sinking traffic with source VPN prefix will do.

Teco

> Admittedly, you could

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Nov 2013 12:08:03 -0500

> not see a use case for non-::0 destination prefixes with non-::/0

Access to the LLN in the home might only effectively work if you use the
(right?) ULA.    

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works