> 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 >>> > ------------------------------------------------------------------------ _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
