> Ole Troan <mailto:otr...@employees.org> > 20 February 2013 14:58 > 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. 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) > cheers, > Ole > Ray Hunter <mailto:v6...@globis.net> > 20 February 2013 11:06 >> Ole Troan <mailto:otr...@employees.org> >> 20 February 2013 09:59 >> Ray, >> >>> 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) >> 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? > 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) >>> 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. >> 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. > 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. >>> 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) >> 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. > 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. >>> 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. >> 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 >> more specifics... > 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:v6...@globis.net> >> 20 February 2013 08:46 >> 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: >>> Begin forwarded message: >>> >>>> From: <internet-dra...@ietf.org> >>>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt >>>> Date: February 18, 2013 22:01:47 GMT+01:00 >>>> To: <o...@cisco.com> >>>> Cc: <lore...@google.com> >>>> 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 <o...@cisco.com>; 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=utral (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=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088" >>>> X-Virus-Scanned: amavisd-new at amsl.com >>>> Content-Type: text/plain; charset=tf-8" >>>> Content-Transfer-Encoding: quoted-printable >>>> X-Test-Idtracker: no >>>> X-Ietf-Idtracker: 4.40 >>>> Message-Id: <20130218210147.7330.45442.idtrac...@ietfa.amsl.com> >>>> Return-Path: internet-dra...@ietf.org >>>> 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 >>>> >> ------------------------------------------------------------------------ > > Ole Troan <mailto:otr...@employees.org> > 20 February 2013 09:59 > Ray, > >> 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) > > 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? > >> 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. > > 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. > >> 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) > > 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. > >> 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. > > 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 > Ray Hunter <mailto:v6...@globis.net> > 20 February 2013 08:46 > 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: >> Begin forwarded message: >> >>> From: <internet-dra...@ietf.org> >>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt >>> Date: February 18, 2013 22:01:47 GMT+01:00 >>> To: <o...@cisco.com> >>> Cc: <lore...@google.com> >>> 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 <o...@cisco.com>; 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=utral (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=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088" >>> X-Virus-Scanned: amavisd-new at amsl.com >>> Content-Type: text/plain; charset=tf-8" >>> Content-Transfer-Encoding: quoted-printable >>> X-Test-Idtracker: no >>> X-Ietf-Idtracker: 4.40 >>> Message-Id: <20130218210147.7330.45442.idtrac...@ietfa.amsl.com> >>> Return-Path: internet-dra...@ietf.org >>> 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 >>> > ------------------------------------------------------------------------ _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
