[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at iab.org
https://www1.ietf.org/mailman/listinfo/ram