Re: [RRG] Not moving the problem to the global mapping system

[Robin Whittle <rw@firstpr.com.au>]

Short version:      Brian's strawman criteria and the current
                    map-encap proposals.

                    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.


Hi Michael,

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"
criteria.

You wrote:

> I think your complaint stems from the fact that Brian did
> not include any metric of (non-monetary) update cost in his
> strawman.

It was more than that - his text:

> <strawman>
>
> 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.
>
> </strawman>

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
      from them.

  2 - The cost to participant devices or operators in the mapping
      system of each update is comparable to the cost of a BGP
      update.

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
routers today.


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

I agree.


> 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
        the responses.

        In the Friday 14 March RRG meeting, I recorded the audio
        live (it is not archived at:
        http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf71/)
        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.

        http://www.ops.ietf.org/lists/rrg/2007/msg00253.html
        http://www.ops.ietf.org/lists/rrg/2007/msg00255.html

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


  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
         practical.)

        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.


 - 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