Short version: A core-edge separation scheme such as LISP
which does not use real-time mapping
distribution to control the behavior of
ITRs therefore needs some way each ITR can
decide which of multiple RLOCs to use.
Attempts to improve this real-time process
include the ETR sending locator reachability
bits and the use of versioning in the mapping
information.
LISP also involves ETRs being the authoritative
source of mapping information. This raises
further technical and administrative questions
about how the ETRs for one end-user network,
which are typically in different ISPs, can work
together securely and reliably, especially at
times of outages and other sources of network
instability.
With a real-time mapping distribution
architecture, as used by Ivip, there is no need
for ITRs to make such decisions - and ETRs can
be much simpler, with no need to communicate
with ITRs at all, and no need for them to be
coordinated in any way. Also, end-user
networks can probe reachability and decide which
ETR will be used, in real time, with any
techniques they like.
Hi Damien,
While I only partially understand this part of LISP, I share your
concerns about ETRs sending real-time reachability information to
ITRs. Even if it was secure (which I understand it is not) there are
all sorts of problems with different ETRs having a different
understanding of the reachability of all the ETRs for a given EID
prefix, and then the ITR receiving multiple differing sets of locator
reachability bits from different ETRs at different times.
Also, I think there is a problem with the bits needing to refer to a
specific order of RLOC addresses, as defined in the complex mapping
data. When the ITR receives a mapping reply with a different order
of RLOCs than the one it has cached, then it can be difficult for an
ITR to know whether the bits it receives relate to the current or to
a previous order of RLOCs.
With LISP, I have no idea how the ETRs of a particular end-user
network are supposed to coordinate their activities so as to be able
to do anything consistent or reliable regarding telling ITRs which
ETRs are currently reachable, or at least which are reachable from
the DFZ and are also connected well (not congested) to the
destination network.
These ETRs are going to be in different ISPs, so how are the ISPs
supposed to configure their ETR to communicate reliably and securely
with ETRs in some other ISP, for every single end-user network which
uses that ETR?
When things are getting rough, with outages, traffic flowing in
different ways to get around the outage, congestion, misconfiguration
etc. how are the ETRs supposed to communicate reliably to work
consistently together?
How are they supposed to decide what the real reachability situation
is? Likewise the mapping information? There might be three ETRs in
different ISPs, each in some way configured by one or more ISPs
and/or in some way controlled by the end-user network in terms of the
mapping information they send out to the APT network (or register
with their respective Map Servers which do this).
But what if ETR-A becomes isolated from the end-user network? The
end-user network might configure (or ask its ISPs to configure) the
other two - ETR-B and ETR-C - with some different mapping
information, such as new RLOCs, deleted RLOCs or rearranged RLOCs.
But ETR-A will not have this new configuration and so will be causing
different mapping and/or different locator reachability bits to be
sent out via the ALT network or to ITRs.
Versioning may be more secure than the ETR sending locator
reachability bits, and it may involve the ETR in less complexity.
However, I think the whole business of involving ETRs in matters
concerning reachability and mapping is a problem for LISP.
During times of disruption, when they most need to communicate, ETRs
will often be unable to communicate reliably.
In Ivip, ETRs do two things:
1 - For encapsulation: Decapsulate packets
Modified header forwarding: Restore original IP headers
Then the ETR forwards the packets to the destination network
by some locally configured means.
2 - For encapsulation only, the ETR engages in a protocol by which
the ITR can reliably and rapidly determine the Path MTU
to that ETR:
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
ETRs might be involved in probing of reachability, by whatever
external system the end-user network hires (or deploys themselves).
Ivip has no reachability testing or ETR decision making functions at
all. It is up to the end-user network to do this, however they
choose, and to use that information to change the mapping of each of
their micronets (EID prefix, but with arbitrary start point and
length) to a single ETR address, in real-time.
The reachability probing system would be multiple servers in the DFZ,
operating as a coordinated system. The end-user network may well
give the operators of this system the authority to make decisions
about which ETR(s) traffic should flow to, so the reachability
probing network would actually control the mapping of their micronets
in real time. This reachability probing network could also
coordinate with a router in the destination network, or be under
manual control, to spread traffic over multiple ETRs to achieve
incoming TE. This would be by splitting the servers which receive
the incoming packets over multiple IP addresses so they could be in
separate micronets, each separately mappable to a different ETR.
While the reachability probing system might specifically probe ETRs,
a more likely scenario doesn't directly involve the ETR at all.
Probe Servers ISP1 Destination end-user network
PS1 ----------- ETR1-----\ /
\ / CER1---
PS2 ----------- ETR2-----/ \
ISP2
Two probe servers in the DFZ can send packets to either ETR. They
can probe the full status of the ETR without probing it directly. To
do this, they act like an ITR, by encapsulating a probe packet
addressed to the CER1 end-user router, or to some other router or
host within the end-user network. They can encapsulate it with the
address of either ETR1 or ETR2. Each probe carries a nonce and there
needs to be a response returned from the target device - which could
be as simple as a ping response with enough of the original packet to
include the nonce.
This way, each individual probe server can probe full reachability of
the end-user network via either ETR. The ETR would have no special
functionality to support this, and does not need to be configured in
any way regarding the probe network.
The same system would apply for modified header forwarding - instead
of encapsulation. The probe servers would create the modified
headers so the probe packet would be forwarded via one ETR or the other.
The probe servers would communicate their results to some central
server system in the probe network, which would make decisions about
changing mapping in real time whenever it appeared that one or the
other ETRs was unable to get packets to the destination network.
All core-edge separation schemes need ITRs and ETRs. However, with a
real-time mapping distribution architecture such as used with Ivip,
the ITR does not make any decisions about which ETR to send packets
through, because the Ivip architecture externalises the probing and
decision-making system from the core-edge separation scheme itself,
and require end-user networks to do it themselves. This reduces the
probe traffic, compared to every ITR doing its own probing, and
enables an endless choice of probe techniques and decision making
logic to be employed.
It also means the ETRs can be very simple indeed.
For modified header forwarding, there is no PMTUD stuff to do, and
the ETR simply restores the format of the packet to a normal IP
format. It then forwards the packet to the correct destination
network by some means. That's it. The ETR only needs to be
configured to recognise that certain address ranges in the restored
packet's destination address correspond to destination networks which
it can forward the packet to.
As long as LISP and APT or any other core edge separation scheme rely
on a slow mapping distribution system, there are going to be complex
tasks for the ITRs in determining which of the multiple ETRs' RLOC
addresses to use.
For LISP (including OpenLISP, which is independent of the main
LISP-ALT project), the attempts to handle this real-time problem
include locator reachability bits and versioning. Both of these
involve ETRs being highly complex and also working in a coordinated
manner with the ETRs of other ISPs.
Ivip requires none of this because the real-time mapping system tells
all the ITRs exactly what to do for each micronet (EID prefix):
tunnel the packet to just one ETR address. Consequently the Ivip
ITRs and ETRs are much simpler than would be possible in a fully
developed LISP or APT system (APT's ITR functions are split between
the ITR and the Default Mapper).
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
