[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Not moving the problem to the global mapping system
Short version: Brian's strawman criteria and the current
A note about LISP-ALT having a form of
push added, by which ETRs would solicit
a mapping request from ITRs which are
sending them traffic packets.
I will discuss your comments on the Ivip business model in a
separate thread: "Ivip business models: fast push & OITRDs".
Here I discuss the limitations I perceive in Brian's "strawman"
> I think your complaint stems from the fact that Brian did
> not include any metric of (non-monetary) update cost in his
It was more than that - his text:
> The update rate in the mapping system should be at least
> two orders of magnitude less than the update rate in
> the BGP4 system, at any point in time.
would require a future map-encap scheme's mapping update rate to be
less than 1% of the current rate of updates (however measured) in
BGP. Yet, we want the map-encap scheme to support potentially
billions of separately mapped slices of address space.
This seems overly restrictive from several perspectives, including.
1 - The rate of mapping updates must be minimised because they
inherently impose burdens on people who do not benefit
2 - The cost to participant devices or operators in the mapping
system of each update is comparable to the cost of a BGP
As I tried to indicate in a previous message, point 1 doesn't apply,
or applies to a much lesser degree, to Ivip, since the organisations
which collectively run most of the fast push scheme will be paying
for that system by collecting a fee per update from end-users.
Regarding point 2, I think that for all the map-encap schemes and
especially for Ivip, the cost per any one device which handles a
mapping update - or handles a mapped micronet in its memory - should
be less than the cost per update or BGP advertised prefix in DFZ
> We must have /some/ constraint on mapping updates -- no matter how
> little processing a single Ivip mapping update requires, its
> (non-monetary) cost is still non-zero.
> Ivip is unique among the proposals, as you mention, in the
> following way: all other proposals intend to guarantee either
> fewer pushed mapping updates compared to BGP, or pull-only updates
> /by design/.
OK - here is my pernickety analysis of your statement and of how
Brian's criteria applies to the current map-encap proposals:
LISP-NERD - pure push.
Fewer updates than BGP for a given number of prefixes, due
to ITRs doing their own reachability detection and making
their own multihoming service restoration based on the
options provided in the mapping data. Likewise the ITRs
doing their own TE work, rather than having the end-user
do it via changed mapping data (Ivip) or changing the
advertisement of the prefix (current BGP practice).
I am not convinced this would result in the factor of 100
drop Brian is seeking. For that to be the case, it would
need to be shown that at least 99% of current BGP updates
were purely related to multihoming service restoration and
TE, not to permanent, planned, inevitable changes in where
prefixes are advertised. It would also need to be shown
that the alternative ETR addresses contained in the mapping
data were generally adequate to cope with all outages. If
not, then the end-users would hurriedly create new mapping
to cope with some fault condition they had not fully
anticipated. Then it would need to be shown that the rate
of end-users changing their mapping, in order to fine-tune
TE or how their multihomed service would be restored, would
be so low that Brian's ambitious goal could be achieved.
However, as a LISP-NERD system grew to have more mapped
prefixes than BGP's current 250k, I am sure the absolute
number of updates would rise beyond current BGP levels.
So I can't imagine how a successful LISP-NERD system -
successful due to providing many more end-user networks
with MH and TE than the BGP system currently does - could
meet Brian's factor of 100 reduction requirement.
While the 100:1 goal probably couldn't be met, I think that
for a given number of prefixes or end-user networks,
LISP-NERD would reduce the number of updates compared to
handling them via current BGP techniques.
LISP-ALT - pure pull.
I am not sure how Brian's criteria would apply to ALT,
because there is no push and so no updates to measure.
ETRs can change their mapping as frequently as they
like and no-one would notice, unless by asking for
the same mapping repeatedly and noting any changes in
In the Friday 14 March RRG meeting, I recorded the audio
live (it is not archived at:
and Dino was discussing a way by which ETRs currently
receiving tunneled traffic packets from ITRs could send back
new mapping data to ITRs, so providing a form of real-time
"Notify" system, unconstrained by caching times of ITRs,
which scales well and which does not burden the ALT network
itself. I think this would be done by the ETR asking the
ITR to request fresh mapping. My recording cut out for
reasons unknown in the middle of this. This would not be as
effective as Ivip's push and Notify system, since the LISP
approach assumes that the ITRs can communicate with ETRs
which have the updated mapping, assumes a high level of
coordination amongst disparate ETRs in a fault situation,
and assumes the ITR can securely and reliably decide to
use the updated mapping.
Brian's criteria doesn't seem to capture this kind of
mapping change - and it only applies to the ITRs which
are currently sending traffic to the ETRs in question.
LISP-ALT meets your proposal due to it being pure pull -
but what of this proposed extension to have ETRs send
fresh mapping to some ITRs?
APT - slow hybrid push-pull
Brian's criteria clearly applies to the flooding push
part of APT - from wherever the updates arise (any
Default Mapper or from some other sources in APT ISP
networks?) to every Default Mapper in the APT island.
As with NERD, to achieve this 100:1 reduction
for a fixed number of end-user networks seems
pretty challenging, and seems impossible if the
APT system grows to cope with millions or billions
of end-user networks.
Brian's criteria takes no account of the number of
network elements partaking in the transfer of mapping
changes. With BGP it is the DFZ routers - and we
only have a rough guess of how many there are: 123k
or most likely more.
However, with APT, the number of participating
Default Mappers, or whatever other devices are involved
in flooding mapping updates across the APT island,
is likely to be a different number than this. I guess
it is less, but maybe not.
As with LISP-NERD, I expect that for a given number of
prefixes or end-user networks, APT would result in a
lower number of updates than would occur with current BGP
Ivip - fast hybrid push-pull
Fast push of mapping messages which are simpler and
therefore shorter than in all the other proposals.
Participating devices handle updates generally much more
efficiently than BGP routers do.
As argued earlier, Brian's criteria doesn't seem well
suited to the costs and benefits of Ivip, and Ivip's
update rate will not meet the 100:1 reduction goal.
TRRP - pure pull
(Though Bill Herrin has two approaches to a "Notify" system
- pushing updates towards where they are needed, or at
least causing ITRs which need them to ask for updated
mapping - I am not convinced these approaches are
Similar to LISP-ALT. The authoritative query servers (ETRs
in ALT and DNS servers in TRRP) can update their mapping as
frequently as they like without it being measurable in any
ordinary sense, or being a burden on anyone. So Brian's
criteria does not seem to apply in any practical sense to
TRRP or LISP-ALT.
To the extent it is a pure pull system, it meets your
criteria. However, as with LISP-ALT, there are proposals
to add a directed form of push, so this wouldn't fit into
your criteria, and any such push of mapping changes would
be measurable and important under Brian's criteria,
although it would only involve a subset of the whole system.
to unsubscribe send a message to firstname.lastname@example.org 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