Re: [RRG] Separation vs. Elimination

[Michael Meisel <meisel@cs.ucla.edu>]

Hi Robin,

Robin Whittle wrote:
> Hi Michael,
> 
> I am perplexed that you don't consider Ivip to be a member of the
> class of solutions known as "Separation" - the class of "core-edge
> separation" schemes.
> 
> You wrote:
> 
>>> It doesn't matter that Ivip has a faster mapping system which
>>> enables simpler mapping data and simpler ITRs and ETRs, or that it
>>> is not intended to prevent edge devices from sending packets to
>>> devices in the "core".
>> I think the Ivip mapping system is exactly the part that doesn't fit. We
>> feel strongly that we need to make a technical argument (not an economic
>> one) as to why we aren't just moving the problem to the mapping system.
>> Ivip has the only mapping system that proactively pushes mapping updates
>> through the core.
> 
> I don't see how these issues affect the question of whether Ivip is
> a core-edge separation scheme.  I attest it is.

Sorry, I guess I wasn't clear on what my point was -- I definitely and
wholeheartedly agree that Ivip is a separation scheme. =) The reasoning
above was just to explain why the differences in the Ivip mapping system
would have made it somewhat contradictory to mention Ivip as an example
in the HotNets paper.

> LISP, APT, Ivip and TRRP all move the problem to the mapping system
> - and to ITRs and ETRs etc.  But we are crafting the new mechanisms
> to scale to much larger numbers of end-user prefixed (EIDs for LISP
> and APT - I call them "micronets") then the global BGP system can
> handle.
> 
> In addition, with Ivip, I intend there to be business arrangements
> so that end-users pay for their use of the mapping system.  This
> means the whole thing can be run profitably and agreeably, scaling
> to very large usage rates, since each mapping changes generates
> revenue - rather than there being some end-users burdening other
> parties with rates of updates which the other parties consider
> unreasonable.   I wouldn't claim that every part of the entire
> mapping distribution system is necessarily covered like this, but
> most of the top end would be - not the tail ends of the Replicator
> system and the full database query servers themselves.
> 
> 
>> Ivip has the only mapping system that proactively pushes mapping
>> updates through the core.
> 
> I disagree.
> 
> APT and Ivip are the most similar proposals, in my view.  They are
> both hybrid push-pull systems.  In both APT and Ivip, the full
> mapping data is pushed to full-database query servers - Default
> Mappers for APT.  For both APT and Ivip these local full database
> query servers provide fast, low-cost, reliable mapping responses.
> 
> This is totally different from the global query server arrangements
> of LISP-CONS, LISP-ALT or TRRP.  (Six/One Router doesn't have any
> particular mapping system yet.)  It is also totally different from
> LISP-NERD's approach of pushing all mapping data to every ITR.

Agreed.

> Ivip pushes the mapping fast and APT pushes it slowly.  Ivip has a
> distributed, but still reasonably centralised, push system which
> fans out to all full database query servers. APT has multiple
> islands, with more diffuse pushing of the updates from multiple
> sources of mapping data within the islands.  (I don't see any
> benefit in APT islands - I think there should be one APT system.)

I think the larger difference between the mapping systems is what I
pointed out below -- the difference in what information is distributed.

Regarding APT, I think you will find that APT islands that are not
physically connected can be logically connected in the next version of
our incremental deployment scheme. However, we can't force ISPs that
don't already have business relationships to create them, so there is
always the (as you say, probably undesirable) possibility of multiple,
disconnected islands.

> Your formal definition of separation is:
> 
>   separating edge networks from the transit core, and engineering a
>   control and management layer in between.
> 
> I attest that Ivip does this.  I see below that you mean more by
> "separation" than I do.

Actually, I don't believe I do -- just a case of miscommunication on my
part.

>  . . .
> 
>>> I was just pointing out that I think that only Ivip and LISP with
>>> PTRs do this robustly.  I think APT's approach isn't so thorough.
>> I guess we have to agree to disagree on this. 
> 
> OK - but I don't understand how APT (with APT islands) can robustly
> support packets from non-upgraded networks when there are two EIDs
> such as /25 or longer, in the one /24, and the two end-user networks
> are using ISPs in different APT islands, in a setting where it is
> impossible to have advertisements for prefixes longer than /24
> propagate across the DFZ.

I assume this is not possible. But that means it provides an incentive
for the separate islands to converge to one. =)

>> Also, keep in mind that  APT is still under active development,
>> particularly in this area.
> 
> I wasn't trying to say that APT could never support packets from
> non-upgraded networks addressed to smaller EIDs - just that with the
> current arrangements, in my understanding, that it can't.
> 
> . . .
> 
>>> OK.  Your paper indicates that Elimination schemes can't support
>>> packets from non-upgraded networks - at least that is my
>>> interpretation of (page 4):
>>>
>>>    Under Elimination, transit networks can do nothing but wait
>>>    for a unanimous action by all the edge networks before the
>>>    routing table begins to scale.
>>>
>>> Perhaps I am reading too much into that statement, but it is
>>> profound benefit of Separation schemes that at least some of them
>>> support packets from non-upgraded networks, compared to none of the
>>> elimination schemes.
>> I think you're reading a bit too much into it. =) We're talking
>> specifically about scaling the routing table here. Of course,
>> non-upgraded networks can still communicate with upgraded networks in an
>> elimination scheme. However, if upgraded networks stop injecting their
>> prefixes into the global routing table, they lose the benefits of
>> multihoming when communicating with non-upgraded networks.
> 
> That is what I mean - with Elimination schemes, there is no way of
> achieving the scalability goals whilst providing multihoming support
> for packets from non-upgraded networks.  So if you want to get
> anyone - or more particularly most end-user networks - to adopt the
> scheme, you must run it in a way that multihoming is supported for
> packets sent from non-upgraded networks.  Then, the only path to
> scalability is to get practically every network to upgrade.  Only
> then can we achieve the scalability goal, by withdrawing the routes
> from the DFZ.
> 
> 
>> So upgraded networks will want to continue to inject their prefixes into
>> the routing table until there are no more non-upgraded networks. So the
>> transit networks' routing tables won't shrink until this happens.
> 
> Precisely - we agree: Elimination schemes are not a suitable
> solution, in part because they could only provide scalability
> benefits after essentially complete adoption during a backwards
> compatible mode of operation for initial adoption, which provides no
> scaling benefits.
> 
> However, it does not follow that all Separation schemes can
> simultaneously achieve scaling benefits while providing multihoming
> and portability support for all packets sent from non-upgraded
> networks.  Hence my mention of what I perceive are the limitations
> of APT and TRRP in this regard.
> 
> 
>>> That said, I think it is important to point out that this problem of
>>> Elimination schemes - the benefits depending on how many other
>>> networks have adopted it - also applies to some Separation scheme.
>>> In particular, any scheme which can't provide multihoming and
>>> portability for packets sent from non-upgraded networks means that
>>> end-users adopting the system only gain usable, robust, complete,
>>> multihoming and portability after all other end-user networks adopt
>>> the system.  Hence my mention of the limitations of APT's support
>>> for packets from non-upgraded networks, of TRRP's preliminary
>>> arrangements for this, and of Six/One Router's inability to do this.
>> First, let me reiterate that we are talking in general about separation
>> schemes in the paper, of course any particular design may or may not be
>> able to achieve all of the possible benefits.
> 
> OK.
> 
>> Second, some separation schemes are not intended for deployment in
>> end-user networks (a.k.a. edge networks) at all. 
> 
> I don't understand this, since your definition is:
> 
>   separating edge networks from the transit core, and engineering a
>   control and management layer in between.
> 
> The edge-network needs to adopt the new system.  They either need
> new address space, for instance if they are currently using PA
> space, or they need to change the way their current PI space is
> administered - or gain new Scalable PI space.   There doesn't
> necessarily have to be actual ITRs and ETRs in the edge networks,
> but the concept of there being edge and ISP networks with or without
> ITRs (or their Six/One Router equivalents) is crucial to the
> operation of the Separation schemes.
> 
> 
>> We are trying to make
>> the point in the paper that transit networks are the ones that need the
>> routing table to scale, and it is possible for transit networks to
>> deploy separation schemes themselves, in theory, in order to directly
>> address that issue. This is not possible for elimination schemes.
> 
> I agree it is not possible for elimination schemes, but I can't
> think how transit networks could deploy any of the current
> separation schemes without involving the end-user networks.  Can you
> give an example?

Sure: APT. APT is deployed by an ISP by turning their border routers
into APT EDRs (or TRs or whatever you want to call them). Customers
outgoing packets are encapped by the ISP, their incoming packets are
decapped by the ISP. If the customer is multihomed, they can ask their
providers to put their TE preferences into the mapping info for their
prefix(es), but that's totally optional.

>>>   separating edge networks from the transit core, and engineering a
>>>   control and management layer in between.
>>>
>>> This doesn't match Ivip if "separation" means preventing edge
>>> networks from sending packets to core addresses - but LISP, TRRP and
>>> Six/One Router don't attempt to do this, and it is debatable whether
>>> APT (eFIT??) could ever robustly achieve this.
>> If your *provider* is encapsulating your packets (as in APT), of course
>> you can't address anything in the *upgraded* transit core. But
>> non-upgraded transit networks are effectively in edge space, so they can
>> still be addressed.
> 
> I would have thought it more correct to say:
> 
>   non-upgraded transit networks are effectively in *core* space, so
>   they can still be addressed.  The Default Mapper has no mapping
>   for any address in a non-upgraded edge network, and to ensure
>   it can be reached from an upgraded edge network, it must forward
>   the packets without encapsulation.
> 
>   (Of course, for hosts in non-upgraded edge networks to be able
>   to send packets to hosts in upgraded edge networks, one or
>   more border routers in the APT island need to advertise either
>   the upgraded edge network's EID prefix, or some other prefix
>   which covers this EID prefix.)
> 
>   Only once all edge networks adopt APT will the core be truly
>   "separated" from all edge networks.

Continuing from where I left off above, all packets that get sent to the
ISP from then on are either already encapped (by another ISP in the same
island), or get encapped by that ISP. Same goes for decap. No non-border
router inside that APT island is directly addressable by devices outside
the island.

>>> If "separation" means removing the edge address space from the core
>>> routing system, then Ivip matches this description just as well as
>>> LISP, APT, TRRP and Six/One Router.  The differences in the mapping
>>> systems are not relevant to the fact that all these systems achieve
>>> this common "separation" goal.
>> See above.
> 
> OK - so your use of the term "Separation" has a very different
> meaning from the way I use it in my assertion that Ivip is a
> "core-edge separation scheme".
> 
> I mean separation in the sense that the end-user address space is
> managed by a separate system from the core, and does not burden the
> core or contribute much or at all to its scaling problem.

I agree. Sorry... all of this confusion is my fault. I didn't mean to
say Ivip isn't a separation scheme -- it definitely is. I just meant to
say that it's mapping system didn't fit some of the constraints we
wanted to place on mapping systems for this paper.

> You mean "separation" in that from an end-user network which adopts
> the scheme, it is physically impossible to send packets to any core
> address.
> 
> I understand this is a goal of APT.  I don't think it is very useful
> - and I think it could only be achieved after 100% adoption by all
> edge networks.
> 
> But if this meaning of "separation" is your criteria, by which you
> correctly exclude Ivip, then I don't understand why you include LISP
> or TRRP.  AFAIK, neither aims to physically separate all the edge
> networks from the core as I understand you aim to do with APT.
>
>>> From what you just wrote, I understand that APT's approach to the
>>> technical limits and unfair costs in the current BGP system is to
>>> reduce the number of BGP advertised prefixes and cope with many more
>>> multihomed and portable end-user EID prefixes by handling these with
>>> a "mapping" system, with ITRs, ETRs, Default Mappers etc.
>> Right.
> 
> OK.
> 
>>> From what you wrote, I understand your solution to the same problems
>>> occurring in the mapping system - overly large numbers of prefixes
>>> and/or updates to the mapping of these prefixes, and the unfair cost
>>> burdens this places on participants in the interdomain routing
>>> system, in this case the ISP in an APT island - is purely a
>>> technical fix.  From that, I guess you mean that the APT mapping
>>> system will be several orders of magnitude more efficient than BGP -
>>> and that there is no arrangement for costs being paid by those who
>>> benefit from the mapping changes, to those who are burdened by these
>>> changes.
>>>
>>> In that case, I think the gains APT would provide - the increased
>>> number of end-user prefixes the Internet will be able to handle
>>> relative to whatever it can handle now - is roughly equivalent to
>>> the extra efficiency with which APT manages mapping changes relative
>>> to the efficiency with which BGP handles changed prefix advertisements.
>>>
>>> I guess you could get one, two or maybe three or four orders of
>>> magnitude out of this.
>> No, it's not an issue of efficiency. BGP and the Ivip mapping system
>> both distribute two types of information: topology information (who is
>> connected to who), and reachability information (which connections are
>> currently working). These two types of information are indistinguishable
>> in these systems.
> 
> OK - though the way BGP's routers handle packets and communicate
> which prefix is advertised by which router is completely different
> from Ivip's arrangement of ITRs, ETRs, query servers and fast-push
> mapping distribution system.
> 
> In both cases, there is a global system which enables packets
> addressed to some prefix to be sent to some router.  Ivip only works
> as an addition to the BGP system.  BGP works on its own.  BGP's
> handling of changes is slow and expensive - and difficult or
> impossible to charge end-users for when they make a change.  Ivip's

Why? Say I'm your customer, and we have a configured BGP session. You
count the number of updates that arrive over that connection per month,
and then charge me per update once a month.

> handling of changes is intended to be much faster and less expensive
> - while also making it easy to charge a small fee per update, a few
> cents for instance.
> 
> 
>> APT only distributes topology information in the mapping system. 
> 
> For each micronet, Ivip's mapping system distributes the address of
> the ETR to which packets addressed to that micronet should be sent
> by every ITR.  It is the responsibility of the end user to change
> the mapping to some other ETR which works if the current ETR is not
> working, or is not connected to their network.  This requires Ivip's
> mapping to be sent out fast - effectively in real-time - and it
> simplifies the ITRs and ETRs and reduces the size of the mapping
> information, since ITRs and ETRs are not involved in testing
> reachability.
> 
> APT, like LISP or TRRP, has mapping information with two or more ETR
> addresses (assuming a multihomed end-user network).
> 
> This mapping information is assumed not to need to be changed very
> much, since APT's push (to the Default Mappers, from which ITRs pull
> the mapping information they need) is slow by comparison to Ivip.
> 
> Consequently, each APT (or LISP or TRRP) ITR (or the ITR's Default
> Mapper) needs to do its own probing of ETRs or use whatever
> techniques to determine ETR reachability - then the ITRs (actually,
> I think it is APT's DMs) need to make their decisions, based on the
> mapping information, which ETR to tunnel the packets to.
> 
> 
>> So the
>> increased number of edge prefixes that an APT-based network can handle
>> is relative to the (increasing) amount of BGP traffic that is due to
>> reachability changes in edge prefixes.
> 
> Are you saying that a major efficiency - that is, scaling -
> advantage of APT is that it doesn't convey reachability information?
>
> Assuming this is the case, then I see it is true to this extent:
> Your mapping doesn't need to be pushed as fast or as frequently as
> Ivip's, or as fast or frequently as BGP would ideally propagate its
> changes.

Yes, exactly!

> No-one else has drawn parallels between Ivip and BGP - so this is
> interesting.  Clearly they are completely different, and Ivip
> assumes a core routing system - BGP.  However, they are alike in
> that both are in a hurry to communicate "reachability" information
> across the Net.
> 
> Every time a BGP prefix is advertised, or no-longer advertised at a
> given router, changes to this effect need to be propagated.  The
> changes may not need to go very far, or they may involve changing
> the best path decision of every router in the DFZ.
> 
> Every time an Ivip micronet is mapped to some ETR, or not mapped to
> it (typically it would simply be mapped to another ETR, but it could
> be mapped to NULL, or its space could be reassigned to one or more
> different micronets), the Ivip system needs to convey this quickly
> to every full database query server.  (And to any full database ITR,
> but my current thinking is that there will be few or none of these -
> just caching ITRs, some of which have a full database query server
> integrated into them, or have one in the same rack.)
> 
> APT is not in a hurry to push mapping information to all the
> island's Default Mappers.
> 
> Being not in a hurry is arguably a scaling benefit, as is not having
> to push the mapping very often.  However, one extra cost (compared
> to Ivip) is that APT needs to push more complex, more voluminous,
> mapping information.  Another major extra cost your ITRs/DMs and
> ETRs need to be much more complex than Ivip's because they must do
> all the reachability testing and multihoming service restoration
> decision making.

This is all true. But we argue this is necessary complexity. The
Internet is a complex system. I think it was Einstein that said: as
simple as possible, but no simpler.

>>> The Ivip approach is to provide firstly a more efficient mapping
>>> system relative to BGP - as does APT - but also to technically
>>> structure the mapping system so end-users can be made to pay for
>>> each mapping change.  This enables quite a lot of the mapping system
>>> (not all, but most of it) to be run as a series of businesses.  More
>>> details are in:
>>>
>>>   http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01
>>>
>>>
>>> Then, there funding for the mapping system, so there are incentives
>>> to build it, extend it, run it, make it more efficient etc.  This
>>> should greatly extend the maximum number of micronets, updates etc.
>>> the whole system can handle, compared to what I understand is the
>>> APT approach of a more efficient mapping system with costs falling
>>> unfairly on the ISPs, with no backpressure on end-users to reduce
>>> the number of mapping changes or the number of EIDs in the mapping
>>> system.
>> The costs are not falling *unfairly* on the ISPs -- they are the ones
>> that stand to benefit. Again, the primary goal of APT is better routing
>> scalability, which is a DFZ problem.
> 
> But what if an end-user network issued a mapping update every 10
> seconds, 24 hours a day?

Edge networks don't send mapping updates directly under APT. ISPs send
mapping updates that contain their customers' prefixes. We also plan to
have the protocol limit the frequency of updates to something on the
order of (very roughly) once per hour. Because we don't carry
reachability information, there is no need for frequent updates. We're
currently working on some simulations to see exactly what time scale is
workable.

> That would be as much of a burden on the ISPs in the APT island as
> hundreds of thousands of ordinary end-user networks which only
> changed their mapping every month or so.  (In terms of mapping
> traffic and processing it at each DM.  In terms of storage, the
> burden is the same.)
> 
> In this respect, APT achieves no benefits over BGP.  Both APT and
> BGP have to accept the arguably excessively frequent changes and
> propagate them - and in both cases there is no way of charging the
> originator of these changes to help deter them from making so many,
> or to help pay for their cost across all the ISPs.
> 
> Ivip is completely different in this regard - there will be a small
> fee per update.

Yes, our solution is technical (frequent updates are not necessary for
desired functionality), yours is economic (frequent updates are
necessary, but can be costly). The way I see it, we are technicians, not
policy makers, so I don't see how an economic solution is enforceable.

> So I think APT continues this problem of having to propagate
> end-user initiated changes across many devices, without a fee.  This
> is what bedevils BGP - and is a significant part of the the heart of
> the routing scaling problem.
>
>> I suspect you will have a lot to say on this, so perhaps it should be
>> moved to a separate thread, but I am curious: in regards to your
>> economic model, what is stopping an ISP from charging their BGP-speaking
>> customer for each BGP update today?
> 
> Other folks on the list would have a better idea of this, but I
> think the current BGP system relies on trust and unsecured
> announcements.  To put up some kind of fence, administered in some
> way to reject updates from networks which don't in fact pay a fee
> per update, would require a major upgrade to all participating
> routers.  It would require some pretty fancy security arrangement
> and my guess is that it is all too much of a headache.  It would
> also require some kind of organisation, accounting system, and
> presumably some way of distributing monies to help ISPs pay for
> bigger DFZ routers.

I was trying to say that you could charge edge networks for sending BGP
updates to their providers, not charge in the core. As we've discussed,
this is where most of the updates originate. These BGP connections are
manually configured, and, AFAIK, generally need to match up with the
physical connection that the customer's data flows across. So it seems
to me that's pretty hard to fake.

> I figure it could be done.  If this was all that was required to fix
> the routing scaling problem, I think people would be working on it.
> 
> However, it doesn't alter the fact that the BGP system can't
> reasonably be expected to scale to as many prefixes as there are
> end-user networks which need portability and multihoming.
> 
> Fees for each BGP prefix and for each updates would help deter those
> who advertise and change their advertisement of prefixes for
> arguably spurious reasons, so it would marginally reduce the scaling
> problem.  However it wouldn't solve the scaling problem assuming we
> want to have 10 million, 100 million or whatever end-user networks
> with portable, multihomable address space.

So, if I am understanding correctly, your claim is the following: Ivip
solves routing scalability by (a) proactively distributing the same edge
network topology and reachability information as BGP, except more
efficiently, and (b) enforcing a charge per update?

>>>>> Your description:
>>>>>
>>>>>    LISP-CONS and LISP-ALT build a DNS-like hierarchical overlay to
>>>>>    retrieve mapping data when needed.
>>>>>
>>>>> strikes me as wrong.  Neither has much resemblance to DNS.  ALT is a
>>>>> completely separate network, with its own BGP instance, using a
>>>>> different but parallel address space, for sending mapping queries,
>>>>> which are typically actually traffic packets.  The responses
>>>>> typically come back via the ordinary Internet, rather then the ALT
>>>>> network.  LISP-CONS is no longer being developed, as far as I know.
>>>> Protocols aside, they seem quite similar to me -- in both cases, you
>>>> query a hierarchy of servers, eventually getting the information you
>>>> requested directly from the authoritative source. The major difference
>>>> is that DNS queries start at the root of the tree directly, whereas
>>>> LISP-ALT queries start at a leaf before ascending to the root.
>>> There are other differences which I consider significant, such as
>>> the ALT network being a completely separate network, with routers,
>>> BGP, tunnels etc.  I think these differences are such that
>>> "DNS-like" is an inadequate description.
>>>
>>> For instance, DNS queries go straight to the relevant server, via
>>> the Internet.  There often needs to be a query to one server in
>>> order to find the address of another server to send a second query to.
>>>
>>> In the ALT system, a single query gets to the appropriate server -
>>> there is no recursion.
>> I think you mean, there is *only* recursion, in the sense of recursive
>> DNS queries.
> 
> 
> I mean "no recursion".
> 
> My understanding of ALT is that an ITR makes a query to some remote
> query server it has no idea the location or Internet address of.
> The query is typically the initial traffic packet for some EID
> prefix for which it currently has no mapping.
> 
> It pops the packet into the ALT network, encapsulating it with a
> LISP header with the ITR's address as the source address and the
> initial packet's destination address as the destination address.
> 
> The ALT network's address is the same range of numbers as the
> Internet's range (eg. the IPv4 ALT network has 0.0.0.0 to
> 255.255.255.255) but the routers in the network use these addresses
> completely independently from any address those routers might have
> on the Internet.
> 
> The ALT routers are linked by tunnels in the Internet.
> 
> Each ALT router aggregates some number of ALT routers below it.  The
> packet is passed along these tunnels and routers, just as if it was
> on the Internet, but this is a different network.  The packet's
> destination address - the destination host EID address, ensures it
> is forwarded to the authoritative query server for this EID.  I
> understand this is typically an ETR, but it need not be.  This ETR
> sends back the mapping reply directly via the ordinary Internet
> (which is much faster and more direct than sending it back by the
> ALT network).
> 
> There is no recursion.  It is a conceptually neat scheme -
> delivering the initial packet to the ETR even when the ITR doesn't
> have mapping information (the ETR's address) - and at same time
> having this constitute a mapping request.  (APT has something
> similar in a faster, local manner with the ITR sending packets to
> DMs and getting a mapping reply in return.)
> 
> However, it is a global query server system, which I think is a
> really bad idea in terms of delay and reliability.  Worse still, the
> physical paths likely to be traversed by query packets will often be
> geographically much longer than the shortest geographical path.
> 
> LISP-ALT has no concept of recursion, as far as I know.

Ok, I see what you mean.

>>> Also the query typically is the traffic
>>> packet, so the ALT system functions as an early delivery system,
>>> before the ITR has the mapping for this packet's EID prefix.
>>> Another difference is that there is this whole new network, with its
>>> own BGP system (scaling problems in that too?).  The physical
>>> location of the various routers in this system is likely to be
>>> scattered all over the world, and the "highly aggregated" nature of
>>> the ALT system leads to packets likely cris-crossing continents and
>>> oceans as they traverse from source leaf and branch to trunk and
>>> then to destination branch and leaf.
>>>
>>>   http://psg.com/lists/rrg/2008/msg00229.html
>>>   http://www.antd.nist.gov/~ksriram/strong_aggregation.png
>>>
>>> I think that to call this "DNS-like" would give readers a
>>> way-to-simple impression of LISP-ALT and its likely problems.
>> Of course, a one-word description is necessarily way too simple. But
>> this was only a six page paper, and explaining LISP-ALT is tangential to
>> our point, so we couldn't do much better. I agree with you that LISP-ALT
>> has many problems that DNS does not.
> 
> Yes . . . 6 pages:
> 
>   http://conferences.sigcomm.org/hotnets/2008/cfp.html
> 
> is not much if you have something complex to write about.
> 
> Still, I think that it is misleading to describe LISP-ALT as "DNS-like".
> 
> . . .
> 
>> Notice the title of the slide: "What about Multipath ROUTING?" Our paper
>> is talking about Multipath TRANSPORT, as are the rest of Mark's slides.
>> Multipath TRANSPORT doesn't involve the routing system at all.
> 
> Thanks - I roughly figured out this distinction after I wrote my
> last message.
> 
> 
>>> Anyway, in your paper, it might be good to cite prior work on the
>>> multipath approach you illustrate in section 5.
>> If you mean the combination of multipath transport with separation, as
>> illustrated, this is an original contribution, there is (AFAIK) no prior
>> work.
> 
> OK.
> 
>> If you mean multipath transport in general, see Mark's slides (which you
>> linked to above) and this reference:
>>
>> P. F. Tsuchiya. Efficient and robust policy routing using multiple
>> hierarchical addresses. SIGCOMM Comput. Commun. Rev., 21(4):53–65, 1991.
> 
> OK - the OCR text is available for a fee:
> 
>   http://portal.acm.org/citation.cfm?doid=115992.115999
> 
> 
>>>>> I think what you wrote about failure detection is pertinent:
>>>>>
>>>>>    Being able to effectively gauge the status of
>>>>>    multiple paths requires transmitting a large quantity of
>>>>>    data and sophisticated subflow control; not all applications
>>>>>    can continuously send large quantities of data (e.g.,
>>>>>    VoIP connections), and not all end points are suited to
>>>>>    perform complex control (e.g., small sensors).
>>>>>
>>>>> This critique also applies to ITRs trying to do reachability
>>>>> detection in the non-Ivip core-edge separation schemes.  I discussed
>>>>> this in my recent message to Iljitsch.
>>>> I'm not sure what your basis is for this claim -- in APT, for example,
>>>> one data packet from one ER (a.k.a. ITR) to a failed DR (a.k.a. ETR) is
>>>> generally sufficient to discover the failure.
>>> I think you must be relying on receiving an ICMP message either from
>>> some intermediate router than the ETR is unreachable, or from the
>>> ETR that the destination network is unreachable.
>>>
>>> I don't think that relying on ICMP messages to detect network
>>> failures is robust.  A failed or flaky part of the network can't be
>>> relied upon to do anything, including successfully sending out ICMP
>>> messages for every packet which goes to some router which has its
>>> next hop in the faulty part of the network.
>> No, we don't rely on ICMP in APT. We have our own control messages that
>> are generated and processed at DRs and DMs. I believe the details (at
>> least of previous versions of our failure handling) are described in
>> most (if not all) of the APT-related documents.
> 
> OK - there is a message from the ETR to the DM of the sending
> network that the ETR can't reach the destination network:
> 
>   http://tools.ietf.org/html/draft-jen-apt-01#section-11.4
> 
> If the ETR's unreachability is reflected in its BGP prefix no longer
> being reachable, this is handled in section 6.1.1.
> 
> But what if there is some network failure between the ITR and the
> ETR?  Section 6.1.2 handles this, on the assumption that the ITR can
> send packets to the network in which the ETR resides, and that the
> default mapper there, working with the internal routing system, will
> be able to detect that the ITR sent a packet to the no-longer
> reachable ETR.
> 
> OK - I see how you do this without relying on ICMP messages.  You do
> however rely on:
> 
> 1 -  BGP to tell the sending network's border router, and therefore
>      the ITR, that the ETR's network is unreachable.

As is true in the Internet today.

> 2 -  The DM in the ETRs network to tell the ITR (or the ITR's DM?)
>      that the ETR is unreachable.
> 
> 3 -  The reachable ETR to tell the ITR (or the ITR's DM?) that the
>      destination network is unreachable.
> 
> 
> I think 3 should be OK - and probably 2.
> 
> However, there can be long delays across the Net with BGP
> propagating a notion of unreachability.  The destination network
> could go off the air and nearby routers cancel their advertisements,
> but other routers think their neighbour has a path, and advertise
> that path's length.  This does not necessarily get propagated
> quickly, due to a delays in each router, including if there is a
> flurry of such announcements when a major link dies.  Also, there is
> MRAI path hunting, depending on the structure of the routers.
> 
> http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_hunting_MRAI_disc
> 
> which can delay the propagation of an unreachable condition by ~30
> seconds for however many depths of this process there are.

All of this is true, but APT isn't meant to fix or avoid BGP's problems,
just to limit how much of the network BGP routers have to deal with.

>>>>> Page 5 col 1 para 2
>>>>>
>>>>> I was unable to find any CIRL references - Google equated this with
>>>>> "circle".
>>>> Ah, it seems the URL was accidentally left out of the bibliography. Here
>>>> it is:
>>>>
>>>> http://read.cs.ucla.edu/~frost/cirl/
>>>   CIRL: DDoS mitigation in eFIT
>>>   Chris Frost and Mike Mammarella July 13, 2008
>>>
>>>> Note that this is very much a WiP. We just cited it as a
>>>> proof-of-concept.
>>> Thanks for this link.  I stand by my critique of basing security
>>> responses on the assumption that an encapsulated packet sent to an
>>> ETR was sent via the ITR whose address is in the source address of
>>> the encapsulating header - the attacker can send encapsulated
>>> packets directly, with any ITR address in the outer header.
>>>
>>> In eFIT, perhaps it is impossible for an end-user host to send a
>>> packet to an ETR, in which case my critique would not apply.
>>> However, this is a highly idealised situation in which every
>>> end-user network in the world adopts eFIT-mapped address space and
>>> sits behind a router which refuses to forward any packet from inside
>>> the network to the interdomain core, other than those which are
>>> encapsulated already by ITRs and therefore are addressed to ETR
>>> addresses, which are in the core.
>>>
>>> Still, in that situation, how is the border router to distinguish
>>> between a packet it receives from an ITR inside its network, and an
>>> identical looking packet created in a host controlled by the attacker?
>> The answers to all of this are dependent on both how APT networks handle
>> packets from non-upgraded networks, on the particular DDoS mitigation
>> scheme, and on what (if anything) is done to ensure the authenticity of
>> ITR addresses. These are all works in progress and/or future work, so
>> I'd rather not speculate, except to reiterate that I don't see any of
>> these things as unsurmountable.
> 
> OK - thanks for your detailed reply.  No 6 page limits around here!

Certainly not. =)

-Michael

>   - Robin
> 
> 
> --
> 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

--
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