about all this, I don’t need
to repeat myself.
Regards,
Damien Saucez
> On 9 Jan 2018, at 18:54, Dino Farinacci <farina...@gmail.com> wrote:
>
> Guys, please look at the latest changes instead of hashing the same
> arguments.
>
> This is what I am going to do. I am go
specifications.
I think the proposition of moving text that the chairs proposed is very
reasonable and greatly improve the quality of the specifications and therefore
reduce the risk of misinterpretation and bugs while implementing the protocolS
Cheers,
Damien Saucez
> On 4 Jan 2018, at 18:00, D
I support the adoption of draft-rodrigueznatal-lisp-vendor-lcaf
Damien Saucez
> On 26 Jul 2017, at 13:16, Luigi Iannone <g...@gigix.net> wrote:
>
> The call ends August 10th 2017 !
>
> Luigi
>
>> On 26 Jul 2017, at 11:41, Luigi Iannone <g...@gigix.net>
the right word. For me it is an
>> implementation detail, hence not needed to be document in the specs but of
>> course it can be implemented.
>
> Clock sweep is still recommended by vendors. And it should.
I agree that clock sweep may be interesting (though I am not really sure that
in practice it is of real use as it is finally very slow and not flexible, but
maybe you have a deployment case where clock sweep is used and without it it
would not have been possible to do something). I still believe that Clock sweep
is something related to deployments and constructor recommendations. For me it
is not really part of the protocol, just a way to play with mappings. Anyway,
compared to the rest, this is really a detail.
Thanks,
Damien Saucez
>
> Dino
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
+1
Damien Saucez
> On 25 Jul 2016, at 16:34, Jose Saldana <jsald...@unizar.es> wrote:
>
> Hi
>
>> On 7/15/16 6:56 AM, Luigi Iannone wrote:
>>> His All,
>>>
>>> the chairs have review the WG discussion during the adoption call.
>>>
&
This new title is perfect.
Damien Saucez
> On 25 Jul 2016, at 14:12, Vina Ermagan (vermagan) <verma...@cisco.com> wrote:
>
> Hello,
>
> During IETF96 WG meeting a change of title from “LISP Configuration YANG
> Model” to “YANG Model for LISP” was proposed by author
Dear chairs,
I support the new chartes with the changes proposed by Fabio and Vina.
As Joel and Vina, I would prefer not to order the different points as such
prioritisation would be highly subjective.
Cheers,
Damien Saucez
On 05 Jan 2016, at 02:49, Vina Ermagan (vermagan) <ve
aightforward to make it in a nice way, but
the as LISP is about decoupling control-plane and data-plane it would
make sense to also decouple control and data-plane definition.
Imagine you want someone to only implement the control-plane, how
does he know what to implement exactly to be fully compliant?
Hello,
I am supporting the move to ST and focus to overlay technology in this case.
Damien Saucez
On 25 Aug 2015, at 11:27, Lori Jakab l...@lispmob.org wrote:
On 8/25/15 12:07 PM, Luigi Iannone wrote:
Folks,
so far only Dino replied to this thread. Should we understand that people
Perfect!
Damien Saucez
On 16 Aug 2015, at 00:03, farina...@gmail.com wrote:
The logic follows like this:
If NVo3 is a requirement for the recharter, then L2 overlay support is
required. If L2 overlay support is required, then you must stretch subnets.
If you stretch subnets
Hello,
I understand that multicast and nat traversal are potentially required in all
use cases, but the must support sounds extreme to me. Are they hypothetical
requirements or real demand from the market targeted by LISP, new version ?
Damien Saucez
On 12 Aug 2015, at 19:44, Stig Venaas s
Dear Lispers,
An early video of the demo done today is available on
https://youtu.be/kdIJ6pbG_zE
Best regards,
Damien Saucez
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Hello,
Please find enclosed the slides of the presentation Cloud SOHO Services
20150720_cloud_soho_services_ietf_93.pdf
Description: Adobe PDF document
Thank you,
Damien Saucez
On 17 Jul 2015, at 09:54, Luigi Iannone g...@gigix.net wrote:
To all presenters of the meeting,
Please send
A new version with some minor correction
20150720_cloud_soho_services_ietf_93.pdf
Description: Adobe PDF document
Damien Saucez
On 19 Jul 2015, at 11:39, Damien Saucez damien.sau...@gmail.com wrote:
Hello,
Please find enclosed the slides of the presentation Cloud SOHO Services
that.
This is the exact reason why [CCD12] is referenced. It shows that the impact
is on miss rate (see page 5). Also as it is a public analytical study, people
can
adapt it relatively easily (as opposed to a traffic trace that is not available
to
the community).
Damien Saucez
as the map-cache is implemented
with LRU.
Damien Saucez
2. Repeat the cited studies, but with a pessimistic (worse case) rather than
optimistic (better than best case) assumption about cache granularity.
The second option would allow us to actually have some idea what would happen
if LISP
provision the EID-to-RLOC cache of their ITRs according to the miss
rate they want to achieve for their given traffic.
That is clear enough for me and unless someone can prove the model
wrong I am perfectly fine with this observation that is supported by
empirical data.
Cheers,
Damien Saucez
Hello,
Please find attached the slides for the impact presentation.
20150323_IETF92_lisp_impact.pdf
Description: Adobe PDF document
Damien Saucez
On 17 Mar 2015, at 13:35, Luigi Iannone g...@gigix.net wrote:
Hi All,
no changes on the agenda have been requested, which is now confirmed
and more detailed information than is available with
currently deployed routing and control protocols.
ok, we will integrate that.
Thank you for all your efforts!
Damien Saucez
Thanks, Ross
___
lisp mailing list
lisp@ietf.org
https
Saucez
Thanks, Ross
-Original Message-
From: Damien Saucez [mailto:damien.sau...@inria.fr]
Sent: Wednesday, February 18, 2015 4:06 AM
To: Ross Callon
Cc: Luigi Iannone; LISP mailing list list; Olivier Bonaventure
Subject: Re: [lisp] Progress on threats document
Hello Ross
I support this option.
Damien Saucez
On 29 Jan 2015, at 14:24, Sander Steffann san...@steffann.nl wrote:
Hi,
Op 29 jan. 2015, om 13:27 heeft Gregg Schudel (gschudel)
gschu...@cisco.com het volgende geschreven:
+1
it’s been deployed for several years and very stable (and simple to work
Thank you, we will had this to the new version. Florin is already on the beef :)
Damien Saucez
On 16 Dec 2014, at 00:21, Dino Farinacci farina...@gmail.com wrote:
Beside the crypto document there is a call for adoption for the impact
document and a WG last call for the EID block management
Hello,
I am ok with the last call for the EID Block Management Guidelines document.
Just a question, section 3.b (Prefix Size Rationale”) of the EID Prefix
Request” form
is mandatory, what information must be put there?
Damien Saucez
On 04 Dec 2014, at 14:33, Luigi Iannone g...@gigix.net
-plane more general/extensible while keeping
backward compatible.
Damien Saucez
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
feedback from people
about the different impact but what we are looking is impact based on
facts, not expectations.
Damien Saucez
Thanks, Ross
From: lisp [mailto:lisp-boun...@ietf.org] On Behalf Of Luigi Iannone
Sent: Saturday, October 25, 2014 8:04 AM
To: LISP mailing list list
Cc: Damien
FYI
We still have a few days and would be happy to have additional contribution,
particularly on middle boxes and push-pull.
Thank you,
Damien Saucez
Begin forwarded message:
From: internet-dra...@ietf.org
Subject: New Version Notification for draft-saucez-lisp-impact-07.txt
Date: 24 Oct
Hello,
Thanks for the input.
I guess you have such deployment, do you have some figure (numbers) that could
become public to show the competitive advantage of LISP?
Damien Saucez
On 07 Oct 2014, at 01:16, Sharon sbar...@gmail.com wrote:
Damian, sorry for the delay, meant to get
- Ed on the problem of middle boxes and NATs
Would you both be ready to provide a little paragraph on this?
Any other volunteer?
Thank you,
Damien Saucez
On 29 Sep 2014, at 19:01, Sharon sbar...@gmail.com wrote:
Hi Damian, our experience applying the lisp architecture is focused
Internet. This draft
can be seen somehow as a companion of the -intro- document that focuses
on the architecture and mechanisms.
Thank you for you collaboration,
Damien Saucez
- Architecture description: This document will describe the
architecture of the entire LISP system, making it easier
Hello,
This is definitely something interesting and that is worth discussing in this
document!
Damien Saucez
On 29 Sep 2014, at 19:01, Sharon sbar...@gmail.com wrote:
Hi Damian, our experience applying the lisp architecture is focused on
service providers network under the umbrella
Dear all,
We just submitted a revision of the threat document.
We would like to thank the WG in general and Ron in particular for all
the comments that have been provided.
As you can see, the document changed in depth so to cover as much attack as
possible.
See you in Toronto.
Damien Saucez
is to be able to construct a complete threat
categorisation.
Thank you,
Damien Saucez
On 16 Jun 2014, at 18:39, Ronald Bonica rbon...@juniper.net wrote:
Joel,
IMHO, there is a very distinct need.
As we have seen previously in this email thread, some mitigations introduce
new threats
Dear all,
We carried out some measurement constraints on the LISP Beta Network.
More precisely, we evaluated the performance of the mapping system and
the interworking mechanism. Our measurements highlight that
performance offered by the LISP interworking infrastructure is
strongly dependent on
.
What do you think of all this?
Damien Saucez
On 13 Jun 2014, at 18:26, Ross Callon rcal...@juniper.net wrote:
We have had significant discussion of attacks against the control plane of
routers, and some discussion of the relative capacity of the control plane
versus data plane. I have
and are protected by the nonce.
Could you describe precisely the attack you have in mind? The only
think I can see is relying on the birthday paradox but that is a
completely different story.
Damien Saucez
On 10 Jun 2014, at 21:37, Ronald Bonica rbon...@juniper.net wrote:
Dino,
Exactly! So, assume
been filed.
Best regards,
Damien Saucez
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
to provide a reliable service to
legit traffic and/or systems or by exploiting vulnerabilities to make
the targeted service unable to operate properly.
is covering the case you mention.
Damien Saucez
.
Thank you,
Damien Saucez
Ps: happy holidays :)
On 21 May 2014, at 18:45, Ross Callon rcal...@juniper.net wrote:
To get the charter to say fix these security holes we need to know what the
security holes are. The point of the threats document is to understand what
threats
Dear Ross,
Thank you for your time.
Before detailed comments below, we have to remind that the objective
of this document is to identify global threats potentially introduced
by LISP w.r.t. what exists today in the legacy Internet. The problem
space is out of the scope of the document.
I support the draft as it reflects the last WG discussions.
Damien Saucez
On 20 Mar 2014, at 19:26, Joel M. Halpern j...@joelhalpern.com wrote:
The draft LISP EID Block has been revised to reflect the WG discussion and
comments received.
This starts a last call for this document, ending
.
Thank you,
Damien Saucez
Thanks Regards,
Marc
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
storms for the startup, not for the shutdown.
Damien Saucez
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
an ITR, packets are forwarded to another ITR and
there is a miss storm as long as the prefixes in the backup ITR do not
cover those that where in the down ITR.
Damien Saucez
Dino
Damien Saucez
Dino
___
lisp mailing list
lisp@ietf.org
-engineering the management of
sending map-requests on a given ITR will likely end up creating more
complexity, and therefor fragility, in the implementation.
That's a point we can discuss, but are you ready to accept packet loss?
At the end, a miss = a packet drop...
Damien Saucez
-Darrel
for the WG to produce (rather
than sending it to the Independent Stream?)
I do believe this is an appropriate document for the WG to produce and
will be happy to review it.
Damien Saucez
Yours,
Joel, asking as chair
On 1/27/14 1:55 PM, Dino Farinacci wrote:
Draft draft-farinacci-lisp-rig
On 05 Dec 2013, at 11:56, Albert Cabellos acabe...@ac.upc.edu wrote:
Hi,
On 04/12/2013 22:40, Damien Saucez wrote:
[snip]
* Section 4.3.2.2-RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.
I think the analysis
Hello Albert,
On 04 Dec 2013, at 21:28, Albert Cabellos acabe...@ac.upc.edu wrote:
Hi
I went through the document in detail and IMHO it is well structured and
more importantly, it provides a complete and meticulous analysis of the
security threats of LISP on a public deployment.
Thank
I support the adoption of this document as WG doc.
Damien Saucez
On 20 Nov 2013, at 00:25, Terry Manderson terry.mander...@icann.org wrote:
In Vancouver the chairs received a request for the following document to be
adopted as a WG item.
http://tools.ietf.org/html/draft-iannone-lisp-eid
as a point to consider in the new charter.
Regards,
Damien Saucez
On 21 Oct 2013, at 11:12, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Locator/ID Separation Protocol Working Group
of the IETF
Hello,
This is a working version of the draft for the interim meeting as you can
notice it has been almost fully rewritten. The recommendation section is
still empty but will be properly provisioned for the end of the week.
Thank you all for your comments.
Best regards,
Damien Saucez
On 02
of early October.
Thank you,
Damien Saucez
Begin forwarded message:
From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lisp-threats-05.txt
Date: 29 Aug 2013 23:08:40 GMT+02:00
To: Damien Saucez damien.sau...@inria.fr, Luigi Iannone
luigi.iann...@telecom
to control these servers is able to control internet forwarding.
I can imagine that the RSA would like LISP very much.
Don't worry, before you traffic to be encapsulated by LISP you will use DNS...
Damien Saucez
Heiner
___
lisp mailing list
Dear all,
I will not interact with the mailing list for now to avoid putting
biased in the discussion. As soon as I will see a convergence
to something, I will reflect this in the draft and propose a new
version for revision.
Thank you all for your contribution.
Damien Saucez
On 21 Mar 2013
.
The authors of DDT are very aware of all this and
DDT is a good tradeoff between our research
expectations and their operational needs
discovered deploying LISP in lisp4.net.
For more details, check
Loránd Jakab, Albert Cabellos-Aparicio, Florin Coras, Damien Saucez, and
Olivier Bonaventure
of the good. So we have to find a trade-off
between best and good.
Damien Saucez
Hi Damian,
I read your security document after your emails yesterday, and was hoping I
could get you to address your thoughts on the best practical security
measures. Without offering an opinion
is the wrong word, but given that ALT does not define any
security mechanism (it simply assumes the use of whatever is available
with BGP), the explicit description of how security works with DDT would
seem to be easier/better to me.
ok
Damien Saucez
--Vince
On 23 Oct 2012, at 22:32, Damien Saucez damien.sau...@gmail.com wrote:
On 23 Oct 2012, at 21:34, Vince Fuller v...@cisco.com wrote:
Hi Damien-
Thanks for catching the typos. I few comments on your comments:
7.4. Just Enough Security
How much security to have is a complex issue
submitted by Damien Saucez and posted to the
IETF repository.
Filename: draft-saucez-lisp-iesg-statement
Revision: 00
Title: LISP IESG Statement
Creation date: 2012-10-14
WG ID: Individual Submission
Number of pages: 12
URL:
http
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:
So folks, requests for speaking slots
if you
provide valid case for it.
Would resiliency (and protection against path exploration) be a
valid case for it?
Damien Saucez
Thx,
R.
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
A new version of I-D, draft-saucez-lisp-itr-graceful-00.txt
has been successfully submitted by Damien Saucez and posted to the
IETF repository.
Filename: draft-saucez-lisp-itr-graceful
Revision: 00
Title: LISP ITR Graceful Restart
Creation date: 2012-07
Hello Eliot,
May I ask you why you say that LISP+ALT relies on caching?
LISP+ALT is just a BGP based overlay, where is the caching
there (is the BGP RIB that you consider as a cache?).
Cheers,
Damien Saucez
On 23 Feb 2012, at 07:38, Eliot Lear wrote:
On 2/20/12 9:06 PM, John Scudder
Hello,
By its very nature LISP causes resiliency issues. Don't you think that the
charter should briefly evoke that?
Thank you,
Damien Saucez
On 21 Dec 2011, at 02:49, Terry Manderson wrote:
That works for me in both cases of wearing/not wearing WG hat.
Cheers
Terry
On 20/12/11 9
and we can present that status of them in Paris as well.
I will give comments on draft for beginning of next week and later (january)
update
my implementation accordingly.
Damien Saucez
Thanks,
Dino
--Vince
- Forwarded message from internet-dra...@ietf.org -
Date: Mon
Hello Fred,
On 14 Sep 2011, at 17:18, Templin, Fred L wrote:
Hi Damien,
-Original Message-
From: Damien Saucez [mailto:damien.sau...@uclouvain.be]
Sent: Wednesday, September 14, 2011 11:07 AM
To: Templin, Fred L
Cc: lisp@ietf.org
Subject: Re: [lisp] Source address spoofing
, in the case
the RLOC changes before the expiration, you will need
SMR or version change implying the retrieval of the new
mapping. But in this particular case, you also have a
security threat that is a DoS…
Regards,
Damien Saucez
On 14 Sep 2011, at 10:15, Templin, Fred L wrote:
I have
of Jeff saying that the churn problem should
not be neglected.
Thank you,
Damien Saucez
Cheers,
R.
Even in campus networks like our
university we do not observe millions of concurrent flows. In one day we
have in
general 3 million different IP addresses in our network
question with the cache is related to the mapping retrieval: what
if we do not have a mapping in the cache. Drop is not always a good option,
buffering is not always possible and forwarding is maybe not achievable for
scalability reasons (r.i.p. data-probe).
Thank you,
Damien Saucez
Of course
Dear Jeff,
On Thu, Jul 14, 2011 at 4:03 AM, Damien Saucez
damien.sau...@uclouvain.be wrote:
On 14 Jul 2011, at 04:55, Ross Callon wrote:
To me it seems highly unlikely that this assumption is within an order
of magnitude of being correct.
At a first glance, the assumption might look bad
-list to design a worst case scenario
that we can study to see how the ITRs would behave?
Thank you for the feedback,
Damien Saucez
Ross
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
70 matches
Mail list logo
