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

From: Terry Manderson <[email-masked]>
Date: Thu, 21 Jun 2012 18:08:05 -0700

The usual buzz surrounding agendas has begun on various WG lists, why should
LISP be any different right? ;-)

Please note:

2012-07-02 (Monday): Working Group Chair approval for initial document
(Version -00) submissions appreciated by 17:00 PT (UTC -7).

2012-07-09 (Monday): Internet Draft Cut-off for initial document (-00)
submission by 17:00 PT (UTC -7)

2012-07-16 (Monday): Internet Draft final submission cut-off by 17:00 PT
(UTC -7)

2012-07-18 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7)

2012-07-20 (Friday): Early Bird registration and payment cut-off at 17:00 PT
(UTC -7).

2012-07-23 (Monday): Revised Working Group agendas due by 17:00 PT (UTC -7)

So folks, requests for speaking slots to me by the 9th of July (2012-07-09)
please.

Cheers
Terry

---

From: Vince Fuller <[email-masked]>
Date: Mon, 25 Jun 2012 08:58:35 -0700

> So folks, requests for speaking slots to me by the 9th of July (2012-07-09)

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

---

From: Terry Manderson <[email-masked]>
Date: Mon, 25 Jun 2012 16:05:44 -0700

Thanks Vince.

Noted.

Cheers
Terry

---

From: Damien Saucez <[email-masked]>
Date: Tue, 26 Jun 2012 10:37:22 +0200

Hello,

May I have a 10min slot to present "LISP ITR Graceful Restart"?

The draft draft-saucez-lisp-itr-graceful related to that will be submitted
in the coming days.

Thank you,

Damien Saucez

On 26 Jun 2012, at 01:05, Terry Manderson wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Terry Manderson <[email-masked]>
Date: Tue, 26 Jun 2012 18:36:41 -0700

Hi Damien,

Request noted.

Cheers
Terry

---

From: Damien Saucez <[email-masked]>
Date: Fri, 29 Jun 2012 11:27:16 +0200

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 30 Jun 2012 13:02:33 +0200

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

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.