Re: [lisp] Upcoming meeting

[Victor Moreno (vimoreno)]

We should discuss the topic of backbone peerings and how those may be enforced 
in an overlay. 
We should also have a discussion on the policies required for the air 
traffic/operations control applications.


Sent from my iPhone

> On Aug 24, 2021, at 2:28 PM, Dino Farinacci  wrote:
> 
> 
>> 
>> So the question really for the working group is "what things do you think it 
>> is worth discussing.  Not listening to.  Discussing.
> 
> The intent of these presentations is to spur discussion. And, as I said, can 
> be as short as 5 minutes to bootstrap discussions. The time allocated would 
> be for discussion and not for presentation.
> 
> Dino
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for Agenda Items

[Victor Moreno (vimoreno)]

Hi Luigi,

We should spend some time on the uberlay topic. Can you please add it to the 
agenda?

Sent from my iPhone

On Feb 24, 2021, at 2:45 AM, Luigi Iannone  wrote:

 All,

either I have a mail problem or there is not that much to discuss in the next 
IETF.

As you can see below the agenda is pretty empty.

Please let us know ASAP if you want a slot.

Thanks

Ciao

Joel & Luigi




CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA

Session 1/1 (120 Minutes)
=-=-=-=-=-=-=-=-=-

Friday, March 21, 2021
12:00 - 14:00 (UTC), Session I, 120 Minutes
(20:00 - 22:00 Beijing)
(13:00 - 15:00 Paris)
(7:00 - 9:00 New York)
(4:00 - 6:00 San Francisco)
Room 6: https://meetings.conf.meetecho.com/ietf110/?group=lisp==1

- Administration
Halpern/Iannone
- Agenda Bashing
- Status reports for WG drafts
10 Minutes (Cumulative Time: 10 Minutes)



o WG Items

- LISP Yang Model - https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/
  10 Minutes (Cumulative Time: 20 Minutes)
  Alberto Rodriguez Natal  Cabellos


o Non WG Items


- Overflow Time/ Discussion
  100 Minutes (Cumulative Time: 120 Minutes)




On 9 Feb 2021, at 15:54, Luigi Iannone mailto:g...@gigix.net>> 
wrote:

Folks,

The preliminary agenda is out and it seems that we are meeting on Friday.

While the agenda may still change it is about time to call for agenda items.

Please if you want a slot send a message to the chairs by February 23rd at 
latest (we will publish a draft agenda on February 24th).

Thanks

Ciao

L.


Begin forwarded message:

From: IETF Agenda mailto:age...@ietf.org>>
Subject: IETF 110 Preliminary Agenda
Date: 6 February 2021 at 01:55:06 CET
To: "IETF Announcement List" 
mailto:ietf-annou...@ietf.org>>
Cc: i...@ietf.org, 110...@ietf.org
Reply-To: supp...@ietf.org

The IETF 110 Preliminary Agenda has been posted. The final agenda will be 
published on Friday, February 12, 2021.

https://datatracker.ietf.org/meeting/110/agenda.html
https://datatracker.ietf.org/meeting/110/agenda.txt

The preliminary agenda includes all planned WG, RG, and BoF sessions. We are 
still finalizing details for a few of our usual meeting-adjacent events, so 
please look out for further details about those. Information about side meeting 
signups will be available when the final agenda is posted.

Please note the agenda times are listed in CET (UTC +1) by default. You may 
select which time zone is displayed on the HTML version of the agenda with a 
menu on the right side of the page. Choose “Meeting Timezone” for CET, “Local 
Timezone” for your own current time zone, “UTC” for UTC, or choose any other 
time zone from the drop down list.


IETF 110 Information: https://www.ietf.org/how/meetings/110/
Register online at: https://registration.ietf.org/110/

Don’t forget to register for these exciting IETF 110 events!


Hackathon
Signup: https://registration.ietf.org/110/new/hackathon/
More information: https://www.ietf.org/how/runningcode/hackathons/110-hackathon/
Keep up to date by subscribing to:
https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110SprintSignUp
More information: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110Sprint

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Moving forward with lisp-nexagon

[Victor Moreno (vimoreno)]

You have my support as well.

-v


On Aug 16, 2020, at 5:23 AM, Sharon Barkai 
mailto:sharon.barkai=40getnexar@dmarc.ietf.org>>
 wrote:

Thank you Rotem, Dino, Fabio, Alberto, and all other sent support notes.
I ask the chairs to move from adoption, steps following RFC are outlined bellow.

Understood the chairs would like lisp-nexagon to reference the 6830bis not 
rfc6830.
This makes sense, hopefully 6830bis will clear IESG soon. Tnx.




On Aug 4, 2020, at 20:40, Rotem Tamir 
mailto:rotemtamir=40getnexar@dmarc.ietf.org>>
 wrote:

Hi Sharon,

As a person coming from a non networking background, having worked on web 
backend and data pipeline problems for many years I wanted to say that working 
on this standard has been quite an eye opening experience.

I have not even heard of LISP before this work (when you first approached me 
with this I thought you were referring to the programming language), and I did 
struggle with the idea for a while. But looking at it now from an system 
architecture perspective it is a brilliantly simple and scalable approach to 
building a massive network of real-time geo spatial communication.

Had we not gone with this approach we would have created yet another version of 
the wheel, another proprietary  black box protocol.

These are very exciting times to be in the AI/vision/automotive field and I 
really think we have a solid foundation to build upon.

So yes, I join the others in saying  I’m really looking forward to it become a 
proper RFC,

Thanks for your work on this !!

R

On Tue, 4 Aug 2020 at 18:18 
mailto:lisp-requ...@ietf.org>> wrote:
Send lisp mailing list submissions to
lisp@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/lisp
or, via email, send a message with subject or body 'help' to
lisp-requ...@ietf.org

You can reach the person managing the list at
lisp-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lisp digest..."


Today's Topics:

   1. I-D Action: draft-ietf-lisp-vpn-06.txt 
(internet-dra...@ietf.org)
   2. Re: Moving forward with lisp-nexagon (Lori Jakab (lojakab))
   3. Re: Moving forward with lisp-nexagon (Fabio Maino (fmaino))


--

Message: 1
Date: Mon, 03 Aug 2020 15:38:14 -0700
From: internet-dra...@ietf.org
To: mailto:i-d-annou...@ietf.org>>
Cc: lisp@ietf.org
Subject: [lisp] I-D Action: draft-ietf-lisp-vpn-06.txt
Message-ID: 
<159649429407.9381.18270622230431003...@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"


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 WG of the IETF.

Title   : LISP Virtual Private Networks (VPNs)
Authors : Victor Moreno
  Dino Farinacci
Filename: draft-ietf-lisp-vpn-06.txt
Pages   : 17
Date: 2020-08-03

Abstract:
   This document describes the use of the Locator/ID Separation Protocol
   (LISP) to create Virtual Private Networks (VPNs).  LISP is used to
   provide segmentation in both the LISP data plane and control plane.
   These VPNs can be created over the top of the Internet or over
   private transport networks, and can be implemented by Enterprises or
   Service Providers.  The goal of these VPNs is to leverage the
   characteristics of LISP - routing scalability, simply expressed
   Ingress site TE Policy, IP Address Family traversal, and mobility, in
   ways that provide value to network operators.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-vpn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-vpn-06
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-vpn-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/




--

Message: 2
Date: Tue, 4 Aug 2020 10:03:01 +
From: "Lori Jakab (lojakab)" mailto:loja...@cisco.com>>
To: Sharon Barkai 
mailto:40getnexar@dmarc.ietf.org>>
Cc: "lisp@ietf.org list" 
mailto:lisp@ietf.org>>
Subject: Re: [lisp] Moving forward with lisp-nexagon
Message-ID: 
mailto:f0930cf4-feab-43c7-877c-b3394ce39...@cisco.com>>
Content-Type: text/plain; 

Re: [lisp] Virtual meeting

[Victor Moreno (vimoreno)]

Another topic that I’ve been holding off on (in favor of finalizing publication 
of the RFC bis documents) is the federation of control planes. We’ve come 
across this requirement in many cross-organizational environments (the ones for 
which we started working on Uberlay). I’ll send a separate note (under a 
dedicated header) to the list so we can get warmed up ahead of the virtual 
interim.

In a nutshell, we have multiple providers in the Civil Aviation space who 
currently peer with each other in a very traditional manner (control and data 
plane peering). The policies enforced at these peering points are key to their 
business. The intent is to evolve this backbone to use LISP as the control 
plane and simplify the peering arrangement by focusing on enforcing the 
policies at the control plane level. Many benefits to pursuing this, which we 
can discuss as the WG gets involved.

Cheers,

-v

> On Mar 16, 2020, at 11:24 AM, Joel Halpern Direct 
>  wrote:
> 
> Thank you Alberto.  To see if folks want to engage on the topic, could you 
> write a short email describing the question and, if you can, some of the 
> things that you would like to discuss?
> 
> Folks, let's be clear.  I do expect we will have a virtual interim. Maybe 
> even more than one.  I would really like to see groundwork on the email list 
> so that any request by the chairs for folks to make time is for more than 
> just some presentations.
> 
> Thank you,
> Joel
> 
> On 3/16/2020 2:15 PM, Alberto Rodriguez Natal (natal) wrote:
>> Joel, all,
>> I'm in favor of having a virtual interim meeting. One of the points that I 
>> have on my personal list of "things to discuss when we have time" is the 
>> aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from 
>> some deeper discussion with the WG regarding, nonces, security associations, 
>> ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for 
>> discussion and get some opinions on an interim.
>> Thanks,
>> Alberto
>> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Support draft-nexagon wg adoption

[Victor Moreno (vimoreno)]

This is a space where the LISP model can make a big difference and something 
the WG should be spending time on. I support the adoption of the document by 
the WG.

-v


> On Nov 20, 2019, at 7:16 PM, Sharon Barkai  wrote:
> 
> As co-auth also support draft for interoperable edge brokering of shared EID 
> geo-state.
> 
> As “lisper” think mapped-overlay scales logically and/or algorithmically 
> addressable network-compute / multicast-channels.
> 
> * ref also Dino mobile node mcast demo
> 
> Combined believe this key to scale deployment per edge location for co-op 
> end-points for apps needing such termination / turn-around. 
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> 
>> On Nov 19, 2019, at 8:50 AM, Bruno Fernandez-Ruiz  wrote:
>> 
>> I believe the pub/sub + H3-server brokered model of communication fits 
>> naturally with LISP and addresses a hugely important networking requirement 
>> for continuously roaming mobility clients.
>> 
>> As such, I endorse the draft to be published as an informational RFC.
>> 
>> -b
>> 
>>> On 19 Nov 2019, at 06:36, Sharon Barkai  wrote:
>>> 
>>> Hey, following very productive session today and as discussed would like to 
>>> formally ask group for draft adoption. 
>>> 
>>> Cheers,
>>> Sharon
>>> 
>>> --szb
>>> Cell: +972.53.2470068
>>> WhatsApp: +1.650.492.0794
>>> ___
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

[Victor Moreno (vimoreno)]

This is very helpful Sharon. Thanks! Makes diving into the draft much more 
appealing now …

-v

> On Sep 18, 2019, at 10:30 PM, Sharon Barkai  
> wrote:
> 
> Thank you Victor.
> 
> Quick recap of mobility networks evolution:
> 
> 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was 
> specified over WiFi spectrum with basic safety messages (BSM) in which cars 
> conveyed their GPS and kinematics sensor events like hard-brake, sharp-turn.
> Additional payment and information messages were specified as well.   
> 
> 2. For privacy considerations road-side-units (RSU) were specified as well to 
> hand  MAC keys to be used so cars will not be tracked. This double 
> infrastructure presented a barrier so DSRC over cellular was specified CV2X.
> The 5G evolution is supposed to match the latency of peer to peer WiFi. 
> 
> 3. The peer to peer challenges however remained, the need to test every 
> product with every other product is a barrier for extending the protocol to 
> support  on vehicle vision and sensory annotations which evolved since - such 
> as machine vision and liadr. Also timing sequence for relaying  annotations 
> between vehicles remains a problem since both DSRC and CV2X have no memory 
> and cars drive away.
> 
> Addressable geo-states brokering solves timing, interoperability, and 
> extendability limitations, and, edge-processing address latency needs => 
> demonstrated in single-digit latencies in production environments, sub 5msecs 
> in labs.
> 
> From here selecting LISP as the layer3 protocol of choice the road is short 
> and explained in the draft:
> 
> o  The support for logical EIDs for states based on (de-facto) geo-spatial 
> standard grids
> 
> o controlling latency and high availability by routing to states at the edge
> 
> o supporting ephemeral EIDs for vehicles
> 
> o signal-free-multicast for limited cast of many geo-spatial channels
> 
> o the distributed connectionless scale
> 
> o the multi-vendor interoperability that allows for “bring your own XTR” to 
> protect geo-privacy
> 
> o the ability to overlay multiple cellular network providers and multiple 
> cloud-edge providers
> 
> .. are some of the features which make LISP a good choice for mobility VPNs. 
> Hope this helps.
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> 
>> On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno)  
>> wrote:
>> 
>> I think a thorough understanding of mobility requirements and dependencies 
>> and how LISP may or may not accommodate these scenarios is key. I would like 
>> to see us work on this and other mobility related drafts (e.g. Ground based 
>> LISP).
>> 
>> Victor
>> 
>>> On Sep 18, 2019, at 11:18 AM, Dino Farinacci  wrote:
>>> 
>>> I’m a side author on this document and more of a reviewer. But I’ll answer 
>>> your questions on behalf of a WG member.
>>> 
>>>> Before I get more privacy feedback (if I do) I want to know
>>>> 1) does the WG actually care about this?
>>> 
>>> I do. Because understanding in deep detail the use-cases, allows us to 
>>> understand if LISP has the necessary protocol features.
>>> 
>>>> 2) Is it ready for more extensive review?
>>> 
>>> Yes.
>>> 
>>>> I realize we have not adopted this document.  Some of this feedback is to 
>>>> help the chairs judge what to do when the authors do ask for adoption.
>>> 
>>> We are at a point of the protocol’s life where working on use-cases allows 
>>> more adoption. I am for making this a working group document (even though 
>>> the authors have not formally requested).
>>> 
>>> Dino
>>> 
>>> ___
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

[Victor Moreno (vimoreno)]

I think a thorough understanding of mobility requirements and dependencies and 
how LISP may or may not accommodate these scenarios is key. I would like to see 
us work on this and other mobility related drafts (e.g. Ground based LISP).

Victor

> On Sep 18, 2019, at 11:18 AM, Dino Farinacci  wrote:
> 
> I’m a side author on this document and more of a reviewer. But I’ll answer 
> your questions on behalf of a WG member.
> 
>> Before I get more privacy feedback (if I do) I want to know
>> 1) does the WG actually care about this?
> 
> I do. Because understanding in deep detail the use-cases, allows us to 
> understand if LISP has the necessary protocol features.
> 
>> 2) Is it ready for more extensive review?
> 
> Yes.
> 
>> I realize we have not adopted this document.  Some of this feedback is to 
>> help the chairs judge what to do when the authors do ask for adoption.
> 
> We are at a point of the protocol’s life where working on use-cases allows 
> more adoption. I am for making this a working group document (even though the 
> authors have not formally requested).
> 
> Dino
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt

[Victor Moreno (vimoreno)]

I support making this a WG document. We must complement the security provided 
for map replies in LISP-sec with mechanisms to secure map-requests and 
map-registers such as those proposed in ecdsa-auth.

Victor

> On Sep 11, 2018, at 6:04 PM, Colin Cantrell  wrote:
> 
> I support making this document a WG draft
> 
> Cheers,
> Colin Cantrell
> 
>> On Sep 11, 2018, at 2:29 PM, Dino Farinacci  wrote:
>> 
>> As an co-author, I support making this document a WG draft.
>> 
>> Thanks,
>> Dino
>> 
>>> On Sep 5, 2018, at 12:48 AM, Luigi Iannone  wrote:
>>> 
>>> 
>>> 
 On 5 Sep 2018, at 09:46, Luigi Iannone  wrote:
 
 Folks,
 
 As you can see from Dino’s email (below) the authors are requesting that 
 the document
 
 https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/
 
 be adopted as WG item.
 
 This email starts the usual 14 days call for adoption, this call will end 
 on
 Thursday the 19th September, 2018.
>>> 
>>> Small typo in the ending date: Wednesday 19th September, 2018.
>>> 
>>> Ciao
>>> 
>>> L.
>>> 
>>> 
>>> 
 
 Please email the WG list stating whether or not you support acceptance.
 
 If you email to support the acceptance of this document as a WG item, 
 please
 also indicate if you are able and willing to either contribute to, or 
 review, (or both) the draft.
 
 Sitting in silence does not indicate support, please respond appropriately.
 
 The Chairs
 Joel & Luigi
 
 
> On 4 Sep 2018, at 21:05, Dino Farinacci  wrote:
> 
> Folks, here is an update that reflects comments we received at the 
> Montreal presentation:
> 
> 
> 
> A diff file is included for your convenience. 
> 
> At this time, I would like to request this document for working group 
> adoption.
> 
> Thanks,
> Dino/Erik
> 
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org
>> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt
>> Date: September 4, 2018 at 12:00:14 PM PDT
>> To: 
>> Reply-To: internet-dra...@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> 
>> 
>>  Title   : LISP Control-Plane ECDSA Authentication and 
>> Authorization
>>  Authors : Dino Farinacci
>>Erik Nordmark
>>   Filename: draft-farinacci-lisp-ecdsa-auth-03.txt
>>   Pages   : 17
>>   Date: 2018-09-04
>> 
>> Abstract:
>> This draft describes how LISP control-plane messages can be
>> individually authenticated and authorized without a a priori shared-
>> key configuration.  Public-key cryptography is used with no new PKI
>> infrastructure required.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03
>> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-ecdsa-auth-03
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
 
>>> 
>> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] The LISP WG has placed draft-iannone-6834bis in state "In WG Last Call"

[Victor Moreno (vimoreno)]

Support

-v


On May 21, 2018, at 2:51 PM, Alberto Rodriguez-Natal 
> wrote:

+1

Alberto

On Mon, May 21, 2018 at 12:14 PM Gregg Schudel (gschudel) 
> wrote:
+1 support

> On May 21, 2018, at 10:42 AM, Dino Farinacci 
> > wrote:
>
> +1
>
> Dino
>
>> On May 21, 2018, at 10:29 AM, Fabio Maino (fmaino) 
>> > wrote:
>>
>> Support.
>>
>> Fabio
>>
>> On May 21, 2018 8:43 AM, IETF Secretariat 
>> > 
>> wrote:
>>
>> The LISP WG has placed draft-iannone-6834bis in state
>> In WG Last Call (entered by Joel Halpern)
>>
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-iannone-6834bis/
>>
>> Comment:
>> A small delta to bring RFC 6834 to proposed Standards.  Going directly to WG
>> last call to avoid slowing down other work, and because it is so small.
>> Please do speak up, either with support or objection.
>>
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

Best regards,
Gregg

--
:|:.:|:. | gregg schudel (ccie #9591 emeritus)  mobile: +1 571 332 
  cisco   | Tail-f software solutions architect   email: 
gschu...@cisco.com
Website: 
http://www.cisco..com/go/nsodevnet
--

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-rfc6833bis-10

[Victor Moreno (vimoreno)]

I have reviewed the document and I believe it is ready to progress to the next 
step and be handed to the AD.

-v


On Apr 5, 2018, at 7:35 AM, Luigi Iannone 
> wrote:

Hi All,

During our last meeting it was apparent that the work on the LISP document  
[https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-10]
seems done and the document ready for WG Last Call.

This email starts the usual two weeks WG Last Call, to end April 20th, 2018..

Please review this WG document and let the WG know if you agree that it is 
ready for handing to the AD.
If you have objections, please state your reasons why, and explain what it 
would take to address your concerns.

Thanks

Luigi & Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state "Call For Adoption By WG Issued"

[Victor Moreno (vimoreno)]

Support 

Victor

> On Apr 3, 2018, at 7:30 PM, Fabio Maino (fmaino)  wrote:
> 
> As an author, I support adoption of this document.
> 
> This is an important and much needed extension of the LISP protocol that 
> enable publish subscribe functionalities.
> 
> Fabio
> 
>> On 4/3/18 6:14 PM, IETF Secretariat wrote:
>> The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state
>> Call For Adoption By WG Issued (entered by Joel Halpern)
>> 
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-pubsub/
>> 
>> Comment:
>> As requested by the authors, calling for WG adoption.
> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

I think the new text is much better, unambiguous and addresses all concerns.

Thanks Dino,

-v

> On Mar 21, 2018, at 12:29 AM, Dino Farinacci  wrote:
> 
>> Could I not do the above even if the EID-prefix DID NOT EXIST? Or are we 
>> restricting any application of policy only to LISP EID-prefixes, and not to 
>> non-LISP prefixes? 
> 
> No, it would be either.
> 
>> The map-replies suggested in the new text would effectively be NMRs, 
>> correct? i.e. Map-replies with empty locator sets and the ACT bits set.
> 
> The definition of a Negative Map-Reply is one with a empty RLOC-set. I will 
> make that more clear in the definition and the description on how to return 
> different actions.
> 
>> If that is the intent, maybe we need to revise the definitions for NMR and 
>> ACT as I think right now there is some inconsistency/contradiction:
>> 
>> a) NMR definition - Issued in response to queries only for EIDs that DO NOT 
>> EXIST
>> b) ACT bits specification - for use in NMRs ONLY
>> c) New text describing how the ACT bits are used to specify forwarding 
>> behavior for EIDs that DO EXIST
> 
> Agree 100%. See new diff file.
> 
>> So NMRs are exclusive to non-existent or non-registered EIDs (a) and ACT 
>> bits are exclusive to NMRs (b). Yet (c) implies that NMRs will be used for 
>> EIDs that DO EXIST. So (c) contradicts (a).
> 
> No, not really. “Exist” is too general a term. We should say “not 
> registered”. 
> 
> Let me know if new text is better.
> 
> Thanks,
> Dino
> 
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

Thanks Dino,

I want to make sure I understand correctly. A couple of questions:


If the EID-prefix exists and there is a policy in the Map-Server to

have the requestor drop packets for the matching EID-prefix, 
then a

Drop/Policy-Denied action is returned. If the EID-prefix exists 
and

there is a authentication failure, then a Drop/Authentication-
failure action is returned. If either of these actions 
result as a
temporary state in policy or authentication then a 
Send-Map-Request
action with 1-minute TTL MAY be returned to allow the 
reqeustor to
retry the Map-Request.

Could I not do the above even if the EID-prefix DID NOT EXIST? Or are we 
restricting any application of policy only to LISP EID-prefixes, and not to 
non-LISP prefixes?

The map-replies suggested in the new text would effectively be NMRs, correct? 
i.e. Map-replies with empty locator sets and the ACT bits set.

If that is the intent, maybe we need to revise the definitions for NMR and ACT 
as I think right now there is some inconsistency/contradiction:

a) NMR definition - Issued in response to queries only for EIDs that DO NOT 
EXIST
b) ACT bits specification - for use in NMRs ONLY
c) New text describing how the ACT bits are used to specify forwarding behavior 
for EIDs that DO EXIST

So NMRs are exclusive to non-existent or non-registered EIDs (a) and ACT bits 
are exclusive to NMRs (b). Yet (c) implies that NMRs will be used for EIDs that 
DO EXIST. So (c) contradicts (a).

Text for (a)

   Negative Map-Reply:   A LISP Map-Reply that contains an empty
  Locator-Set. Returned in response to a Map-Request if the
  destination EID does not exist in the mapping database.
  Typically, this means that the "EID" being requested is an IP
  address connected to a non-LISP site.

Text for (b)

   ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
  other message type, these bits are set to 0 and ignored on
  receipt.  These bits are used only when the 'Locator Count' field
  is set to 0.  The action bits are encoded only in Map-Reply
  messages.  The actions defined are used by an ITR or PITR when a
  destination EID matches a negative Map-Cache entry.  Unassigned
  values SHOULD cause a Map-Cache entry to be created, and when
  packets match this negative cache entry, they will be dropped.


-v

On Mar 20, 2018, at 12:44 AM, Dino Farinacci 
> wrote:

On Mar 19, 2018, at 6:22 PM, Dino Farinacci 
> wrote:

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions

Thanks Victor. See new update enclosed. Let us know if you are good with the 
changes and the response below.

1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
LH, it is not spelled out anywhere. I assume this means Lisp Header.

It is a reference to the row in the diagram above:



Understood, but should we not spell out LISP Header somewhere rather than just 
using LH without spelling it out anywhere?

I can change it. See new diff.


3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
Forward action code. However the definition of the Map-reply message in section 
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG 
agrees I can suggest text that would generalize the recommended processing 
behaviors described in 8.3 to allow the inclusion and use of the specified 
actions in the case of NMRs.

Well the text below is correct and is explaining when a mapping entry DOES NOT 
exist. For all other actions, they are sent for entries that DO EXIST in the 
mapping database. And the reasons for sending the specific action type is 
documented in the Map-Reply ACT field description:

I agree that the text is correct, but I am pointing out that is not sufficient. 
If my policy is to drop traffic destined to an EID that is either not 
registered or not configured in the Mapping DB, how would I instruct the EID to 
drop the traffic? I would think I'd want to issue an NMR with action drop  (4 
or other). The spec currently doesn’t illustrate such actions. Text in 8.3 & 
8.4 prescribes that the NMR for non-configured or non-registered EIDs will 
always have an action of Native-Forward, but I need the action to be Drop (for 
example).

In the definitions section, the NMRs are defined as responses to queries for 
EIDs that DO NOT EXIST, in the text you pasted below, the ACT bits are defined 
as exclusive to the NMRs (set to 0 in any other message).  It is not clear to 
me how these actions can apply to entries that DO EXIST?

-v

Okay, I added some text.

Dino



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

> On Mar 19, 2018, at 6:22 PM, Dino Farinacci  wrote:
> 
>> Dear WG,
>> 
>> I did a quick review of rfc6833bis-08. Some comments/suggestions
> 
> Thanks Victor. See new update enclosed. Let us know if you are good with the 
> changes and the response below.
> 
>> 1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
>> LH, it is not spelled out anywhere. I assume this means Lisp Header.
> 
> It is a reference to the row in the diagram above:
> 
> 

Understood, but should we not spell out LISP Header somewhere rather than just 
using LH without spelling it out anywhere?

> 
> 
>> 2. Section 5.8. On page 27, there is a figure/header format showing the AD 
>> Type and Authentication Data Content, which is not referenced anywhere. 
>> Looks like it needs to be removed.
> 
> Nice find. When the text was moved from RFC6830, we mis-placed it in RFC6833.

Ack, good.

> 
>> 3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
>> Forward action code. However the definition of the Map-reply message in 
>> section 5.4 allows 8 possible action codes and specifies 6 possible actions. 
>> If the WG agrees I can suggest text that would generalize the recommended 
>> processing behaviors described in 8.3 to allow the inclusion and use of the 
>> specified actions in the case of NMRs. 
> 
> Well the text below is correct and is explaining when a mapping entry DOES 
> NOT exist. For all other actions, they are sent for entries that DO EXIST in 
> the mapping database. And the reasons for sending the specific action type is 
> documented in the Map-Reply ACT field description:

I agree that the text is correct, but I am pointing out that is not sufficient. 
If my policy is to drop traffic destined to an EID that is either not 
registered or not configured in the Mapping DB, how would I instruct the EID to 
drop the traffic? I would think I'd want to issue an NMR with action drop  (4 
or other). The spec currently doesn’t illustrate such actions. Text in 8.3 & 
8.4 prescribes that the NMR for non-configured or non-registered EIDs will 
always have an action of Native-Forward, but I need the action to be Drop (for 
example).

In the definitions section, the NMRs are defined as responses to queries for 
EIDs that DO NOT EXIST, in the text you pasted below, the ACT bits are defined 
as exclusive to the NMRs (set to 0 in any other message).  It is not clear to 
me how these actions can apply to entries that DO EXIST? 

-v

> 
>  ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
>  other message type, these bits are set to 0 and ignored on
>  receipt.  These bits are used only when the 'Locator Count' field
>  is set to 0.  The action bits are encoded only in Map-Reply
>  messages.  The actions defined are used by an ITR or PITR when a
>  destination EID matches a negative Map-Cache entry.  Unassigned
>  values SHOULD cause a Map-Cache entry to be created, and when
>  packets match this negative cache entry, they will be dropped.
>  The current assigned values are:
> 
>  (0) No-Action:  The Map-Cache is kept alive, and no packet
>  encapsulation occurs.
> 
>  (1) Natively-Forward:  The packet is not encapsulated or dropped
>  but natively forwarded.
> 
>  (2) Send-Map-Request:  The packet invokes sending a Map-Request.
> 
>  (3) Drop/No-Reason:  A packet that matches this Map-Cache entry is
>  dropped.  An ICMP Destination Unreachable message SHOULD be
>  sent.
> 
>  (4) Drop/Policy-Denied:  A packet that matches this Map-Cache
>  entry is dropped.  The reason for the Drop action is that a
>  Map-Request for the target-EID is being policy denied by
>  either an xTR or the mapping system.
> 
>  (5) Drop/Authentication-Failure:  A packet that matches this Map-
>  Cache entry is dropped.  The reason for the Drop action is
>  that a Map-Request for the target-EID fails an authentication
>  verification-check by either an xTR or the mapping system.
> 
> Thanks again,
> Dino
> 
> 
> 
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

These comments apply to version -09 of the document without any change.

-v


On Mar 19, 2018, at 2:18 PM, Victor Moreno (vimoreno) 
<vimor...@cisco.com<mailto:vimor...@cisco.com>> wrote:

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions



1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
LH, it is not spelled out anywhere. I assume this means Lisp Header.

2. Section 5.8. On page 27, there is a figure/header format showing the AD Type 
and Authentication Data Content, which is not referenced anywhere. Looks like 
it needs to be removed.

3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
Forward action code. However the definition of the Map-reply message in section 
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG 
agrees I can suggest text that would generalize the recommended processing 
behaviors described in 8.3 to allow the inclusion and use of the specified 
actions in the case of NMRs.

   8.3.  Map-Server Processing
   Once a Map-Server has EID-Prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.
   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map-Server first checks to see if the destination EID
   matches a configured EID-Prefix.  If there is no match, the Map-
   Server returns a Negative Map-Reply with action code "Natively-
   Forward" and a 15-minute TTL.  This MAY occur if a Map Request is
   received for a configured aggregate EID-Prefix for which no more-
   specific EID-Prefix exists; it indicates the presence of a non-LISP
   "hole" in the aggregate EID-Prefix.
   Next, the Map-Server checks to see if any ETRs have registered the
   matching EID-Prefix.  If none are found, then the Map-Server returns
   a Negative Map-Reply with action code "Natively-Forward" and a
   1-minute TTL.

   8.4 …

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
   table that covers the full EID space), it immediately returns a
   negative LISP Map-Reply, with action code "Natively-Forward" and a
   15-minute TTL.  To minimize the number of negative cache entries
   needed by an ITR, the Map-Resolver SHOULD return the least-specific
   prefix that both matches the original query and does not match any
   EID-Prefix known to exist in the LISP-capable infrastructure.


Regards,

-v





___
lisp mailing list
lisp@ietf.org<mailto:lisp@ietf.org>
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions



1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
LH, it is not spelled out anywhere. I assume this means Lisp Header.

2. Section 5.8. On page 27, there is a figure/header format showing the AD Type 
and Authentication Data Content, which is not referenced anywhere. Looks like 
it needs to be removed.

3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
Forward action code. However the definition of the Map-reply message in section 
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG 
agrees I can suggest text that would generalize the recommended processing 
behaviors described in 8.3 to allow the inclusion and use of the specified 
actions in the case of NMRs.

   8.3.  Map-Server Processing
   Once a Map-Server has EID-Prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.
   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map-Server first checks to see if the destination EID
   matches a configured EID-Prefix.  If there is no match, the Map-
   Server returns a Negative Map-Reply with action code "Natively-
   Forward" and a 15-minute TTL.  This MAY occur if a Map Request is
   received for a configured aggregate EID-Prefix for which no more-
   specific EID-Prefix exists; it indicates the presence of a non-LISP
   "hole" in the aggregate EID-Prefix.
   Next, the Map-Server checks to see if any ETRs have registered the
   matching EID-Prefix.  If none are found, then the Map-Server returns
   a Negative Map-Reply with action code "Natively-Forward" and a
   1-minute TTL.

   8.4 …

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
   table that covers the full EID space), it immediately returns a
   negative LISP Map-Reply, with action code "Natively-Forward" and a
   15-minute TTL.  To minimize the number of negative cache entries
   needed by an ITR, the Map-Resolver SHOULD return the least-specific
   prefix that both matches the original query and does not match any
   EID-Prefix known to exist in the LISP-capable infrastructure.


Regards,

-v





___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Review of RFC6833bis

[Victor Moreno (vimoreno)]

In addition to the comments provided by Alberto and Dino, I have some comments 
on the text in section 5 of the RFC. 

1. The text in section 5 currently prescribes that in response to a map-request 
for a non-registered or non-existent EID, an ITR should expect an NMR from the 
Map-Server (or Resolver) with action code “Natively-Forward” (this is stated in 
section 5.1 and re-stated in 5.3 and 5.4). Prescribing that this is to always 
be an NMR with a Native-Forward action is limiting. 

After trying to address a few use cases, it would be very useful if the 
specification allowed:

a. As an alternative to responding with an NMR, an implementation may respond 
to a Map-Request for a non-registered or non-existent EID with a “positive" 
map-reply inclusive of an RLOC-set that can be configured in the 
Mapping-System. The immediate use case this would address is that of not having 
to configure a PETR statically at every ITR, but have the map-replies include 
the PETR's RLOC information. This Map-Reply should have short TTLs and include 
covering/hole EID prefixes just as specified for the current NMRs, hence this 
differs from a map-reply for registered 0/0 EIDs.

b. The use of all action codes possible with the ACT bits (as defined in 
section 4.4) when Map-Replying with an NMR to a Map-Request for a 
non-registered or non-existent EID. As I read the text in section 5, it isn’t 
clear that other action codes are allowed, the text is focused solely on 
Natively-Forward, there are strong requirements to leverage the Drop action and 
particularly Drop/Policy-Denied.

2. There are multiple references to LISP-ALT in the text. Do we want to keep 
those references moving forward? Or can these be removed? The implementations I 
work with do not use ALT, but maybe there are others that do?

3. Section 5.3. Paragraph 2 is describing the behavior for the MS when there is 
a match on an EID “hole”. Section 5.3. suggests a 15 minute TTL, meanwhile 
section 5.1. suggests a 1 minute TTL for the same EID. I think it should be 1 
minute in both cases. 

I can contribute with text suggestions once we discuss the above on the list. 

-v


> On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal 
>  wrote:
> 
> Thanks for the responses Dino. I'll get back to you later this week.
> 
> Alberto
> 
> On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci  wrote:
>>> Hi all,
>>> 
>>> Wanted to send this before the meeting on Friday. I just completed a
>>> review of 6833bis, you can find my comments below. Like last time,
>>> extracts from the draft are copied and followed by my comments.
>>> 
>>> Thanks,
>>> Alberto
>> 
>> Thanks again Alberto for your comments. See my responses inline and a -07 
>> diff file.
>> 
>>> Map-Resolver:  A network infrastructure component that accepts LISP
>>> Encapsulated Map-Requests,
>>> 
>>>   • [AR] We could remove "Encapsulated" and just use "Map-Requests".
>>> A Map-Resolver may accept non-encapsulated Map-Requests as well.
>> 
>> No, they are “control-plane” encapsulated. I’ll make that more clear.
>> 
>>> Map-Register message:   A LISP message sent by an ETR to a Map-Server
>>> to register its associated EID-Prefixes.  In addition to the set of
>>> EID-Prefixes to register, the message includes one or more RLOCs to be
>>> used by the Map-Server when forwarding Map-Requests (re-formatted as
>>> Encapsulated Map-Requests) received through the database mapping
>>> system.
>>> 
>>>   • [AR] This may give the impression that the RLOCs on the
>>> Map-Register are only to forward Map-Requests, which is not the case
>>> in proxy-reply mode. I would suggest we rephrase this text as follows:
>>> "In addition to the set of EID-Prefixes to register, the message
>>> includes one or more RLOCs to be used to reach the ETR. The Map-Server
>>> uses these RLOCs when it has to forward Map-Requests (potentially
>>> re-formatted as Encapsulated Map-Requests) received through the
>>> database mapping system.”
>> 
>> I reworded.
>> 
>>> Map-Notify message:   A LISP message sent by a Map-Server to an ETR
>>> 
>>>   • [AR] I would replace "ETR" with "xTR" so we cover the PubSub
>>> behavior as well.
>> 
>> Can’t do that because an ITR does not get Map-Notifies as a response to a 
>> Map-Register. But I will add that ITRs get Map-Notifies to inform them of 
>> RLOC-set changes (for pubsub and signal-free-multicast use-cases).
>> 
>>> 
>>> For definitions of other terms -- notably Map-Request, Map-Reply,
>>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
>>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
>>> 
>>>   • [AR] I think that the definitions for Map-Request and Map-Reply
>>> should be moved here, and probably we should include the definition
>>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for
>>> control-plane messages, not the other way around.
>> 
>> They did. But the text you identified above was not changed. Changed 

Re: [lisp] 6833bis - NMR with locator count !=0

[Victor Moreno (vimoreno)]

> On Aug 22, 2017, at 10:22 AM, Dino Farinacci <farina...@gmail.com> wrote:
> 
> Here are some of my comments Victor.
> 
>> Would be mainly conveying the RLOCs of the feasible PETRs dynamically.
> 
> Anything or anyone can register mapping entries to the mapping database as 
> long as they are authenticated with the map-server. So I believe you can 
> achieve what you want with NO spec changes or additions to the protocol.

That would be great, we’ve been trying and haven’t had luck.

> 
>> As PETRs are brought on-line in the network, they can be configured/added in 
>> the Mapping System, rather than touching a multitude of ITRs.
> 
> Meaning you do not want ITRs to have to configure PETRs. That makes a ton of 
> sense for scale and management reasons.

Correct, we are looking at 1000s of ITRs in some of these networks.
> 
>> This would also allow a more elegant definition for the support of a default 
>> exit to the Internet in the Extranet case defined in the lisp-vpn draft. In 
>> this scenario, the RLOC record would convey the RLOC of the PETR plus the 
>> IID to which the Internet connects at the PETR.
> 
> An ITR has no idea where a packet really ends up. So if its encapsulating to 
> an ETR at the destination site or a PETR that decaps and sends the packet 
> many “native” hops to a non-EID destination, then so be it.

Correct, what is of interest is to have some sense of the likelihood of the 
mapping received changing and allow the ITR to check again. We are looking at 
the NMR as one way to indicate back to the ITR the nature of the mapping. 
Because the ITR can differentiate clearly between an NMR and a Positive MR, it 
can choose to treat the mappings differently. For example (maybe this is 
implementation specific) the cache-TTL assigned to the mapping received in an 
NMR may be in the order of minutes, vs. a mapping from a positive MR having a 
TTL in the order of hours..

> 
> I would not call these negative map-replies though. By definition, from the 
> spec, a negative map-reply is a map-reply with an RLOC-count of 0. 

What I am after is a map reply with the characteristics of an NMR (short TTL, 
dynamically calculated covering prefix for non-EID destination), but an 
RLOC-count > 0. If there is a way to encode this with a Positive MR, then we 
are covered. 

> 
> What many implemenationsn do is when they get a map-reply with an RLOC set of 
> 0, they then decide, via configuration to encapsulate to a list of xTRs. 
> Those xTRs are PETRs (by definition of the implementation).

We are trying to avoid the “decide, via configuration, to encapsulate to a list 
of xTRs”, but still have the ITR give the map-cache a short TTL. 

> 
> It could be useful to write up a very short draft indicating a “dynamic 
> use-case for PETRs”. But check the Interworking RFC to make sure we didn’t 
> cover this, in some form (even brief) in that spec.

I can do that if it helps. It would be very very brief.

-v

> 
> Cheers,
> Dino
> 
>> 
>> -v
>> 
>>> On Aug 21, 2017, at 11:12 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
>>> 
>>> Can you explain what information you are conveying with the RLOCs?  I think 
>>> we would need a clear use case before changing the spec.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 8/22/17 2:07 AM, Victor Moreno (vimoreno) wrote:
>>>> Dear WG,
>>>> As we put some of our specifications to the test in deployments, we have 
>>>> found the ability to return RLOCs dynamically in an NMR to be compelling 
>>>> in a variety of deployment scenarios. Particularly in Networks with 
>>>> multiple Internet exit points.
>>>> What are the thoughts of the group on allowing NMRs with a locator count 
>>>> !=0?
>>>> One option to indicate that a map-reply is an NMR could be to assign one 
>>>> of the reserved bits as an NMR flag.
>>>> Would like to gauge the inclination of the WG before proposing text/edits.
>>>> -v
>>>> ___
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6833bis - NMR with locator count !=0

[Victor Moreno (vimoreno)]

Thanks Joel,

That would be ideal, could you please shed some light on what you see as 
“suitable indications” in a map-reply?

The two things that are compelling about the NMR are:

1. Dynamic calculation of covering prefix for the non-EID requested
2. short TTL of the mapping so that we continue requesting more specifics (the 
ITR implementations usually know to assign a short TTL when the map-reply is an 
NMR [loc-count == 0])

If I can continue to achieve those without manually configuring the PETR RLOCs 
at the ITRs, we have what we need. But I didn’t see a way to do this in the 
framework of the current spec.

-v

> On Aug 22, 2017, at 7:40 AM, Joel M. Halpern <j...@joelhalpern.com> wrote:
> 
> Now speaking only as an individual:
> 
> If you want the Proxy ETR to be in the mapping system, wouldn't it make more 
> sense to have it register the address block for which it is serving as a 
> proxy?  With suitable indications so that ITRs which learn of it get back the 
> bits that tell them to continue askign about more specifics?  That would seem 
> to result in existing ITRs working with these newer PETRs without any changes.
> 
> Yours,
> Joel
> 
> On 8/22/17 2:32 AM, Victor Moreno (vimoreno) wrote:
>> Would be mainly conveying the RLOCs of the feasible PETRs dynamically.
>> As PETRs are brought on-line in the network, they can be configured/added in 
>> the Mapping System, rather than touching a multitude of ITRs.
>> This would also allow a more elegant definition for the support of a default 
>> exit to the Internet in the Extranet case defined in the lisp-vpn draft. In 
>> this scenario, the RLOC record would convey the RLOC of the PETR plus the 
>> IID to which the Internet connects at the PETR.
>> -v
>>> On Aug 21, 2017, at 11:12 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
>>> 
>>> Can you explain what information you are conveying with the RLOCs?  I think 
>>> we would need a clear use case before changing the spec.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 8/22/17 2:07 AM, Victor Moreno (vimoreno) wrote:
>>>> Dear WG,
>>>> As we put some of our specifications to the test in deployments, we have 
>>>> found the ability to return RLOCs dynamically in an NMR to be compelling 
>>>> in a variety of deployment scenarios. Particularly in Networks with 
>>>> multiple Internet exit points.
>>>> What are the thoughts of the group on allowing NMRs with a locator count 
>>>> !=0?
>>>> One option to indicate that a map-reply is an NMR could be to assign one 
>>>> of the reserved bits as an NMR flag.
>>>> Would like to gauge the inclination of the WG before proposing text/edits.
>>>> -v
>>>> ___
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6833bis - NMR with locator count !=0

[Victor Moreno (vimoreno)]

Would be mainly conveying the RLOCs of the feasible PETRs dynamically.
As PETRs are brought on-line in the network, they can be configured/added in 
the Mapping System, rather than touching a multitude of ITRs.
This would also allow a more elegant definition for the support of a default 
exit to the Internet in the Extranet case defined in the lisp-vpn draft. In 
this scenario, the RLOC record would convey the RLOC of the PETR plus the IID 
to which the Internet connects at the PETR.

-v

> On Aug 21, 2017, at 11:12 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
> 
> Can you explain what information you are conveying with the RLOCs?  I think 
> we would need a clear use case before changing the spec.
> 
> Yours,
> Joel
> 
> On 8/22/17 2:07 AM, Victor Moreno (vimoreno) wrote:
>> Dear WG,
>> As we put some of our specifications to the test in deployments, we have 
>> found the ability to return RLOCs dynamically in an NMR to be compelling in 
>> a variety of deployment scenarios. Particularly in Networks with multiple 
>> Internet exit points.
>> What are the thoughts of the group on allowing NMRs with a locator count !=0?
>> One option to indicate that a map-reply is an NMR could be to assign one of 
>> the reserved bits as an NMR flag.
>> Would like to gauge the inclination of the WG before proposing text/edits.
>> -v
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] 6833bis - NMR with locator count !=0

[Victor Moreno (vimoreno)]

Dear WG,

As we put some of our specifications to the test in deployments, we have found 
the ability to return RLOCs dynamically in an NMR to be compelling in a variety 
of deployment scenarios. Particularly in Networks with multiple Internet exit 
points. 

What are the thoughts of the group on allowing NMRs with a locator count !=0?

One option to indicate that a map-reply is an NMR could be to assign one of the 
reserved bits as an NMR flag.

Would like to gauge the inclination of the WG before proposing text/edits.

-v
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of LISP Anonymity [draft-farinacci-lisp-eid-anonymity-02.txt]

[Victor Moreno (vimoreno)]

Support.

Victor

On Jul 26, 2017, at 2:41 AM, Luigi Iannone 
> wrote:

Hi All,

During the 99th IETF authors of the document 
draft-farinacci-lisp-eid-anonymity-02.txt
[https://tools.ietf.org/html/draft-farinacci-lisp-eid-anonymity-02]
asked for WG adoption. Meeting participants expressed consensus on adoption.

This message begins the two weeks call for WG adoption to confirm the meeting 
outcome.
The call ends on  August 3rd 2017.

Please respond to the LISP mailing list with any statements of approval or 
disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and the WG is expected to
  modify the document's content until there is WG consensus that the content is 
solid.
  Therefore, please don't oppose adoption just because you want to see changes 
to its content.

- If you have objections to adoption of the document, please state your reasons 
why,
  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues and we 
can
  begin a dialog about how best to address them.


Luigi and Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-te-12.txt

[Victor Moreno (vimoreno)]

support.

-v

On Apr 12, 2017, at 2:30 AM, Luigi Iannone 
> wrote:

Hi All,

During the 98th IETF authors of the document draft-farinacci-lisp-te-12.txt
[https://tools.ietf.org/html/draft-farinacci-lisp-te-12]
asked for WG adoption. Meeting participants expressed consensus on adoption.

This message begins the two weeks call for WG adoption to confirm the meeting 
outcome.
The call ends on  April 27th 2017.

Please respond to the LISP mailing list with any statements of approval or 
disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and the WG is expected to
  modify the document’s content until there is WG consensus that the content is 
solid.
  Therefore, please don’t oppose adoption just because you want to see changes 
to its content.

- If you have objections to adoption of the document, please state your reasons 
why,
  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues and we 
can
  begin a dialog about how best to address them.


Luigi and Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-moreno-lisp-vpn-00.txt

[Victor Moreno (vimoreno)]

Support

-v

On Apr 12, 2017, at 2:29 AM, Luigi Iannone 
> wrote:

Hi All,

During the 98th IETF authors of the document draft-moreno-lisp-vpn-00.txt
[https://tools.ietf.org/html/draft-moreno-lisp-vpn-00]
asked for WG adoption. Meeting participants expressed consensus on adoption.

This message begins the two weeks call for WG adoption to confirm the meeting 
outcome.
The call ends on  April 27th 2017.

Please respond to the LISP mailing list with any statements of approval or 
disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and the WG is expected to
  modify the document’s content until there is WG consensus that the content is 
solid.
  Therefore, please don’t oppose adoption just because you want to see changes 
to its content.

- If you have objections to adoption of the document, please state your reasons 
why,
  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues and we 
can
  begin a dialog about how best to address them.


Luigi and Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-portoles-lisp-eid-mobility-02.txt

[Victor Moreno (vimoreno)]

Support

-v

On Apr 12, 2017, at 2:28 AM, Luigi Iannone 
> wrote:

Hi All,

During the 98th IETF authors of the document 
draft-portoles-lisp-eid-mobility-02.txt
[https://tools.ietf.org/html/draft-portoles-lisp-eid-mobility-02]
asked for WG adoption. Meeting participants expressed consensus on adoption.

This message begins the two weeks call for WG adoption to confirm the meeting 
outcome.
The call ends on  April 27th 2017.

Please respond to the LISP mailing list with any statements of approval or 
disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and the WG is expected to
  modify the document’s content until there is WG consensus that the content is 
solid.
  Therefore, please don’t oppose adoption just because you want to see changes 
to its content.

- If you have objections to adoption of the document, please state your reasons 
why,
  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues and we 
can
  begin a dialog about how best to address them.


Luigi and Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call fo document draft-ietf-lisp-signal-free-multicast-02.txt

[Victor Moreno (vimoreno)]

This is my formal/obvious vote to move the document forward.

-v

> On Mar 27, 2017, at 9:34 AM, Dino Farinacci  wrote:
> 
> Victor and I (co-authors) believe this should be moved to IESG review. That 
> might be obvious, but if the authors don’t vote . . .  ;-)
> 
> Dino
> 
>> On Mar 27, 2017, at 9:06 AM, Luigi Iannone  wrote:
>> 
>> Folks,
>> 
>> the chairs did not receive any feedback concerning this call.
>> 
>> Remember that silence is not consensus.
>> 
>> We extend the WG Last Call until next Monday April 3rd, 2017.
>> 
>> Please speak up.
>> 
>> Luigi & Joel
>> 
>>> On 11 Mar 2017, at 10:22, Luigi Iannone  wrote:
>>> 
>>> Hi All,
>>> 
>>> The authors of the LISP-Signal-Free-Multicast document 
>>> [https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-02] 
>>> asked for WG Last Call. 
>>> 
>>> This email starts the usual two weeks WG Last Call, to end March  27th, 
>>> 2017.
>>> 
>>> Please review this WG document and let the WG know if you agree that it is 
>>> ready for handing to the AD.
>>> If you have objections, please state your reasons why, and explain what it 
>>> would take to address your concerns.
>>> 
>>> Thanks
>>> 
>>> Luigi & Joel
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for Agenda Items

[Victor Moreno (vimoreno)]

Hi Luigi,

I have the following two topics which I would like to present to the WG:

Victor Moreno, Virtual Private Networks and Extranets, 10 minutes
Victor Moreno, EID Mobility, 5 minutes.

Thanks in advance,

-v

On Mar 8, 2017, at 2:10 AM, Luigi Iannone 
> wrote:

Hi All,

We have a time slot during the next IETF in Chicago so it is time to fix the 
agenda for our WG.
The LISP WG  is scheduled to meet on Thursday, March 30th, 2017, from 13:00 to 
15:00 (2 hours)

Please send your requests for agenda items (Presenter’s name, ppt title, slot 
duration)
to lisp-cha...@tools.ietf.org by Wednesday 
15th March, 2017.

Thanks

Joel & Luigi

On 4 Mar 2017, at 00:55, IETF Secretariat 
> wrote:

Dear Luigi Iannone,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

lisp Session 1 (2:00:00)
   Thursday, Afternoon Session I 1300-1500
   Room Name: Zurich C size: 100
   -



Request Information:


-
Working Group Name: Locator/ID Separation Protocol
Area Name: Routing Area
Session Requester: Luigi Iannone

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 50
Conflicts to Avoid:
First Priority: rtgwg nvo3 i2rs sidr grow sfc nfvrg pim intarea
Second Priority: mboned icnrg irtfopen idr spring bier maprg
Third Priority: l2tpext bess


People who must be present:
 Joel M. Halpern
 Wassim Haddad
 Deborah Brungard
 Luigi Iannone

Resources Requested:
 Meetecho support in room

Special Requests:

-


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Fwd: New Version Notification for draft-portoles-lisp-eid-mobility-00.txt

[Victor Moreno (vimoreno)]

Dear Workgroup,

Please refer to this recent draft submission for context on the Agenda slot 
this afternoon referring to the unified control plane work.

Kind Regards,

Victor

Begin forwarded message:

From: >
Subject: New Version Notification for draft-portoles-lisp-eid-mobility-00.txt
Date: April 7, 2016 at 12:08:32 PM GMT-3
To: Dino Farinacci >, Vrushali 
Ashtaputre >, Marc 
Portoles-Comeras >, "Victor 
Moreno" >, Marc Portoles Comeras 
>, Fabio Maino 
>


A new version of I-D, draft-portoles-lisp-eid-mobility-00.txt
has been successfully submitted by Fabio Maino and posted to the
IETF repository.

Name: draft-portoles-lisp-eid-mobility
Revision: 00
Title: LISP L2/L3 EID Mobility Using a Unified Control Plane
Document date: 2016-04-07
Group: Individual Submission
Pages: 20
URL:
https://www.ietf.org/internet-drafts/draft-portoles-lisp-eid-mobility-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-portoles-lisp-eid-mobility/
Htmlized:   https://tools.ietf.org/html/draft-portoles-lisp-eid-mobility-00


Abstract:
  The LISP control plane offers the flexibility to support multiple
  overlay flavors simultaneously.  This document specifies how LISP can
  be used to provide control-plane support to deploy a unified L2 and
  L3 overlay solution, as well as analyzing possible deployment options
  and models.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast?

[Victor Moreno (vimoreno)]

Support

-v

On Dec 9, 2015, at 2:36 AM, Alberto Rodriguez-Natal 
> wrote:

Support

On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern 
> wrote:
This is a call for adoption  of draft-farinacci-lisp-signal-free-multicast.
Please speak up if you support or oppose adoption of this document.  It has 
been presented multiple times to the working group, generally to positive 
reception as far as I can tell.

This call will last two weeks, until CoB 21-December-2015.

Yours,
Joel

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Editorial error in RFC 6830

[Victor Moreno (vimoreno)]

Hello WG, 

I found the following editorial error, I understand text fixes to the RFC are 
currently being collected.

Negative mapping entries are introduced in section 3 (page 8) and therein is a 
cross-reference to section 6.1.5 for the well defined actions associated with a 
negative map reply. The cross referenced actions are actually documented in 
section 6.1.4, not 6.1.5. The cross-reference needs to be corrected to 6.1.4.

Regards,

-v

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-ermagan-lisp-yang-01.txt - Call for WG Adoption

[Victor Moreno (vimoreno)]

Approve/support

-v

On Aug 9, 2015, at 2:57 PM, Luigi Iannone 
g...@gigix.netmailto:g...@gigix.net wrote:

Hi All,

The authors of the document draft-ermagan-lisp-yang-01.txt
[https://tools.ietf.org/html/draft-ermagan-lisp-yang-01]
asked for WG adoption.

This message begins the two weeks call for WG adoption.
The call ends on  August 24th 2015.

Please respond to the LISP mailing list with any statements of approval or 
disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and the WG is expected to
  modify the document’s content until there is WG consensus that the content is 
solid.
  Therefore, please don’t oppose adoption just because you want to see changes 
to its content.

- If you have objections to adoption of the document, please state your reasons 
why,
  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues and we 
can
  begin a dialog about how best to address them.


Luigi and Joel
___
lisp mailing list
lisp@ietf.orgmailto:lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] [EXTENDED] draft-saucez-lisp-impact-07 - Call for WG Adoption

[Victor Moreno (vimoreno)]

+ 1

Victor

 On Dec 22, 2014, at 10:51 AM, Dino Farinacci farina...@gmail.com wrote:
 
 I like option (1) and think the document should be adopted.
 
 Dino
 
 On Dec 22, 2014, at 7:12 AM, Joel M. Halpern j...@joelhalpern.com wrote:
 
 To amplify Luigi's comment, we have several choices:
 1) We can use this document as the basis for the working group action to 
 address the milestone.
 2) We can use something else as a basis for working group action to address 
 the milestone.
 3) We can go fight about whether this matters because we don't want to do 
 this.
 
 If you like option (1), tell us you want the document adopted.
 If you like option (2), please say so and give us some idea of what 
 different looks like.  Best if you offer to provide a draft by a date, but 
 even just a paragraph or two on what different is would help us understand 
 your opposition.
 If you like (3), please explain.  That path seems likely to waste more time 
 than producing a good document.  Particularly since we have what looks to 
 the chairs like a very good start on this deliverable.
 
 Speak up, please.
 
 Yours,
 Joel
 
 On 12/22/14 10:08 AM, Luigi Iannone wrote:
 Hi All,
 
 the two weeks have elapsed since the beginning of the WG Adoption Call
 for draft-saucez-lisp-impact-07.
 
 There was actually very little reaction on this call.
 
 Silence does not help to make a decision, one way or another.
 
 Recall that our charter explicitly state that we will work on A
 description of the impacts of LISP”.
 
 The WG Adoption Call is extended for another two weeks (until 5th
 January 2015).
 
 Please take this opportunity to express your opinion on this document.
 
 Thanks
 
 Luigi  Joel
 
 On 04 Dec 2014, at 12:27, Luigi Iannone g...@gigix.net
 mailto:g...@gigix.net wrote:
 
 Hi All,
 
 During the 91st IETF authors of the draft-saucez-lisp-impact-07
 [https://tools.ietf.org/html/draft-saucez-lisp-impact-07]
 asked for WG adoption. Meeting participants expressed consensus on
 adoption.
 
 This message begins the two weeks call for WG adoption to confirm the
 meeting outcome.
 The call ends on  December 19th 2014.
 
 Please respond to the LISP mailing list with any statements of
 approval or disapproval.
 
 Recall that:
 
 - This is not WG Last Call. The document is not final, and the WG is
 expected to
 modify the document’s content until there is WG consensus that the
 content is solid.
 Therefore, please don’t oppose adoption just because you want to see
 changes to its content.
 
 - If you have objections to adoption of the document, please state
 your reasons why,
 and explain what it would take to address your concerns.
 
 - If you have issues with the content, by all means raise those issues
 and we can
 begin a dialog about how best to address them.
 Luigi and Joel
 
 ___
 lisp mailing list
 lisp@ietf.org
 https://www.ietf.org/mailman/listinfo/lisp
 
 ___
 lisp mailing list
 lisp@ietf.org
 https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)

[Victor Moreno (vimoreno)]

+1

I am however interested in the comparison, but I don't see it as part of an 
introduction or other lisp specification document 
Victor

 On Aug 11, 2014, at 4:33 PM, Dino Farinacci farina...@gmail.com wrote:
 
 We should not compare LISP to any other protocol. We should define what LISP 
 is. BGP and LISP solve different problems.
 
 Dino
 
 On Aug 11, 2014, at 4:13 PM, Ronald Bonica rbon...@juniper.net wrote:
 
 Darrel,
 
 Clearly, this is a WG document and the entire WG gets a chance to review, 
 accept or reject a contribution. That goes without saying for any document.
 
  
Ron
 
 -Original Message-
 From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
 Sent: Monday, August 11, 2014 7:10 PM
 To: Ronald Bonica
 Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list
 Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
 
 Doing the same
 
 I mentioned that I'd want to see the text before supporting (or opposing) 
 its
 inclusion...  So adding sections seems somewhat premature.
 
 
 -D
 On Aug 11, 2014, at 3:55 PM, Ronald Bonica rbon...@juniper.net wrote:
 
 This time adding the folks who I dropped accidentally
 
 Darrel,
 
 Fair enough.
 
 Could the editors leave an empty section between the sections that are
 now numbered 6.4 and 6.5. The Title of that section is Differences Between
 LISP and BGP. I will provide text within the next week or so.
 
 Ron
 
 
 -Original Message-
 From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
 Sent: Monday, August 11, 2014 1:29 PM
 To: Ronald Bonica
 Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list
 Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
 
 
 On Aug 11, 2014, at 9:59 AM, Ronald Bonica rbon...@juniper.net wrote:
 
 
 In order to help the reader understand the difference between LISP
 and
 BGP, it might be a good idea to add a few pages that compare and
 contrast the two. It should answer the following questions:
 
 - In BGP, how does the producer of a route know that it is time to
 push it
 - In LISP, how does the consumer of a route know that it is time to
 pull it
 - In BGP, what happens when the control path between the producer
 and
 consumer of a route becomes degraded or unusable
 - In LISP, what happens when the control path between the producer
 and
 consumer of a route becomes degraded or unusable
 
 
 Ron
 
 I eagerly await your suggested text.
 
 -D
 
 ___
 lisp mailing list
 lisp@ietf.org
 https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] New Version Notification for draft-moreno-lisp-datacenter-deployment-00.txt

[Victor Moreno (vimoreno)]

Dear LISP WG,

This is a new LISP Deployment draft, and this one is centered on how to deploy
LISP within and across Data Centers.  We¹d like to
request comments on this.

Terry/Joel, we¹d also like a 5 minute slot at IETF89 to present this draft to 
the WG in London.

Thanks in advance,

Victor

On Feb 14, 2014, at 9:39 AM, internet-dra...@ietf.org wrote:

 
 A new version of I-D, draft-moreno-lisp-datacenter-deployment-00.txt
 has been successfully submitted by Victor Moreno and posted to the
 IETF repository.
 
 Name: draft-moreno-lisp-datacenter-deployment
 Revision: 00
 Title:LISP Deployment Considerations in Data Center Networks
 Document date:2014-02-14
 Group:Individual Submission
 Pages:20
 URL:
 http://www.ietf.org/internet-drafts/draft-moreno-lisp-datacenter-deployment-00.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-moreno-lisp-datacenter-deployment/
 Htmlized:   
 http://tools.ietf.org/html/draft-moreno-lisp-datacenter-deployment-00
 
 
 Abstract:
   This document discusses scenarios and implications of LISP based
   overlay deployment in the Data Center.  The alternatives for
   topological location of the different LISP functions are analyzed in
   the context of the most prevalent Data Center topologies.  The role
   and deployment of LISP in the Wide Area Network and Data Center
   Interconnection are also discussed.
 
 
 
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 The IETF Secretariat
 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-xu-softwire-ip-in-udp

[Victor Moreno (vimoreno)]

LISP follows the procedures and principles described in this draft
inherently.

These may actually be described in one of the LISP drafts already actually.

-v


On 12/30/12 12:45 PM, Damien Saucez damien.sau...@gmail.com wrote:

Hello,

Interesting document, have you ever though of LISP to do that?

Regards,

Damien Saucez
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP (re-)Charter discussion

[Victor Moreno (vimoreno)]

LISP is a bit unique in that it can enable many applications
concurrently.

If the effort for each application is spun off to different groups, each
thread will evolve independently and with that the cohesion of the
protocol may quickly be lost.

IMO it is important that the WG retains ownership/authority over all
things LISP.

-v

 -Original Message-
 From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf
Of
 Terry Manderson
 Sent: Monday, September 26, 2011 9:17 PM
 To: Dino Farinacci (dino)
 Cc: lisp@ietf.org
 Subject: Re: [lisp] LISP (re-)Charter discussion
 
 Thanks Dino,
 
 I encourage all LISP WG members to reflect on the questions below and
voice
 an opinion.
 
 To paraphrase what Dino has written, one proposal (and Dino correct me
if
 I've oversimplified) is that the LISP WG should become a working group
that
 contains ALL things LISP. So wherever a body of work uses LISP
 encapsulation, or LISP mapping it may gravitate to here to maintain
LISP
 interoperability and (where appropriate) protocol cohesion.
 
 ..discuss.
 
 :)
 
 Cheers
 Terry
 
 
 On 23/09/11 3:24 AM, Dino Farinacci d...@cisco.com wrote:
 
  Terry, what I would like to know first and foremost, before adding
any
  specific feature or use-cases to the charter is if they *should*
belong
 in the
  LISP working group charter versus being owne by another working
group.
 And
  what the working group thinks about this. I will give some examples
to
 get
  some clarity and to be more specific.
 
  (1) LISP could be used for many data-center use-cases.
  (2) LISP could be used for device mobility.
  (3) LISP could be used as a IPv6 coexistence solution while
delivering
 route
  table reduction and low opex multihoming.
  (4) LISP could be used as a VPN solution.
  (5) The mapping database could be used for other applications like
 keeping
  track of multicast group membership.
 
  So, to enumerate each one:
 
  For (1), does the LISP WG take this on or is there a data-center
specific
  protocol solution working group (ARMD is not that working group
because
 it is
  a requirement definition working group)?
 
  For (2), the MOBOPTs IRTF research group seem to take interest in
LISP-
 MN.
  Does it do the initial work and have it spin off a mobility working
 group,
  which there are many already. To add, there is a cross-product issue
too
 since
  LISP-Multicast can run in a LISP-MN implementation and there is a
 multimob
  working group already established.
 
  For (3), there are zillions of solutions and places where this
occurs
 over the
  last decade, I would suggest not spinning another working group for
this
 and
  have the LISP working group be address-family agnostic which would
also
  include MAC addressing as a address-family as well a GPS
coordinates.
 
  For (4), again, coupled with (3), LISP can do L2-over-L3,
L3-over-L3, as
 well
  as the other 2 combinations, does the VPN use-case stay in the LISP
 working
  group or is it fragmented to be taken to each L2VPN and L3VPN
working
 groups.
 
  For (5), we do not want to error where everything is put into DNS
 (because it
  is the only applicaiton level wide-area/multi-organizational
distributed
  database). In our case the mapping database. And moreoever, if the
use-
 case
  functionality is distributed to other working groups, will there be
 design
  change requests to the mapping database design coming from too many
 source
  points.
 
  As you can see, this can get very complex and confusing and could
result
 in
  design fragmentation and opportunity for competitive proposals. All
which
 turn
  out to add more inefficiencies to the protocol design process which
 nearly
  always results in undeployable compromises.
 
  Dino
 
  On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote:
 
  Hi Folks,
 
  In Prague there was no strong consensus on modifying the LISP
Charter
 from
  what it currently is, perhaps only updating the existing
 Goals/Milestones.
 
  So no clear decision could be made. What I would like to do is push
out
 a
  'idea generating' draft charter that is _almost_ identical to what
we
 have
  today.
 
  You can find the existing charter here:
  https://datatracker.ietf.org/wg/lisp/charter/
 
  The draft is below.
 
  So in light of such an approach, Joel and I discussed some work
items
 that
  came from what was said at the mic in Prague and to us
individually.
 
  They are:
 
  * Finish the deployment document
  * Get the two security documents done
  * Get an operational document at least started, which should
include
  cache management and ETR synchronization techniques.
  * Either in the second security document, or in complementary
documents
 we
  need to evaluate the security threat to cache maintenance, and
  evaluate the applicability and coverage we get from a reuse of SIDR
  technology.
 
  Is anything not represented here that you believe necessary? and
 conversely
  is there something here that is out of scope in your eyes?
 
  Are there