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
