Re: [lisp] Thinking forward to Vancouver, important dates.

[Damien Saucez <[e-mail]>]

Hello Robert,

sorry for the delay.

many thanks for the comments, nice to emulate the discussion.

comments inline

On 30 Jun 2012, at 13:02, Robert Raszuk wrote:

> 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."
> 

of course, as the path might be very different, it is better
to have one flow = one path

> 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.

well, with vanilla BGP, at one given router you have only one
exit per prefix. Of course this exit can be different at different
routers and intradomain multipath can be used to reach this
exit.

In the paper, we consider vanilla BGP, of course multipath BGP
allows several exits per prefix, and you can use add path to
iBGPed announce multiple routes internally

> 
>> 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.
> 
sure, but as far as I know, they are black boxes and there is no
standard method for them. is there?

>> 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.

sure, but again I think there is not standard specifications for
that yet and I am not sure that, when we look how it moves,
BGP will have this feature within the next 5-10 years. But
maybe I am wrong, I am not following the related WGs
that much.

> Also multipath considers link-bw which results in non equal traffic spread.
> 

you are right that the phrasing was not ideal. It is obviously
possible to have no equal traffic spread when combined with
TE, but it is not BGP itself that allow this.

>> 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 ;).

Ok, we don't have the same stub AS definition. Is there any
official definition? In our case, we consider that an AS is a stub
if it is not a transit. According to this definition, it can thus be
multi-homed (multiple upstreams) and multi-connected (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.

Sorry, I am not sure I understand this sentence. With the tunnels,
we can select the exit point exactly, however, of course, the selection
of this exit point is based on partial information.

> 
>> 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)

Yes, it could be a RR++, we just used a specific term to
make the understanding easier but technically, it can
be an extended version of an RR implementation.

> 
>> 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.
> 
actually, we thought about internally announce at least all the addresses
independently (one /32 per "exit link"). To that, we can add one /x per
ASBR that covers all the /32 of the ASBR. Basically, one /32 per logical
link to the outside + one /x per ASBR. Ot top of that, we must allow LISP
to decapsulate even if the RLOC in the DB is not reachable. In such a
way, there is not packet loss and normally PIC would work (but I am
not expert in PIC so maybe there is some corner case I haven't seen).

>> 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.

I thought add path was limited to iBGP. If we can use add-path in eBGP
and if we can use any selection mode we want, then yes it would make it.

> 
> 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

interesting. It is indeed very close, small extension could make it a
possible implementation.

 I like "4.  Angular distance approximation
for BGP warm potato  routing". Would the angular position
easy to construct in "strange" topologies?

>> 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.
> 

I was not aware of this, could you give me pointers? Is there a solution
to keep AS Path correct with AS sets if this is extended to hop i announcing
to hop i+2 or i+3? Here we limit to stubs and announcements between i
and i+1.

Thank you for the inputs.


Damien Saucez

> Best regards,
> R.
>