Hi Ole, Hi Lorenzo,
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. > 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 _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
