[rrg] Summary of architectural solution space - Ivip still isn't properly covered

[Robin Whittle]

Hi Bill,

Regarding your 3rd draft:

  http://bill.herrin.us/network/rrgarchitectures.html

and my comments:

 http://www.irtf.org/pipermail/rrg/2008-November/000172.html
 http://www.irtf.org/pipermail/rrg/2008-November/000216.html

I accept that you don't want to go into the differences between
encapsulation and forwarding - however, it does affect some other
things, such as PMTUD and source address filtering.


You wrote in:

  http://www.irtf.org/pipermail/rrg/2008-November/000212.html

     My inclination is that if it's a full push to any of the map
     servers then its a full push system.

     ...

     I'm open to arguments why that viewpoint is wrong.

and I replied (msg 216) that I think this description and its A2b
description doesn't adequately describe Ivip or APT.

I don't see any change in any of the A2 options.  I think APT and
Ivip need a separate description.  I describe them as "hybrid
push-pull" systems.  If you leave your page as it is, perhaps you
could add a footnote pointing to this message in the archives saying
that I think some further descriptions are needed to cover Ivip, at
least:

   A2d.  GUIDs dynamically mapped to each RLOC are pushed towards a
         central or distributed registry as they change. The registry
         pushes all incremental changes in near-real time to all
         full database query servers in ISP and/or end-user networks.
         The encoders (ITRs) request mapping from these local
         query servers.  The response has a caching time and the
         local query server will push any changed mapping to an
         encoder if it receives such a change for mapping which
         matches a recent query which is still within its caching
         time.  There may be one or more full database query
         servers in each ISP and there may be one or more layers of
         caching query servers between these and the encoders.


Likewise, I see no change in the A3 section.  To encompass Ivip, I
think something like this needs to be added:

    A3c. End-user networks are responsible for controlling the
         mapping of their EID address space.  Each EID prefix -
         in the case of Ivip, not necessarily a prefix, since it
         can be one or more contiguous IPv4 addresses or IPv6
         /64s - is mapped to a single RLOC address.   For reasons
         such as a link failure, to implement inbound Traffic
         Engineering, or to implement address portability when
         moving to another ISP, the end-user network causes
         the mapping to change to the new RLOC address, and this
         is conveyed to all full database query servers in
         near real time.  These push the changes to any encoders
         (ITRs) which may need them, based on previous queries and
         the caching times of the responses.


I understand you don't consider OITRDs and PTRs as part of the
architecture, but I think they are an essential element of Ivip and
LISP which is not covered in your page at present.

I don't see any changes in the A4 descriptions.

I wrote that A4d is a good description of Ivip's approach to PMTUD
problems:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

On second thoughts, A4d is not a good description at all.

Here is an attempt at describing Ivip's "IPTM: ITR Probes Tunnel MTU"
approach.

   A4f. The encoder encapsulates all packets which are short enough
        that once encapsulated, they will be no longer than some
        constant N, where it is assured that the MTU between all
        encoders (ITRs) and ETRs is at least N.  Longer packets
        are either encapsulated and sent, or rejected with a
        packet too big message, depending on how their length
        if encapsulated, compares to two variables the encoder
        maintains for each particular RLOC (ETR) address.  The
        encapsulated packets function as probes, and depending
        on whether the encoder receives PTBs for them, it
        adjusts its two variables.  These represent the
        encoders upper and lower limits to its uncertainty about
        the true MTU to this RLOC.

That is about as good a description as I can think of without making
it a lot longer.  It is a complex thing to do, but I think it will work.

Your description doesn't cover Ivip's two forwarding modes:

  ETR Address Forwarding (EAF) - for IPv4
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw

  Prefix Label Forwarding (PLF) - for IPv6
  http://www.firstpr.com.au/ip/ivip/ivip6/

Here is an attempt to do so:

  A4g  For IPv4, all DFZ and some internal routers are upgraded
       so that an alternative format of IPv4 header can be used.
       The "Evil bit" is set to 1 and 30 bits of the RLOC address
       is encoded into the header, with routers forwarding
       the packet according to that address, rather than the
       destination address.  The ETR restores the header and
       forwards the packet to the end-user network.  This involves
       no encapsulation overhead or PMTUD problems, but
       fragmentable packets longer than a certain length are
       dropped by the encoder.

BTW, I think dropping overly long fragmentable packets is just fine -
applications have had more than a decade to get over burdening the
network with fragmenting their too long packets.


  A4h  For IPv6, all DFZ routers are upgraded to recognise an
       alternative format of the IPv6 header in which 19 or
       20 bits are used to determine the packet's forwarding.
       These bits map to a predefined set of advertised prefixes
       of ISP networks, and so the packet is delivered across the
       DFZ, to a border router of the correct ISP network, without
       PMTUD problems.  If there is more than one ETR at that
       network, a second lookup will be required and a similar, or
       different, mechanism internal to the ISP network will be
       required to forward the packet to the correct ETR.


Here are some comments on your summary of the major criticisms of the
various approaches to Strategy A:

*  There don't appear to be any genuinely clean ways of implementing
*  strategy A. Handling path-MTU is a problem since the packets in
*  the core are different than the origin host would recognize.

This doesn't apply to the two forwarding approaches.  I know it is
radical to suggest altering DFZ routers, but maybe it is not so hard
to do.  The IPv4 approach only concerns the FIB, and the IPv6
approach also involves the RIB to a certain extent.  AFAIK, these
could be done with firmware upgrades.  There is no change at all to
the BGP implementation.   Maybe this would be easier than trying to
develop and deploy the more complex ITRs required to handle the PMTUD
problems.

*  Extra bandwidth is consumed by the ITR figuring out whether the
*  ETR is still available and functioning.

This doesn't apply to Ivip, since the ITRs don't do any reachability
testing.  The end-user network typically would hire a specialised
company to continually probe reachability of its network via all the
ETRs, and to update the mapping accordingly, but that is an entirely
user-selectable burden of probing, and it does not affect ITRs.

*  Border filtering of source addresses becomes problematic.  It's a
*  mess.

I think this is a fair description of LISP, APT and TRRP.

This is not so with Ivip's forwarding approaches - the filtering
happens normally and naturally with those.

Nor is it a problem with Ivip's encapsulation approach of using the
sending host's address as the source address of the encapsulation
header (LISP, APT and I guess TRRP use the ITR's address as the outer
source address).  Ivip's approach of:

  1 - Outer source address = sending host's address.

  2 - ETRs drop any packet where the inner source address does not
      match the outer source address.

solves the problem neatly.  The ISP's border routers carry on as
usual, rejecting packets with a source address matching a list of
internal addresses.  There's nothing more to do.

When, as with LISP, APT and TRRP, the outer source address is that of
the ITR, then the only way of implementing this source address
filtering is to implement it at every ETR.  This would be extremely
expensive and unwieldy, since there might be a large number of ETRs
this list has to be sent to - and because the only fast way to do the
filtering is with hardware (TCAM?), or a rather large lookup table in
RAM.

*  Deployment may require heavy weight "for the public good" relays
*  in the non-upgraded part of the Internet to facilitate migration.

This doesn't match Ivip's OITRD business model at all.  They would be
paid for by the organisation who has the MAB (Mapped Address Block)
which they split up into smaller spaces and rent to end-user networks.

  Business incentives for LISP PTRs and Ivip OITRDs
  http://psg.com/lists/rrg/2008/msg02021.html


I think it would be helpful to include pointers to actual proposals.
 I understand you want to use a more generalised language to describe
the various proposals, but for the benefit of anyone who is not
totally up with RRG discussions (or who is, but is tired), I think it
would help to have such pointers.

I haven't yet read the Strategies B to F.


   - Robin