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

From: Terry Manderson <[email-masked]>
Date: Sun, 1 Jul 2012 18:05:18 -0700

Hi Damien,

Your request has been noted, and if time is available I will pencil you in.

Thanks
Terry

On 29/06/12 7:27 PM, "Damien Saucez" <[email-masked]> wrote:

> Hey,
> 
> Can I have a 10 minute slots to present research work on
> a new usage of LISP that would enable stub network to
> select the ISP's outgoing link they use for every packet?
> 
> In attached, the paper that has been presented a few
> weeks ago. In addition to the content of this paper, I
> would also show a method to use in conjunction with
> this technique to select and use backup paths that
> reduce as much as possible the overlapping of points
> of failure.
> 
>  
> 
> 
> Thank you,
> 
> Damien Saucez
> 
> On 25 Jun 2012, at 17:58, Vince Fuller wrote:
> 
>>> So folks, requests for speaking slots to me by the 9th of July (2012-07-09)
>>> please.
>> 
>> Hi Terry-
>> 
>> I'd like 10 minutes to talk about the LISP architecture draft (being authored
>> by Noel Chiappa) which should be ready in rough form ahead of the -00 draft
>> deadline.
>> 
>>        Thanks,
>>        --Vince
>> _______________________________________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Damien Saucez <[email-masked]>
Date: Fri, 6 Jul 2012 12:35:16 +0200

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

---

From: Damien Saucez <[email-masked]>
Date: Fri, 6 Jul 2012 12:35:37 +0200

> Your request has been noted, and if time is available I will pencil you in.
thanks

Damien Saucez

---

From: Damien Saucez <[email-masked]>
Date: Fri, 6 Jul 2012 14:59:52 +0200

Folks,

We made some measurements during the switchover
from ALT to DDT on LISP4.net with Luigi and Benoit.
We can present some of our results in 5 minutes at the
end of the meeting.

Cheers,

Damien Saucez

On 22 Jun 2012, at 03:08, Terry Manderson wrote:

> Cheers

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 Jul 2012 16:39:29 +0200

Damien,

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

No. EBGP multipath and IBGP multipath are clear examples where in 
vanilla BGP you install more then one BGP path to RIB.

> 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

I am talking about vanilla BGP. No add-path is required for multipath.

>> Please note that there are commercial deployed products doing just
>> that for the last 10 years or so already.
>>

They are not that black. They in fact work by influencing BGP best path 
decision.

> possible to have no equal traffic spread when combined with TE, but
> it is not BGP itself that allow this.

Of course this is BGP itself. Nothing to do with TE. Please see:
http://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-04

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

You select it exactly but only in your peer. The point is that it buys 
you very little as avrage AS distance today is 3.4 - You have completely 
no control what happens after the deflection point.

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

Today it is limited to iBGP, but not that it can not be extended if you 
provide valid case for it.

Thx,
R.

---

From: Damien Saucez <[email-masked]>
Date: Fri, 6 Jul 2012 16:52:48 +0200

Hello,

On 06 Jul 2012, at 16:39, Robert Raszuk wrote:

> No. EBGP multipath and IBGP multipath are clear examples where in vanilla BGP you install more then one BGP path to RIB.
> 

in which RFC is this defined? I looked for but not found it. I am not looking
for multiple routes in the RIB but in the FIB. If you can point me to the 
correct RFC, I am interested.

> They are not that black. They in fact work by influencing BGP best path decision.
> 

Well, I had the impression that this extended community was used
to announce the link capacity more than its usage. Do you know
if someone is using this community to adapt the load balancing 
according to the link load?

> You select it exactly but only in your peer. The point is that it buys you very little as avrage AS distance today is 3.4 - You have completely no control what happens after the deflection point.
> 

Ok, yes you are right. However what we have seen (but these
results are not public right now) that the major benefit if you can
select the exit of your ISP with our technique is that you can use
the most disjoint path (ASPaths sharing the least number of ASNs)
which means that in case of failure, you reduce the risk of using
a path that is actually not yet seen as dead  (because of path
exploration). So I believe that resiliency is a good use case (and
also with any other techniques allowing one to select several
routes by its own)

> Today it is limited to iBGP, but not that it can not be extended if you provide valid case for it.

Would resiliency (and protection against path exploration) be a
valid case for it?

Damien Saucez

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 Jul 2012 17:03:30 +0200

> correct RFC, I am interested.

http://tools.ietf.org/html/draft-ietf-idr-bgp-issues-06
Section 2.11.3

It does not require protocol extension so this is a BGP implementation 
thing. IETF RFCs are not to describe implementations, but protocol.

And of course multipaths are installed both in RIB and FIB.

> to announce the link capacity more than its usage.

True.

> Do you know if someone is using this community to adapt the load
 > balancing according to the link load?

I do not know if this would be a good idea in the first place.

R.

---

From: Damien Saucez <[email-masked]>
Date: Fri, 6 Jul 2012 17:13:58 +0200

On 06 Jul 2012, at 17:03, Robert Raszuk wrote:

> It does not require protocol extension so this is a BGP implementation thing. IETF RFCs are not to describe implementations, but protocol.
> 
ok with the SHOULD i the proposal, that solves the issue

> I do not know if this would be a good idea in the first place.

agree, this is a pandora box but maybe it could help reducing
the impact of some DDoS. For example, with our technique, if
the operator sees that there is too much load from a part of the
network, it can change the weight associated to the locators that
it announces to this part of the network such that a proportion
of the traffic from there is diverted to other parts that are less
loaded. This can be done with the community as well (but you
also need a "scoped advertisement" but this is not elegant as
the value is supposed to give the capacity (called bandwidth
in the draft) in bytes, which hasn't change... An alternative 
would be to have a community that can be scoped and that
only gives a weight to the route. Maybe this already exist.

Damien Saucez