David, thanks for the thorough comments.
> nice to see this moving forward! Comments below with section > copy/paste. > > On Mon, Feb 18, 2013 at 10:04:45PM +0100, Ole Troan wrote: >>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt > [...] >>> 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 > >> 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. yes, let me fix that. >> 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.) yes, it is a hack. it would allows us to proceed while waiting for SADR support in routing protocols though. >> 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. yes. > (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. I suppose that requirement applies generally, not only to the simplified variant. > 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. yes, absolutely. cheers, Ole _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
