[rrg] Enhanced Efficiency - draft critique

[Robin Whittle <[e-mail]>]

No-one has written a critique of:

    Enhanced Efficiency of Mapping Distribution Protocols in
    Map-and-Encap Schemes
    http://www.ietf.org/mail-archive/web/rrg/current/msg05540.html
    K. Sriram, Young-Tak Kim, and Doug Montgomery

http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-13

However some mailing list comments from Dino Farinacci and Brian
Carpenter are listed here:

   http://www.ietf.org/mail-archive/web/rrg/current/msg05694.html

Here is my 854 word draft critique, which I will revise after
feedback from K. Sriram and colleagues.

  - Robin




This submission to the RRG is not for a routing scaling solution, but
was included as a potentially archival contribution to research on
mapping systems for Core-Edge Separation (CES) architectures. (RRG
msg05541, 2009-12-22.)

It concerns two suggestions.  Firstly, more elaborate mapping
arrangements are suggested when one prefix of the "edge" (EID) space
is primarily handled by one ETR, but more specific prefixes within
this are handled by others.  Secondly it hierarchies of ETRs are
suggested, for the purpose of a single ETR aggregating the "edge"
prefixes handled by subsidiary ETRs into a single mapping
announcement.  Both these suggestions involve extra complexity for
marginal gains in scenarios which may only occur infrequently.

A primary purpose of CES architectures is to make "edge" space
portable to any ETR in the world.  While contiguous segments of
"edge" space my indeed be handled by a single ETR, or several
topologically nearby ETRs, it does not appear to be worth introducing
extra complexity into the structure of mapping data to achieve modest
and occasional decreases in the number of items the mapping system
must handle.

In Fig 2, the ITR's request is for a6/24, in a range of "edge" space
mapped in this manner.  The following numbers are those of a
realistic example in which 16 prefixes are numbered 0 to 15, rather
than 1 to 16 as in the proposal paper:

   a0/24 to a6/24:            ETR1
   a7/24:                              ETR3
   a8/24 to a13/24:           ETR1
   a14/24:                         ETR2
   a15/24:                    ETR1

In LISP these 16 /24s could be 16 separate EID prefixes.  Likewise in
Ivip, they could be 16 micronets, each of 256 IPv4 addresses.

The minimal number of EID prefixes in LISP is 8:

    0, 1, 2, 3     = a0/22:  ETR1
    4,  5          = a4/23:  ETR1
    6              = a6/24:  ETR1
    7              = a7/24:            ETR3
    8,  9, 10, 11  = a8/22:  ETR1
   12, 13          = a12/23: ETR1
   14              = a14/24:      ETR2
   15              = a15/24: ETR1

In Ivip, since micronets have arbitrary starting points and lengths,
the minimum number is 5:

    a0.0 to  a6.255:         ETR1
    a7.0 to  a7.255:                   ETR3
    a8.0 to a13.255:         ETR1
   a14.0 to a14.255:              ETR2
   a15.0 to a15.255:         ETR1

The elaboration to the mapping system's data format being considered
is that it should be possible, in a single mapping item, to specify
one prefix with multiple exceptions:

   a0/20                     ETR1
     except for:
     a7/24:                            ETR3
     a14/24:                      ETR2

CES architectures are intended to scale to very large numbers of EIDs
or micronets, including to support potentially billions of mobile
hand-held devices.

The modest reduction in the number of mappings to be handled does not
seem to justify the additional complexity being proposed.  If this
proposal were accepted, then altering a single /24 in the above
example would mean altering the way in which the mapping of other
parts of the "edge" address space are specified.

In the example, ITR1 requests mapping for an address within a6/24
(using the present 0 to 15 numbering system).  The example assumed
that it would be returned all the mapping covering the /20.  But it
is not clear why this should be the case, or what principles would
govern returning more complex and voluminous mapping for the request,
which concerns a single edge address.  In LISP, the map reply should
have been:

    6              = a6/24:  ETR1

and for the minimal mapping example above for Ivip, it should have been:

    a0.0 to  a6.255:          ETR1

Ivip's mapping could be in many arrangements, as could LISP's - but
both Ivip and LISP return a simpler mapping construct than that which
is being proposed - which is highly desirable, since there is no
reason to believe ITR1 would soon need to tunnel packets to any other
"edge" address in the a0/20 range.  In this particular example, the
Ivip reply would cover 7 times as much "edge" space as the LISP
reply.  Map replies in a minimal Ivip mapping arrangement would
frequently cover more addresses than those resulting from a minimal
LISP mapping - and would never return a mapping covering fewer "edge"
IP addresses than with LISP.


The question of ETRs being nested presumes that one ETR can be
reached by ITRs when it is behind one or more other ETRs.  This is
impossible in Ivip and would appear to contradict LISP's requirement
that all ETRs be on "RLOC" ("core") addresses.  To successfully
implement the suggested nesting of ETRs may require greater
complexity in the ETRs and probably nested encapsulation, since the
subsidiary ETRs are presumably on "edge" addresses, as are all
devices "behind" an ETR.

In Figure 3, nested encapsulation would be required for a traffic
packet addressed to a host in z2/24 and there would need to be
additional complexity in ITRs to deliver packets to the correct one
of four destination networks if the traffic packet was addressed to a
host somewhere in y1/22.

Since CES proposals are designed to cope with very large numbers of
mappings for different EID prefixes, micronets or whatever of "edge"
space, it seems that this extra complexity and the reduction in
efficiency due to multiple encapsulations is not justified by the
modest and occasional reduction in the number of mappings the whole
system needs to handle.