Subject: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

From: Ole Troan <[email-masked]>
Date: Mon, 18 Feb 2013 22:04:45 +0100

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
> Date: February 18, 2013 22:01:47 GMT+01:00
> To: <[email-masked]>
> Cc: <[email-masked]>
> Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for <otroan@localhost> (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET)
> Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 15:01:50 -0600
> Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000
> Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com [72.163.7.178])	by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IL1ixR029679	for <[email-masked]>; Mon, 18 Feb 2013 21:01:49 GMT
> Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000
> Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03;	Mon, 18 Feb 2013 13:01:48 -0800 (PST)
> Received: from mail.ietf.org ([64.170.98.30])	by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST)
> Received: from ietfa.amsl.com (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56;	Mon, 18 Feb 2013 13:01:47 -0800 (PST)
> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=neutral (message not signed) header.i=none
> X-From-Outside-Cisco: 64.170.98.30
> X-Ironport-Anti-Spam-Filtered: true
> X-Ironport-Anti-Spam-Result: Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM
> X-Ironport-Av: E=Sophos;i="4.84,690,1355097600"; d="scan'208";a="89740088"
> X-Virus-Scanned: amavisd-new at amsl.com
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> X-Test-Idtracker: no
> X-Ietf-Idtracker: 4.40
> Message-Id: <[email-masked]>
> Return-Path: [email-masked]
> X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com
> X-Ms-Exchange-Organization-Authas: Internal
> X-Ms-Exchange-Organization-Authmechanism: 10
> Mime-Version: 1.0
> 
> 
> A new version of I-D, draft-troan-homenet-sadr-00.txt
> has been successfully submitted by Ole Troan and posted to the
> IETF repository.
> 
> Filename:	 draft-troan-homenet-sadr
> Revision:	 00
> Title:		 IPv6 Multihoming with Source Address Dependent Routing (SADR)
> Creation date:	 2013-02-18
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-troan-homenet-sadr
> Htmlized:        http://tools.ietf.org/html/draft-troan-homenet-sadr-00
> 
> 
> Abstract:
>   A multihomed network using provider aggregatable addresses must send
>   the packet out the right path to avoid violating the provider's
>   ingress filtering.  This memo suggests a mechanism called Source
>   Address Dependent Routing to solve that problem.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: David Lamparter <[email-masked]>
Date: Tue, 19 Feb 2013 05:00:56 +0100

Hi Ole, Hi Lorenzo,

nice to see this moving forward!  Comments below with section
copy/paste.

> > Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
[...]

> 4.  Using SADR for multihoming
>
>    SADR is similar to policy based routing.  This memo proposes a simple
>    extension to the destination based longest match algorithm to
>    constrain it to source address.
>
>    In order to support ingress filtering by upstream networks, the
>    network MUST treat external routes specially.  Ingress filtering MAY
>    also be used internally, by installing (S,D) routes for locally
>    assigned prefixes, where the source prefix would be the aggregatable
>    prefix.  If no ingress filtering is performed inside the network,
>    then normal non-source constrained forwarding is used.

The last sentence seems to imply that, unless we have ingress filtering
on Internal Routers, they don't use SADR forwarding.  This doesn't seem
correct, shouldn't internal routers always use SADR to reach the
correct border router?  There is probably just a "for local networks"
missing before the last full stop.

> 6.2.  Simplified SADR in home networks

(In general, I'm not sure this simplified variant is a good idea... but
I don't have an opinion yet at this point.)

>    In a home network using a dynamic prefix assignment mechanism such as
>    [I-D.arkko-homenet-prefix-assignment] it may be known that a
>    particular Border Router is announcing both an External Route and a
>    Usable Prefix (for example, if the same router ID is announcing
>    both).  In this case, interior routers may assume that the Acceptable
>    Source Prefix of the External Route announced by that Border Router
>    is in fact the Usable Prefix announced by that Border Router.

"the" sounds like a Border Router will only ever announce one such Usable
Prefix.  Thinking of DSL/Cable routers with an USB UMTS/LTE dongle, this
isn't sufficient.

>    An internal router when receiving a AS-External LSA route will
>    install that in the routing table as normal.  When the internal
>    router receives a usable prefix as part of prefix assignment, the
>    router shall add source constrained entries to all the AS-External
>    routes received from the same border router (matching router-ID).

To address aforementioned issue, this should probably read:

    An internal router when receiving a AS-External LSA route will
    install that in the routing table as normal.  When the internal
    router receives one or more usable prefixes as part of prefix
    assignment, the router shall add source constrained entries to all
    the AS-External routes received from the same border router
    (matching router-ID), for each of the usable prefixes.

(Wording in arkko-homenet-prefix-assignment was changed from "usable
prefix" to "aggregated prefix" by the way)

>    Routes that are not associated with a border router or are not AS-
>    External do not have source constrained paths.
>
>    The routing protocol requirements for simplified SADR in the home
>    network are:
>
>    1.  Routing protocol must flood all information to all routers in the
>        home network.  (Single area).
>
>    2.  Prefix assignment and unicast routing must be done in the same
>        protocol.
>
>    3.  A router must be uniquely identified (router-id) so that router
>        advertisements and prefix assignment can be tied together

4.  All routers on the homenet MUST support simplified SADR routing.

If 4. is not given, this scenario will lead to a loop:
All links assumed at equal cost, r2 does not support simplified SADR,
R1,R3,R4 do.

ISP_A, pfx_A ::/0             ISP_B, pfx_B, ::/0
 |                            |
R1 ------ r2 ------ R3 ------ R4
 |
Host

Host now selects an address from pfx_B to reach some site on the
internet.  R1 forwards to r2 because the ::/0 from R4 is more specific
on the source.  r2 forwards back to R1 because it didn't consider source
specific-ness and just went by lower cost...

In particular, as long as R4 doesn't advertise "full" SADR LSAs, this
will also break if r2 implements "full" SADR, but not the simplified
variant.

Cheers,

David

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Feb 2013 07:15:14 +0100

David,

thanks for the thorough comments.

> missing before the last full stop.

yes, let me fix that.

> I don't have an opinion yet at this point.)

yes, it is a hack. it would allows us to proceed while waiting for SADR support in routing protocols though.

>    (matching router-ID), for each of the usable prefixes.

yes.

> 4.  All routers on the homenet MUST support simplified SADR routing.

I suppose that requirement applies generally, not only to the simplified variant.

> will also break if r2 implements "full" SADR, but not the simplified

yes, absolutely.

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Feb 2013 08:46:26 +0100

I have read this draft and find it useful.

> A routing entry may have both  (S, D) paths and (*, D) paths.  The
longest match wins

Section 5 seems to suggest SADR is just a tie breaker applied to the
subset of equal length D routes, but I think you probably should be more
specific on the phrase "longest match" in this sentence, as there are 2
length comparisons (one on D and one on S)

Section 6.2.

During autoconfig, if the prefix is delegated to other Homenet routers
on a hop by hop basis, the Homenet router receiving a new prefix could
indeed install a default SADR route for (parent_prefix/x,0:/0) -> the
upstream delegating router. So in this case your requirement 2 to
strongly couple autoconfiguration  and routing would not seem onerous.

But alternatively, if the delegation of prefixes within Homenet occurs
via a mechanism like DHCP PD, the receiving router could instead install
a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source
address, and then recurse the standard unicast routing table to find the
appropriate next hop toward the Homenet BR. This is a trick that works
very well in BGP networks (with next BGP hop being a software/loopback
interface of the AS egress router that is always up and stable, combined
with an IGP containing just the loopback addresses of the BGP speaking
AS egress routers)

In which case there's no requirement for a hard link between the routing
protocol and the prefix autoconfiguration mechanism, and thus no
requirement to update the IGP to carry SADR routes, which I think is
potentially a big win.

regards,
RayH

Ole Troan wrote:
>> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not signed) header.i=none
>> X-Ironport-Av: E=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088"
>> Content-Type: text/plain; charset=tf-8"

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2013 09:59:38 +0100

Ray,

> length comparisons (one on D and one on S)

yes, right now we say:

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

what if we also included some RIB entry examples?
e.g.

::/0 (route)
  2001:db8::/56 -> NH1 (path #1)
  2001:db9::/56 -> NH2 (path #2)
  -> NH#3 (path #3)

would that make it clearer?

> strongly couple autoconfiguration  and routing would not seem onerous.

right, in that case the parent prefix wouldn't really be the aggregate prefix though, and not
identify the border exit. in a strict routed hierarchy then I guess you wouldn't need SADR.

> with an IGP containing just the loopback addresses of the BGP speaking

yes, now we tie the aggregate prefix and the advertising border router using the router-id.
if the border router had a global address, that was included in the aggregate route advertisement
as well as the external route advertisements, we could use that instead.

it would certainly make the routing tables more clearer and more explicit.

> requirement to update the IGP to carry SADR routes, which I think is

that would be a big win, but I don't quite see how you avoid the hard link?
given that border routers may or may not advertise a default route, and may also advertise
more specifics... 

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Feb 2013 11:06:43 +0100

> Ole Troan <mailto:[email-masked]>
> 20 February 2013 09:59
> Ray,
>
Yes I think so. It's just a readability thing.

Suggest including various combinations e.g. (*,::/0) 
(2001:db8:1::/56,::/0)  (*,2001:db8:2::/56) &
(2001:db8:1::/56,2001:db8:2::/56)
> identify the border exit. in a strict routed hierarchy then I guess you wouldn't need SADR.
I don't see why it would not include this info. AFAIK we haven't yet
settled on a prefix delegation mechanism, so the mechanism could carry
both the aggregate prefix as well as the parent prefix at this point in
the hierarchy, and even the border exit id/address. But then we're
pretty much getting into a combined routing protocol and delegation
mechanism exactly as you already indicated.
> as well as the external route advertisements, we could use that instead.
Right. Why wouldn't a border router have a global address if it is
connected to the Internet?
Am I missing something?
> it would certainly make the routing tables more clearer and more explicit.
And possibly converge faster too on local topology changes.
> that would be a big win, but I don't quite see how you avoid the hard link?
Thinking about this some more, it's specifically the requirement to
select and modify a single IGP that is bothering me. That seems to make
a big assumption about the autoconfiguration mechanism that we have yet
to choose.

Although that in the end modified OSPFv3 might be the best overall
solution, it would seem to me easier and more correct to say that the
prefix autoconfiguration mechanism should distribute the SADR
information, as the Homenet BR anyway has to initiate the prefix
delegation and provide the necessary Homenet BR egress information.

The SADR specific information would to my mind be more tightly coupled
to changes in prefix delegation from the upstream provider, or
availability of the upstream provider link, and not directly with any
local routing protocol or topology change. We're not planning on running
OSPF to providers' PE routers...
> given that border routers may or may not advertise a default route, and may also advertise
True. My assumption is that the 99% use case will be a simple default
route to "the Internet." That could be incorrect.

What's the use case behind more specific routes (in the walled garden)?

What would be so bad in the case of a walled garden if we always
installed a default SADR route associated with the prefix learned
specifically from the walled garden i.e.
(walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR?

We've anyway still got to sort out correct source address selection even
once we've got the basic packet routing in place. Source address
selection   could be the point where the real "routing" decision is
made, whilst SADR would be used to select the correct Homenet BR and to
avoid the ingress filters once the correct source address has been decided.

regards,
RayH
>
> cheers,
> Ole
> Ray Hunter <mailto:[email-masked]>
> 20 February 2013 08:46
> ------------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2013 14:58:18 +0100

Ray,

thinking out loud.

the border router includes in the advertisement of the aggregate prefix:
 - it's own global IPv6 address
 - list of external routes

each internal router:
 - installs (S,D) routes for all of the external routes with the border's global as next-hop.

normal unicast routing is used to get to the border.

yep, that should work too. and be completely independent of routing protocol. but at the cost of being dependent on the prefix assignment mechanism. leaving the question open I suppose, does SADR have a wider applicability outside of the home network...

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Feb 2013 00:12:43 +0900

> normal unicast routing is used to get to the border.

This is what is done in network backbones with next-hop-self. That requires
that you can do recursive loopbacks and that the border router's IP address
is stable - i.e., if it's a loopback address.

---

From: Mattia Rossi <[email-masked]>
Date: Wed, 20 Feb 2013 17:49:40 +0100

> (walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR?
True, generally it seems to me, that more specific routes are only 
needed in the case the Source Prefix in SADR is *.
Otherwise the route is constrained by the source address anyway.
The walled garden route is needed though, if the table looks like this:

     (*, ::/0) -> ISP_A          # Default route to ISP A
     (*, ::/0) -> ISP_B          # Default route to ISP B
     (*, 2001:db8::/64) -> R1                # Internal network, prefix from A
     (*, 2001:db8:1::/64) -> R2              # Internal network, prefix from A
     (*, 2001:db9::/64) -> R1                # Internal network, prefix from B
     (*, 2001:db9:1::/64) -> R2              # Internal network, prefix from B
     (*, fd00::/64) -> R3                    # Internal network ULA
     (2001:db9::/56, 2001:420::/32) -> ISP_B # Walled garden route from ISP B

Maybe that should be listed as an example as well. And maybe a line 
about how to  behave if there's a tie with the multiple default route 
constellation:

     (*, ::/0) -> ISP_A          # Default route to ISP A
     (*, ::/0) -> ISP_B          # Default route to ISP B

If we don't propose a solution , we should add a line which says that 
it's up to the implementation or load balancing mechanism or whatever to 
solve that, like:

    A router forwarding a packet does a longest match look-up on the
    destination address.  If this is a (*, D) entry, it forwards the
    packet out the best next-hop as before (doing equal cost multi path
    load balancing etc). This applies also to multiple (*, ::/0) entries.

> avoid the ingress filters once the correct source address has been decided.

The hosts could perform NAT upon receipt of the ICMP code 5. Of course, 
if you have a low power device then you might have a problem... just a 
thought.

I like the draft and find it very useful.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Feb 2013 21:30:30 +0100

> 20 February 2013 14:58
> yep, that should work too. and be completely independent of routing
> protocol.
Agreed.
> but at the cost of being dependent on the prefix assignment mechanism.
True. Which anyway has still to be solved for Homenet.
> leaving the question open I suppose, does SADR have a wider
> applicability outside of the home network...
>
Almost certainly, if you believe in stateful firewalls, and multiple
alternate paths, but do not want to deploy either NAT66 or rfc6296
Network Prefix Translation (to guarantee a symmetric return path).

You could consider an approach like the CIDR RFC, split into 3 topics:
1) Semantics of making a forwarding decision given a SADR table
2) Considerations for (routing) protocols that maintain the SADR table
3) Homenet specific solution (potentially tied to prefix autoconfiguration)
> 20 February 2013 11:06