[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] How to Incrementally Deploy APT
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 rrg-request@psg.com 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