Viewed as a use case draft, what is there is probably reasonable. I
would be inclined to include some indications of the open questions in
addressing the use case, but that is not mandatory.
Yours,
Joel
On 2/13/14, 4:30 AM, Patrice Bellagamba (pbellaga) wrote:
Hi Joel, you are right, in this case LISP mobility is used instead of L2
technics, and there is advantages to this.
We have seen multiple customers that are not confident with L2 extension,
especially because it does extend the broadcast domain.
Here in addition the L3 device that perform LISP xTR in the cloud is
providing default gateway locally, allowing not to trombone toward the
enterprise to have intra-cloud routing.
LISP respond to the need 'Route when you can, Bridge when you must'
Thanks, Patrice
On 2/12/14 6:26 PM, "Joel M. Halpern" <[email protected]> wrote:
I think taht using the same subnet/prefix simply amounts to having /32
routes in the edge devices. Also, there are other known mechanisms
(L2VPN extension) which achieve that goal.
Having said that, it is a useful goal and one LISP helps with.
I do not see why the routing is any more optimal than any of the other
tunnel management mechanisms.
Yours,
Joel
On 2/12/14, 12:18 PM, Yves Hertoghs (yhertogh) wrote:
Joel,
The main advantages are:
* You can use the same subnet/prefix in both sites
* there is optimised ingress routing from remote LISP enabled sites
towards the right destination
Yves
On 12/02/14 18:12, "Joel M. Halpern" <[email protected]> wrote:
that this describes an existing usage is clearly very important.
It seems that if the scale of the VPN is small enough that manually
configured IPSec tunnels can be used, then LISP does not provide a lot
of advantage. If it is automated tunnels, there seems to be a need to
coordinate the two systems. What am I missing?
Thanks,
Joel
On 2/12/14, 12:04 PM, Fabio Maino wrote:
Hi Joel,
This describes how LISP is used today in combination with IPsec
(typically GDOI is used to simplify key distribution).
I think Dino's work is more forward looking, with two main goals: (1)
combine encryption with the LISP dataplane, for a more efficient
encoding on the wire, (2) take advantage of the LISP mapping system
(and
possibly of some of the mechanisms in LISP-SEC) for key
derivation/distribution
Fabio
On 2/12/14, 8:54 AM, Joel M. Halpern wrote:
This draft seems to expect that IPSec tunnels will be set up by means
outside of LISP. That seems to contravene the premise of LISp that
it
can operate without needing permanent / pre-established tunnel state.
Should this be tied to the work Dino described at the last IETF
meeting on using LISP to establish encryption for the LISP tunnel?
Yours,
Joel
On 2/12/14, 6:22 AM, Santiago Freitas (safreita) wrote:
Hi LISP Working Group,
Today we have submitted a draft that covers using LISP for Secure
Hybrid
Cloud Extension.
The draft can be found at
http://www.ietf.org/id/draft-freitas-bellagamba-lisp-hybrid-cloud-use
ca
se-00.txt
We would like to request your comments on it.
Also, we would like request a small slot on the upcoming IETF 89
meeting
to present an overview of the use case covered on the draft.
We look forward to your comments and for your feedback if we can
have
a
small slot to present an overview of this draft on IETF 89.
Sincerely,
Patrice and Santiago
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
