On Fri, 2008-02-22 at 23:45 +1100, Robin Whittle wrote: > > I have redrawn your diagram to add ISP5 to the left island. > > ________________ > | APT Island 1 | > | ______ | > | / ISP5 \<=================\ > | \__,___/ | || > | ___/ | || ________________ > | / | BGP __\/__ BGP | APT Island 2 | > | | ______ | Routes / ISP4 \ Routes | ______ | > | | / ISP1 \<===|========>\______/<========|===>/ ISP3 \ | > | | \__,___/ | /\ | \__,___/ | > |_|_____|________| BGP Routes || |_______|________| > | | __\/__ | > \ ___|___ / ISP2 \ ___|___ > / Site1 \ \______/ / Site3 \ > \_______/ /\ \_______/ > BGP Routes || > ___\/__ > / Site2 \ > \_______/ > > > Please let me know if the following statements are true or how > they reflect my faulty understanding of APT. Each statement > tends to assume that the previous ones were true. > > 1 - Site1 can multihome with ETRs in ISP1 and ISP5. > > 2 - Site1 can't multihome with ETRs in any other ISPs, > including ISP3. >
Point #2 is incorrect. Site1 can multihome with ISP3. Perhaps this is your concern; the traffic engineering preferences that Site1 expresses to ISP3(see draft for details) won't apply to ISP1 and ISP5. This is true, since the scope of TE preferences do not extend between APT islands. However, packet delivery works just fine. > 5 - Therefore, APT has very limited flexibility in serving the > needs of end-users who have less than 256 IP addresses, > unless all APT sites join up into a single "APT Island". > This puts APT at a distinct disadvantage compared to LISP or > Ivip, which can handle end-user networks (EID prefixes AKA > micronets) as small as a single IP address, and enable the > end users to use any ETR in any ISP in the world, > irrespective of whether that ISP has ITRs and without any > restriction on which ETRs are used by end-users with > neighbouring micronets, or micronets in the same Mapped > Address Block (BGP advertised prefix containing typically > hundreds or thousands of micronets). > > APT considers edge networks to be on the granularity of ASes that do not show up in the middle of an AS path. Such ASes would have >256 IPs. APT is not designed to allow home users to connect directly to an APT island and have their packets tunneled. Thus you are correct in saying that during APT incremental deployment, a site with a PI prefix longer than /24 will not be reachable outside the island (unless the rest of the /24 is in the island, as you pointed out). Keep in mind that today's Internet does not support this either. You claim that APT is at a disadvantage over LISP or Ivip. Correct me if I'm wrong, but don't these proposals have similar problems during incremental deployment? Let's say that I am a lisp/ivip customer site with 111.111.111.128/25 and 111.111.0.0/16 is being used by a non-upgraded ISP. How would an anycast ITR or a PTR announce my prefix in this case? > 6 - When Site1 uses APT's TE capabilities (I recall this is > part of APT) to load share incoming traffic for its > prefix over the two links from the ETRs of ISP1 and ISP5, > this probably does not mean that packets from Site2 will > be load shared between the two links ISP4-ISP5 and > ISP4-ISP1. More likely, all the traffic will flow from > ISP4 to one of these, say ISP5. > > 7 - This would make it difficult or inefficient for the APT > system to somehow load share the incoming traffic over > the two ETRs, since half the traffic would need to flow > from ISP5 to ISP1. (How would this actually be done?) > > Actually, we wouldn't even expect that ISP5 would forward any traffic for Site1 to ISP1, it would just deliver it directly. Basically, the priorities and weights that APT uses for TE would only apply to senders within the island. There might be some tricks we could play with BGP to get data from ISP4 to go to across the right link based on Site1's preferences, but that may not be advisable -- it will likely make a bit of a mess in the BGP announcements. Note that other proposals have to pick a location in a similar trade-off space. > 8 - If: > > <snip> > > LISP, TRRP and Ivip have no such problem with islands or > long path for packets, since the ordinary BGP system takes > packets directly from the ITR to the ETR, irrespective > of whether the networks those BGP routers are in have any > upgrades for LISP, TRRP or Ivip. > Tell us if we're mis-characterizing your example, but it seems that the larger point you're getting at is this: by removing the intermediate ASes in the APT island from the BGP path, we are providing an opportunity for ISP4 to unwittingly send traffic along an unnecessarily long path. That's absolutely right. However, this seems to us to be fundamentally the same problem faced by LISP PTRs or Ivip anycast ITRs in the core -- the ITR/PTR/BR/whatever becomes a necessary extra hop in the path which may be less than optimal. So we don't agree that other proposals avoid this problem. In fact, APT islands are, first, more realistic since they require some business relationship between parties that encapsulate packets for each other, and, second, are likely to scale better. That is, during early deployment, APT islands will be small, only a few ISPs, meaning that an unnecessarily long path (at least one that could have been detected based on ASPATH length today) is unlikely. Only as APT islands grow larger are very long paths likely to be hidden by our scheme, at which point a smaller portion of the network will be non-APT networks, meaning fewer parties will suffer. Thanks for the comments. They were very insightful. Dan and Michael -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
