Hi Damien,
new usage of LISP that would enable stub network to
select the ISP's outgoing link they use for every packet?
Is selecting different outgoing link to different ISP for _every_packet_
is really a good idea ?
Yes in the paper you actually correct yourself by saying:
"Nevertheless, the different packets of a stream will
go through the same ASBR thanks to a hash algorithm
described in the LISP specification."
Few comments on the paper:
--------------------------
However this
diversity cannot be fully exploited due to BGP limitations, which
only keeps one single route for each available prefix.
That is completely incorrect. BGP keeps (and may use locally) as many
paths as it receives from it's iBGP and eBGP peers.
With this scheme, an ISP
may propose its rich path diversity (at least partially) to its
customers, in order to perform advanced traffic engineering (e.g.
fast recovery, load balancing...) based on richer and more flexible
path selection policies (e.g., considering price, performance or
stability of routes).
Please note that there are commercial deployed products doing just that
for the last 10 years or so already.
Multipath BGP extension [12], [13]
slightly changes the BGP decision process in order to use
simultaneously multiple routes. However, the routes must be
similar (i.e., same Local-Preference, AS path length and MED)
and traffic is balanced equally on these paths.
Not true. There are number of knobs in shipping BGP implementations
which relax those checks. Also multipath considers link-bw which results
in non equal traffic spread.
A. Description of the architecture
Our architecture offers the stub the flexible capability of
controlling the network exit point for its own traffic.
Stub AS usually by it's definition has only a single exit .. or multiple
exit points to the same upstream ;).
The tunneling to deflection point in the upstream can be done, but it
guarantees nothing. Till you have at least a minimal assurance what is
the view of the world of the peers of the upstream any decision you make
from stub AS point of view will be quite blind.
At the control-plane level, our architecture relies on a centralized
and extended mapping system named the Local Mapping
Distributor (LMD). In addition to storing and distributing
mappings, the LMD firstly generates them from the diverse
Internet routes, filters them and ranks them.
LMD is just a little bit enhanced RR. (see below)
One possible solution is that an ASBR carries
several IP addresses, one for each neighboring domain it is
connected to. The next-hop field in every received eBGP
update is replaced by the IP address of the local ASBR which
is associated with the neighbor the update is coming from. All
packets sent towards this address must then be routed towards
the appropriate neighbor.
So you are saying the ASBR would advertise into IGP
5.5.5.0/24 while internally each of his EBGP peers would get 5.5.5.1 ..
5.5.5.254 correct ?
The issue with this is that if the peer 5.5.5.X goes down no one in the
domain will ever know about it till BGP withdraws the prefixes coming
from 5.5.5.X - no chance of fast connectivity restoration/PIC.
A specific protocol for
inter-LMD communication must be designed in this case. It
will not be discussed herein due to space constraints.
Assuming that LMDs are just a bit extended RRs normal EBGP with
add-paths could be used. I see no need for new protocol.
Please see the draft where similar concept is described for the
intra-domian optimal path selection. It could be very easy to extend it
to advertise "optimal" paths to stub ASes (either their ASBRs or their
RRs/LMDs).
Ref: http://goo.gl/Gc5LD
The proposal is based on the LISP Map-and-Encap
mechanisms in order to overcome current BGP limitations.
Please note that there is work in progress to define new BGP attribute
which allows to carry remote next hop. That seems completely sufficient
to not only realize your set of goals, but also to allow encapsulation
much further then to the directly connected upstream's deflection point
without shifting entire Internet to a new control/data plane paradigm.
Best regards,
R.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
