Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels

> I am borrowing from LISP the concepts of the Ingress Tunnel Router
> (ITR), the Egress Tunnel Router (ETR), the IP-in-IP tunnelling of
> packets from ITR to ETR and ETRs being either border routers or
> internal routers.  I assume a centralised database of information
> which determines how a packet's destination IP address controls the
> packet being encapsulated to be sent to a specific ETR address.  I
> assume all the ITRs have a full up-to-date copy of this database,
> via some chained or tree-structured, real-time, "push" update system.

Can you tell me what is different here than LISP plus the use of NERD?

> The ITR functions in this scheme are performed by "V-routers",
> meaning "Versatile".  In some instances a V-router may also perform
> something like an ETR function, which I will call a TTR
> (Translation Tunnel Router) but that is a separate issue.
>
> The major differences with respect to LISP are:
>
> 1 -  LISP-mapped prefixes and individual IP addresses are not
>      within any prefix which is advertised in the BGP system.
>
>      ViP-mapped prefixes and individual addresses and are always
>      part of a prefix which is advertised in BGP.
>
>
> 2 -  With LISP, the ITRs are always located in edge networks.
>      They may be interior routers or the border routers.  They
>      accept incoming packets on interfaces which are not connected
>      to eBGP peers.
>
>      With ViP, the ITR function is performed by a "V-router" which
>      is always a BGP router.  The V-router may be a border router
>      - single-homed or multi-homed - or a transit router.  If the
>      V-router is a border router, it may accept incoming packets
>      for encapsulation on any of its interfaces: those connecting
>      to eBGP peers and those connecting to internal routers.
>
>      It makes most sense if the V-router ITR function is implemented
>      as part of the workload of a multihomed border router or a
>      transit router.  If this is the case, ViP places all ITRs in
>      the DFZ.
>
>      However, it would be technically possible to have the ITR
>      function performed by a single-homed border router or by
>      specialised router which has only a single interface which
>      connects to a transit router or to any border router.  In
>      principle, the ITR function could be performed by the
>      host which originates the packet, but I intend that the
>      ITR function have a full copy of the global mapping database
>      so this would be extremely costly.

Tell me what is different here than a LISP ITR running on a CE router  
with BGP enabled?

> 3 -  For LISP-mapped addresses to be universally reachable, all
>      edge networks need to implement ITR functions, either at
>      their border router(s) or at one or probably many internal
>      routers.  (Alternatively, edge networks would need to change
>      their routing system to forward all packets not covered by a
>      BGP advertised prefix to some external router which would
>      provide the ITR function.)

Robin, this is LISP 1.5, don't you realize that? In LISP 1.5, when  
EIDs come out of PI space, they cannot be routeable via the BGP  
Internet, so they use another topology that does carry EIDs. This is  
exactly what you are describing above.

>      A ViP-mapped address will be universally reachable as long
>      as there is a single reachable V-router which can receive
>      packets from the original sender and send encapsulated packets
>      to the ETR for this address.

When you say LISP-mapped or ViP-mapped, it is not clear to me if you  
mean "map to" or "map from". Can you please clarify?

> 4 -  Point 3 has a profound effect on how the two proposals may
>      be incrementally deployed.  With LISP, there is a serious
>      and perhaps insurmountable barrier to anyone deciding to
>      connect a host to a LISP-mapped address.  The first people
>      to do this will find their addresses generally unreachable
>      since virtually no edge networks will have upgraded any
>      of their internal or border routers to perform LISP ITR
>      functions.  Why should they?  It is a huge investment to
>      enable communications with a handful of rebels who are
>      voluntarily opting out of the BGP system (albeit for the
>      benefit of humanity).

A LISP site will have to use both PI and PA addresses for some time.  
However, when it uses PI addresses that *will not* be in the core  
routing tables, other sites can reach them only if they are LISP  
enabled. Otherwise, the non-LISP enabled sites will reach the LISP  
site with PA addresses.

So we can still reduce the size of the routing table and arguably  
more-specific injection from other PA blocks.

>      I can't imagine how LISP would ever get off the ground,
>      since early adopters would have extremely patchy
>      connectivity.  No-one would put a crucial service on a
>      LISP-mapped address.  Since all crucial services would
>      be available on ordinary BGP-routed addresses, why should
>      edge networks spend money on a new or upgraded router?

Because they want better control over their ingress traffic flows.  
They need the level of indirection to achieve this.

>      ViP requires no changes in the edge network of the sender.
>      It can be implemented with a single ITR on some BGP router
>      somewhere in the world, and a single ETR in the edge
>      network of the destination host.

Can you explain how ViP works with PI addresses?

> 6 -  Because LISP needs to be a single system, it needs to be

LISP needs to be a single system only when the entire network runs on  
PI addresses. That won't happen for a very long time.

> 7 -  One of the primary benefit of ViP, together with providing
>      reachability from the outset without requiring sending
>      edge networks to do anything, is that there would be a smaller
>      number of ITRs in the system.  These will tend to be bigger
>      than with LISP and will have more intensive work to do.
>
>      I am thinking of direct RAM-based lookup approaches, involving
>      two or so memory cycles, to speed this operation in hardware.
>      Perhaps one or more models of current high-end router,
>      such as the CRS-1, could perform these functions nicely,
>      with an extensive firmware upgrade.
>
>
> 8 -  With ViP, packets to be encapsulated reach the edge of the
>      BGP system or are forwarded within it, either to a single
>      ITR (if the ViP system only has one V-router) or to one
>      of multiple ITR functions in separate V-routers all of
>      which have the same IP address.

Do you actually think a few ITRs is going to handle the load of the  
Internet?

>
>      ViP uses Anycast to provide multiple redundant paths
>      within the BGP system for packets to find their way to
>      an ITR.  Anycast is not normally used for TCP
>      communications, but I am hoping it will be appropriate
>      here, since the individual ITRs only encapsulate the
>      packet and tunnel it to the ETR.

I have actually tested LISP using anycast addresses and it has the  
same property. If ITRs have the following mapping cached: {0.0.0.0/0,  
1.1.1.1, 2.2.2.2} where 1.1.1.1 and 2.2.2.2 are anycast addresses,  
you can have various ITRs use the closest ETRs based on the above  
locator addresses.

In the spec we call these boxes "reencapsulating routers", where the  
anycast box decapsulates and then does a lookup on the inner DA where  
it has a different mapping (a list of locators where the site  
actually is) to reach the site's ETR.

> 9 -  LISP and what I will call "ViP-basic" both have their ETRs
>      in edge networks, or at the border router.  These ETRs must
>      have an interface with an IP address which is reachable via the
>      global BGP system.  These only handle packets one way - from
>      the sender HA to the LISP/ViP-mapped destination address of HB.
>      Packets in the return direction HA <- HB are sent normally,
>      without relying on tunnelling, if the destination HA's address
>      is not LISP/ViP-mapped.  Otherwise, a similar process occurs
>      with the packet being intercepted by an ITR and tunnelled to
>      the ETR which handles HA's address.

This can only work if HA is using a PA address.

> Example of ViP-basic
> --------------------
>
> ASCII Art only works with fixed width fonts:
>
>
>   Edge Network A
>                           [ITR]
> HA---(IR)----(BR1NA)------(VR1)-----(TR2)--(TR4)   Edge Network B
>                     \         \                \
>                      \         \                \        [ETR]
>                       (TR1)----(VR2)---(TR3)---(BR1NB)---(IR)---HB
>                          \             /
>                           \           /
>                          (TR5)----(TR6)
>                                       \
>                                        \           Edge Network C
>                                         \ [ETR]
>                                         (BR1NC)----HC
>                                                \
>                                                 ---HD

I don't understand the benefit of reducing the number of ITRs but  
still maintaining an ETR in each site. You still have to manage the  
ETRs. So the gain is not that great.

> HA's address is 11.11.11.11, which is part of a prefix which is
> advertised in BGP and which is not covered by ViP mapping.
>
> HB's address is 22.22.0.1, which is part of 22.22.0.0/16, which is
> also advertised in BGP and which is ViP-mapped.  The other hosts'
> addresses are:
>
>   HC = 22.22.4.1
>   HD = 22.22.4.2

If this is the example, why do you need ITRs or ETRs at all? If you  
have routeable addresses just move the packets as we do today.

Dino

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram