Re: [lisp] Moving draft-ietf-lisp-name-encoding to standard track?

[Lori Jakab]

Support.

-Lori

On 1/22/24 11:55 PM, Marc Portoles Comeras (mportole) wrote:


I also support moving this document to Standard track

*From: *lisp  on behalf of Victor Moreno 


*Date: *Friday, January 12, 2024 at 7:57 AM
*To: *Jordi Paillissé 
*Cc: *lisp@ietf.org 
*Subject: *Re: [lisp] Moving draft-ietf-lisp-name-encoding to standard 
track?


I support moving this document to the standards track.

Victor

On Fri, Jan 12, 2024 at 3:51 AM Jordi Paillissé 
 wrote:


Support!

Jordi

El 11/1/24 a les 18:34, Fabio Maino (fmaino) ha escrit:

I support moving this document to standard track

Fabio

*From: *lisp 
 on behalf of Luigi Iannone
 
*Date: *Thursday, January 11, 2024 at 4:53 AM
*To: *LISP mailing list list 

*Cc: *lisp-cha...@ietf.org 

*Subject: *[lisp] Moving draft-ietf-lisp-name-encoding to
standard track?

Hi All,

Happy new year!

As you may have seen from Alberto’s shepherd review of the
name encoding document, it is suggested to move the document
to standard track.

Jim Guichard (our AD) is OK as long as the WG is OK with this
change and that deployment experience is added to the document.

Hence, this email opens a two weeks call to check if you agree
with the change.

Please reply to this email stating whether you are in favor or
you are against.

(Silence does not count)

Please reply.

Ciao

L.

Begin forwarded message:

*From: *"Alberto Rodriguez-Natal \(natal\)"



*Subject: [lisp] Shepherd's review of
draft-ietf-lisp-name-encoding*

*Date: *December 28, 2023 at 12:00:33 GMT+1

*To: *"lisp@ietf.org" 
 

Hi all,

The shepherd’s review of the LISP Distinguished Name
Encoding has been posted. The document is in good shape
and minor identified nits have been fixed. Please find the
review here:


https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/shepherdwriteup/



However, as part of the review, it was raised the question
if the document is in the right stream (currently in
Experimental). Given that there are known implementations
of the spec and that it has been running in production for
some time, my suggestion is to consider moving this
document to Standards track instead.

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

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

[Lori Jakab (lojakab)]

Hi,

I think the document is ready to be handed to the AD.

Best regards,
-Lori

> On Feb 3, 2021, at 6:57 PM, Sharon Barkai 
>  wrote:
> 
> Thank you Luigi Joel.
> 
> We are working to add LISP based digital-twin interface for road segments to 
> the AECC auto-edge. The roll of this interface is to throttle the pipes: car 
> access to edge, edge to cloud by:
> 
> 1. Recording car EID data-handles in tile EID ledgers for selective uploads 
> per quota
> 2. Aggregating coalescing filtering uploads per tile for reduced feed to 
> cloud applications
> 
> This is hard to do with an IETF draft so very much appreciate show of support 
> even though its the 2nd such poll... 
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> 
>> On Feb 3, 2021, at 17:25, Luigi Iannone  wrote:
>> 
>> Hi All,
>> 
>> The authors of  draft-ietf-lisp-nexagon submitted the current version back 
>> in October solving issues raised during SECDIR review.
>> No further comments have been raised and the authors consider the document 
>> stable and ready for  WG Last Call.
>> 
>> This email open the usual two weeks Working Group Last Call, to end February 
>> 17th, 2021.
>> 
>> Please review this WG document and let the WG know if you agree that it is 
>> ready to be handed over to the AD.
>> If you have objections, please state your reasons why, and explain what it 
>> would take to address your concerns.
>> 
>> NOTE: silence IS NOT consensus!
>> 
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Lori Jakab (lojakab)]

Hi,

I think the document is ready to be handed to the AD.

Best regards,
-Lori

On 1/13/21 8:20 AM, Luigi Iannone wrote:
Hi All,

The authors of  draft-ietf-lisp-pubsub submitted a new version addressing the 
issues raised during SECDIR review.
The document seems mature and stable and authors are asking for formal WG Last 
Call.

This email open the usual two weeks Working Group Last Call, to end January 
28th, 2021.

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

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Lori Jakab (lojakab)]

On Sep 27, 2020, at 9:36 AM, Dino Farinacci  wrote:
> 
> I did not see any objections for this request but I didn’t see any specific 
> support either. Can we get some replies if you support this. Otherwise, it 
> will continue to reside for more than 4 years as an individual submission.

I’m supporting the draft to become a WG document.

-Lori

> 
> Thanks in advance,
> Dino
> 
>> On Sep 14, 2020, at 11:49 AM, Dino Farinacci > > wrote:
>> 
>> 
>> 
> 
>> 
>> I would like to make this individual submission a working group document. 
>> I’d like to hear if there are any objections. And then I would like it to 
>> start a WG last call.
>> 
>> The document is a simple encoding of an ASCII string for an EID or RLOC 
>> record using AFI=17 (distinguished-name). It has been active since 2016. I 
>> believe its time to do something with it.
>> 
>> Thanks in advance,
>> Dino
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp



smime.p7s
Description: S/MIME cryptographic signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-farinacci-lisp-name-encoding-10.txt

[Lori Jakab (lojakab)]

Hi,

Just wanted to mention to the WG that support for decoding Distinguished Name 
Encoding in Wireshark was accepted into the master branch and will be part of 
the 3.4.x stable release series.

https://gitlab.com/wireshark/wireshark/-/commit/dc4a5b5addcf990589f7a1afa6963d9de9a5f2b2
 

https://gitlab.com/wireshark/wireshark/-/commit/acbcfefa7ebe2b92d4c2e901c5b2c5b3c6271fe4
 


-Lori

> On Aug 31, 2020, at 6:07 AM, 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 WG of the 
> IETF.
> 
>Title   : LISP Distinguished Name Encoding
>Author  : Dino Farinacci
>   Filename: draft-farinacci-lisp-name-encoding-10.txt
>   Pages   : 6
>   Date: 2020-08-30
> 
> Abstract:
>   This draft defines how to use the AFI=17 Distinguished Names in LISP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-farinacci-lisp-name-encoding-10
> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-name-encoding-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-name-encoding-10
> 
> 
> 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/
> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp



smime.p7s
Description: S/MIME cryptographic signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Moving forward with lisp-nexagon

[Lori Jakab (lojakab)]

Hi Sharon,

I think this draft addresses some really interesting use cases, so I would like 
to see it advanced.

-Lori

> On Aug 2, 2020, at 6:44 PM, Sharon Barkai 
>  wrote:
> 
> We have presented the nexagon
>  https://tools.ietf.org/html/draft-ietf-lisp-nexagon-04  
>  
> work at several LISP WG sessions.  We have made significant improvements to 
> the work over that time in AAA, security, privacy, and grammar thanks to 
> prominent non author wg members.
> 
> This ID can help show what can be done with lisp mapped addressable-states 
> and brokered mp2mp channels by simply using standard lisp ucast/mcast 
> interfaces. 
> 
> ID can also help iot / street-processing specs evolve from sending things to 
> a “server”. Show an interoperable extendible paradigm, and actually 
> interoperate and extend themed-channels with enterprise EID  “MIBs”.
> 
> Before asking the chairs for formal WG adoption as authors, would like to 
> know if folks are interested in seeing this advanced, and willing to help 
> move it forward.
> 
> Thank you.
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp



smime.p7s
Description: S/MIME cryptographic signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Support draft-nexagon wg adoption

[Lori Jakab (lojakab)]

I agree, I also support adopting this as a working group document.

-Lori

On 11/19/19 06:49, Dino Farinacci wrote:

I think this use-case is a great one to make use of all the functionality LISP 
already supports.

I support adoption as a working group draft with a goal to publish the draft as 
an Informational RFC.

Dino


On Nov 19, 2019, at 1:37 PM, 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





smime.p7s
Description: S/MIME Cryptographic Signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt

[Lori Jakab]

Hi,

I read the draft, and support its adoption as a WG document.

-Lori

On 19/09/2018 17:04, Luigi Iannone wrote:

Folks,

here is another piece of the work done in our WG that needs to be 
moved to PS.


It is the updated version of RFC 8113, nothing changed just updated 
coherently with the current status of the other documents.


Because this documents is really really short we will have just one 
week adoption call followed be one week WG Last Call.


This email officially starts the one week call for adoption.

Please spend 10 minutes having a look at the document and send an 
email on whether you agree or not to adopt it.


Thanks

Ciao

Luigi



Begin forwarded message:

*From: *internet-dra...@ietf.org 
*Subject: **I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt*
*Date: *19 September 2018 at 16:49:31 CEST
*To: *mailto:i-d-annou...@ietf.org>>
*Reply-To: *internet-dra...@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



   Title   : Locator/ID Separation Protocol (LISP): 
Shared Extension Message & IANA Registry for Packet Type Allocations

   Authors : Mohamed Boucadair
 Christian Jacquenet
Filename    : draft-boucadair-lisp-rfc8113bis-01.txt
Pages   : 5
Date    : 2018-09-19

Abstract:
  This document specifies a Locator/ID Separation Protocol (LISP)
  shared message type for defining future extensions and conducting
  experiments without consuming a LISP packet type codepoint for each
  extension.

  This document obsoletes RFC 8113.


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

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

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


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

Re: [lisp] Fwd: I-D Action: draft-iannone-6834bis-00.txt

[Lori Jakab]

Hi,

I support this draft going to the AD.

Best regards,
-Lori

On 5/20/18 8:17 PM, Joel Halpern wrote:
> This starts a 4 week implicit adoption call and explicit last call for
> the LISP Map Versioning draft revision with the purpose of moving this
> work onto the standards track.
>
> Please read the draft.
> And then speak up as to whether you agree or disagree with us sending
> this document to our AD for IETF LC and IESG review as a Proposed
> Standard RFC.
>
> We will allow 4 weeks for this call, ending on Sunday, June 17.
>
> Thank you,
> Joel
>
> PS: I will try to find a way to mark this suitably in the data
> tracker, but I suspect it does not have a state to reflect this.
>
>
>  Forwarded Message 
> Subject: I-D Action: draft-iannone-6834bis-00.txt
> Date: Sun, 20 May 2018 11:09:40 -0700
> From: internet-dra...@ietf.org
> Reply-To: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>     Title   : Locator/ID Separation Protocol (LISP)
> Map-Versioning
>     Authors : Luigi Iannone
>   Damien Saucez
>   Olivier Bonaventure
> Filename    : draft-iannone-6834bis-00.txt
> Pages   : 19
> Date    : 2018-05-20
>
> Abstract:
>    This document describes the LISP (Locator/ID Separation Protocol)
>    Map-Versioning mechanism, which provides in-packet information about
>    Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to
>    encapsulate LISP data packets.  The proposed approach is based on
>    associating a version number to EID-to-RLOC mappings and the
>    transport of such a version number in the LISP-specific header of
>    LISP-encapsulated packets.  LISP Map-Versioning is particularly
>    useful to inform communicating Ingress Tunnel Routers (ITRs) and
>    Egress Tunnel Routers (ETRs) about modifications of the mappings used
>    to encapsulate packets.  The mechanism is optional and transparent to
>    implementations not supporting this feature, since in the LISP-
>    specific header and in the Map Records, bits used for Map-Versioning
>    can be safely ignored by ITRs and ETRs that do not support or do not
>    want to use the mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iannone-6834bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-iannone-6834bis-00
> https://datatracker.ietf.org/doc/html/draft-iannone-6834bis-00
>
>
> 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




smime.p7s
Description: S/MIME Cryptographic Signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-rfc6830bis-12

[Lori Jakab]

Hi,

I think the document is ready to be handed to the AD.

Best regards,
-Lori

On 04/05/2018 04:17 PM, 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-rfc6830bis-12
> ]
> 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

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

[Lori Jakab]

Hi,

I think this document is ready to be handed to the AD.

Best regards,
-Lori

On 04/05/2018 04:35 PM, 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

Re: [lisp] WG Last Call for draft-ietf-lisp-gpe-03

[Lori Jakab]

Hi,

I have read the document, worked on implementation and inter-operability
testing, and I think it is ready for handing to the AD.

Regards,
-Lori

On 4/5/18 5:08 PM, Luigi Iannone wrote:
> Hi All,
>
> During our last meeting, the authors of the LISP GPE document
>  [https://tools.ietf.org/html/draft-ietf-lisp-gpe-03]
> asked for Last Call. The room showed consensus and no objections were
> raised.
>
> 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

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

[Lori Jakab]

Hi,

I support adoption as a WG document.

Regards,
-Lori

On 4/4/18 4:26 AM, Joel M. Halpern wrote:
> This was discussed in London, and the authors have requested working
> group adoption.
>
> Please comment on whether you think this document is ready for WG
> adoption.  Which does not mean it is perfect, but rather that it is a
> good start on the problem it aims to solve.
> Comments with motivation or explanation are preferred.
>
> Silence does NOT mean consent.
>
> This last call will last for 2 weeks.
> Thank you,
> Joel
>
> On 4/3/18 9: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


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

Re: [lisp] [ERRATA] Call for WG Adoption of Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00.txt]

[Lori Jakab]

Support.

-Lori

On 7/26/17 2:16 PM, Luigi Iannone wrote:
> The call ends August 10th 2017 ! 
> 
> Luigi
> 
>> On 26 Jul 2017, at 11:41, Luigi Iannone > > wrote:
>>
>> Hi All,
>>
>> During the 99th IETF authors of the
>> document draft-rodrigueznatal-lisp-vendor-lcaf-00.txt
>> [https://tools.ietf.org/html/draft-rodrigueznatal-lisp-vendor-lcaf-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  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-predictive-rlocs-02.txt

[Lori Jakab]

Support

On May 19, 2017 12:06:45 PM GMT+03:00, Luigi Iannone  wrote:
>Hi All,
>
>Authors of the document draft-farinacci-lisp-predictive-rlocs-02.txt 
>[https://datatracker.ietf.org/doc/draft-farinacci-lisp-predictive-rlocs/
>]
>asked for WG adoption.
>
>This message begins the two weeks call for WG adoption. 
>The call ends on  June 2nd 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

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

[Lori Jakab]

Hi,

On 4/12/17 12:28 PM, 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.

I support adopting draft-portoles-lisp-eid-mobility-02 as a working
group document.

-Lori

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

[Lori Jakab]

Hi,

I support draft-ietf-lisp-signal-free-multicast-02 to be handed to the AD.

Regards,
-Lori

On 3/27/17 7:06 PM, 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

Re: [lisp] WG Last Call for draft-ietf-lisp-sec-12.txt

[Lori Jakab]

On 12/2/16 6:50 PM, Luigi Iannone wrote:
> Hi All,
> 
> feedback for this last call has been quite low. For this reason we
> decide to extend the last call for another two weeks, ending December 16th.
> 
> Please state your opinion on whether this document is ready for publication.

Yes, please start the publication process.

-Lori

> 
> Silence is NOT consensus.
> 
> Ciao
> 
> Luigi & Joel
> 
>> On 17 Nov 2016, at 09:36, Luigi Iannone > > wrote:
>>
>> Hi All,
>>
>> The authors of the LISP-Security (LISP-SEC) document
>> [https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/] asked for WG
>> Last Call. 
>>
>> This email starts the usual two weeks WG Last Call, to end December
>>  1st, 2016.
>>
>> 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] Call for adoption draft-farinacci-lisp-rfc6830bis

[Lori Jakab]

I support this document becoming a WG item.

-Lori

On 11/16/16 4:57 AM, Luigi Iannone wrote:
> Folks,
> 
> The chairs received a request for the following document to be
> adopted as a WG item:
> 
> _https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/_
> 
> Here starts a 14 day call for adoption, this call will end on
> Wednesday the 30 November, 2016.
> 
> 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
> 
> 
> ___
> 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 draft-farinacci-lisp-rfc6833bis

[Lori Jakab]

I support this document becoming a WG item.

-Lori

On 11/16/16 4:58 AM, Luigi Iannone wrote:
> Folks,
> 
> The chairs received a request for the following document to be
> adopted as a WG item:
> 
> _https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/_
> 
> Here starts a 14 day call for adoption, this call will end on
> Wednesday the 30 November, 2016.
> 
> 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
> 
> 
> ___
> 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] Changing the title of draft-ietf-lisp-yang

[Lori Jakab]

On 7/25/16 7:41 AM, Damien Saucez wrote:
> This new title is perfect.

+1

-Lori

> 
> Damien Saucez 
>> On 25 Jul 2016, at 14:12, Vina Ermagan (vermagan)  wrote:
>>
>> Hello,
>>
>> During IETF96 WG meeting a change of title from “LISP Configuration YANG 
>> Model” to “YANG Model for LISP”  was proposed by authors for 
>> draft-ietf-lisp-yang such that the tile reflects operational models being 
>> included.  This is to request comment form the list on this change. 
>>
>> Thanks,
>> Vina
>> ___
>> 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 adoption of draft-boucadair-lisp-type-iana-01

[Lori Jakab]

On 7/15/16 6:56 AM, Luigi Iannone wrote:
> His All,
> 
> the chairs have review the WG discussion during the adoption call.  
> 
> We are concerned by the low level of support.  
> We also observed significant discussion around the experimental
> allocation.  
> So we are re-issuing and clarifying the call, to finish one week afte
> rthe end of IETF 96. 
> 
> Please comment on two separate issues:
> 
> 1) Do you think we should create a registry for LISP message types

+1

> 
> 2) If yes to (1), do you think that registry should include reserving an
> entry for Experimentation?

+1

-Lori

> 
> As indicated in the first mail silence does not indicate support, please
> respond to the call.
> 
> Yours,
> 
> Joel
> Luigi
> 
> On 28 Jun 2016, at 11:37, Luigi Iannone  > wrote:
> 
>> Folks,
>>
>> The chairs received a request for the following document to be
>> adopted as a WG item:
>>
>> _https://tools.ietf.org/html/draft-boucadair-lisp-type-iana-01_
>> _
>> _Here starts a 14 day call for adoption, this call will end on
>> Tuesday the 12th July, 2016.
>>
>> 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
>>
> 
> 
> 
> ___
> 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-lcaf-12

[Lori Jakab]

On 4/8/16 4:27 PM, Luigi Iannone wrote:
> Hi All,
> 
> During our meeting yesterday, the authors of the LISP LCAF document
>  [https://tools.ietf.org/html/draft-ietf-lisp-lcaf-12]
> asked for Last Call. The room showed consensus and no objections were
> raised.
> 
> This email starts the usual two weeks WG Last Call, to end April 22nd, 2016.
> 
> Please review this WG document and let the WG know if you agree that it
> is ready for handing to the AD.

I support handing this document to the AD.

Best regards,
-Lori

> 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

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

[Lori Jakab]

On 8/10/15 12:57 AM, Luigi Iannone 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.

I support WG adoption of this document.

-Lori

 
 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.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP Overlay Model

[Lori Jakab]

On 8/10/15 1:05 AM, Luigi Iannone wrote:
 Hi,
 
 LISP provides a rather complete and powerful control-plane, where 
 by means of LCAF, possibly any existing namespace can be mapped 
 on each other.
 However, the data-plane is not as flexible. The current specifications
 allow only IPv4 over IPv6 and vice versa.
 
 In order to create what Sharon Barakai defined “map assisted overlays”
 more work is needed.
 
 In this context the WG should also decide whether just an extended/enhanced
 data-plane is sufficient/needed. Or should the scope be slightly larger and 
 allow as well to support multiple headers type?
 Such header are not necessarily defined by the LISP WG 
 (e.g.  VXLAN-GPE, GENEVE, GUE, etc.)

I think supporting multiple headers is the better option.

-Lori

 
 Would the WG be interested in working in extending the LISP overlay model
 in order to provide data-plane support for what the control plane already 
 allows?
 And what should be the scope?
 
 Joel  Luigi

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

Re: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt

[Lori Jakab]

Hi,

I read the draft and I think it is ready to be handed to the AD.

Regards,
-Lori

On 01/29/2015 05:36 PM, Luigi Iannone wrote:
 Hi All,
 
 The authors of draft-ietf-lisp-ddt-02 
 [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02],
 as well as several active WG participants,
 requested the WG Last Call for this document.
 
 This email starts a 14 days WG Last Call, to end February 13th, 2015.
 
 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

Re: [lisp] draft-ietf-lisp-ddt-02

[Lori Jakab]

On 01/24/2015 12:39 AM, Fabio Maino wrote:
 Agree. It was recently refreshed from expiration, and I believe it's
 ready for last call.

+1

There are several implementations, that have been thoroughly tested for
interoperability, so I support this document going into working group
last call.

-Lori

 
 Fabio
 
 On 1/23/15 9:25 AM, Dino Farinacci wrote:
 I would like to ask the working group if there are any issues with
 draft-ietf-lisp-ddt-02 and if there is any reason to not send this
 document for working group last call?

 It has been around for a while, has good implementation and deployment
 support and hasn't been presented in a working group meeting for a while.

 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] [EXTENDED] draft-saucez-lisp-impact-07 - Call for WG Adoption

[Lori Jakab]

Hi,

I support option #1.

-Lori

On 12/22/2014 05:12 PM, Joel M. Halpern 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

Re: [lisp] Proposing Encapsulation Format LCAF type

[Lori Jakab]

On Nov 27, 2014, at 5:34 PM, Luigi Iannone g...@gigix.net wrote:

 Hi All,
 
 I would like to encourage the WG to post their thoughts about Dino’s proposal 
 of a new LCAF type for Encapsulation Format.
 
 Also, a couple of corrections/Additions to Dino’s mail.
 
 About point (1) of Dino’s mail: 
 
 The proposed encoding is based on a bitwise approach that today reserves 
 specific bits to encapsulation formats that at this time are not WG documents 
 anywhere in the IETF. The WG should be aware that the dependencies introduced 
 in the document may slow down its progress.
 Dino thinks that this will be settled before LCAF will go to last call. 
 Bits reserved for disappeared encapsulations will be not used anymore.
 
 About point (3) of Dino’s mail:
 
 The correct question the chairs would like to see answered the following: 
 
 Is the WG OK to work on the proposed encoding and push the work on a more 
 general format to later times (i.e. after rechartering)?
 
 If not, have people any alternative suggestion?
 
 Again: please comment in order to make progress.

I have heard a few times the accusation that LISP doesn’t properly separate the 
control and data planes.  I think this proposal is a very good idea, and shows 
just how untrue that accusation is.  So I think the WG should work on the 
proposed encoding.

-Lori

 
 ciao
 
 Luigi
 
 On 25 Nov 2014, at 21:20, Dino Farinacci farina...@gmail.com wrote:
 
 I sent this out a couple of weeks ago. There has been some discussion but 
 wanted to move this along. So bringing this back on the list.
 
 I had some private discussions with Damien and Darrel, who had comments on 
 the idea as well as the format of this new Encapsulation Format LCAF type. I 
 would like to summarize the discussion and open discussion up on the list.
 
 I would like to submit this by end of week if there are no strong objections.
 
 To summarize the comments from Damien, Darrel, Luigi, and Joel (please 
 correct me if I missed anything):
 
 (1) My goal of this new LCAF type was to create a specific need to identify 
 what encapsulations a decapsulator can support and not make this a general 
 negotiation facility. The proposal is to not document all types of 
 encapsulation formats that have ever been designed in the IETF but ones that 
 are or may gain popularity in the industry for data-center overlay 
 applications.
 
 (2) There was a request to make the format more general to allow data-plane 
 options to be transmitted in Map-Reply messages. The current format uses 
 only 7 bits out of 32 bits, so future encapsulations can be added. 
 Therefore, the current format is extensible but purposely not generally 
 extensible. If we need to add anything more, we can always add new LCAF 
 types in the future.
 
 (3) A compromise among Dino, Darrel, and Damien was to submit what we have 
 now for experimentation and to discuss more about a adding an LCAF type that 
 will more general to convey data-plane parameters. The chairs indicated we 
 should discuss adding this as a WG item when the recharter discussions occur.
 
 See diff enclosed.
 
 Thanks,
 Dino
 
 rfcdiff-lisp-lcaf-06-to-07.html
 
 draft-ietf-lisp-lcaf-07.txt
 
 
 
 Begin forwarded message:
 
 From: Dino Farinacci farina...@gmail.com
 Subject: Proposing Encapsulation Format LCAF type
 Date: November 13, 2014 at 12:45:42 PM PST
 To: LISP mailing list list lisp@ietf.org
 
 I've been having discussions with various people and there is a rough 
 concensus that if the LISP mapping system can aid in helping encapsulators 
 know what encapsulation formats a decapsulator supports, we will get better 
 interoperability in the face of the myriad of overlay data-planes that are 
 being proposed in the IETF.
 
 Here is the section that was added to the LCAF draft:
 
 PastedGraphic-10.png
 
 
 
 
 Proposed -07 and html diff also enclosed.
 
 Dino
 
 draft-ietf-lisp-lcaf-07.txtrfcdiff-lisp-lcaf-06-to-07.html
 
 
 
 
 
 ___
 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] https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/

[Lori Jakab]

I think this draft is complete and ready to go to the IESG.

-Lori

On 03/20/2014 08:23 PM, Joel M. Halpern wrote:
 The draft LISP Threats Analysis has been significantly revised following
 the WG last call in November.
 The working group seems happy with the results of the revision.
 
 This email starts a two week last call, to end on April 4th, 2014.
 Please review the documnet, and comment to the list on whether it is
 complete and ready to go to the IESG.
 
 Thank you,
 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] LISP SDN

[Lori Jakab]

Hi Alberto, Robert,

I'm really excited to LISP used as an SDN enabler!!

A few initial comments:

On 02/18/2014 12:15 PM, Alberto Rodriguez-Natal wrote:
 Hi Robert,
 
 
 On Tue, Feb 18, 2014 at 4:14 AM, Robert Raszuk rob...@raszuk.net
 mailto:rob...@raszuk.net wrote:
 

[...]

 But I must ask why limit yourself to 5 or 7 tuples if another
 standards body (at least one claims to be the SDO) 
 
 already 
 long time 
 ago defined 39 tuples to be SDN primitives or building blocks. 
 Is there something among those 
 
 
 39 tuples xTRs can't do ? I guess not as both could be same boxes
 from same ODM vendor :)
 
 
 You are right here. More fields beyond just the addresses, protocol and
 ports can be taken into account. For now, we are focusing on these only,
 but we expect to cover more in the future (thus, the n-tuple notation on
 the draft).

I think covering more fields is a good idea.

 
 Besides, please note that we may won't cover the same types that OF
 covers. We don't want to compete with OF, but rather to complement it.

I don't think you would be competing with OF by specifying the same
match types as the ONF does, you would be using (implementing?)
OpenFlow, and that would lead to less fragmentation and more code reuse.

 It's about using the right tool for the job. OF is (generally speaking)
 focused on L2, while LISP is (generally speaking) focused on L3. That's
 why the 5-tuple makes more sense for LISP as a flow identifier than,
 let's say, ETH or ARP fields. Hope I had brought some light here ;)

Well, OpenFlow is slowly adding support for L3 only flows, and LISP is
slowly adding support for L2 encaps. Even if you're initially focusing
on a few match fields, the design should accommodate a variable number
of fields, and the specification of field prerequisites (e.g., if you're
matching on a TCP port number, you should have an IPv4 or IPv6 packet).

As Robert, I would really like OpenFlow compatible match support.

-Lori

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

Re: [lisp] LISP SDN

[Lori Jakab]

On 02/18/2014 01:17 PM, Alberto Rodriguez-Natal wrote:
 Hi Lori,
 
 Thanks for the comments, see below.
 
 On Tue, Feb 18, 2014 at 7:57 PM, Lori Jakab l...@lispmob.org
 mailto:l...@lispmob.org wrote:

[...]

  Besides, please note that we may won't cover the same types that OF
  covers. We don't want to compete with OF, but rather to complement it.
 
 I don't think you would be competing with OF by specifying the same
 match types as the ONF does, you would be using (implementing?)
 OpenFlow, and that would lead to less fragmentation and more code reuse.
 
 
 Don't get me wrong here. Maybe I explained myself poorly. I didn't want
 to say that we need to cover different fields. What I meant to say is
 that maybe we don't need to cover ALL the fields that OF covers. Perhaps
 a subset of those is enough for LISP. Of course, in the future maybe we
 see the need for covering more (all?) OF fields or maybe beyond OF ones.

Understand.

My main consideration here is that many (most?) SDN software packages
today (for whatever definition of SDN) has support for OpenFlow (mostly
1.0). Hardware is also starting to support OpenFlow. So I think that
simply from the implementation point of view you have an advantage if
you just can reuse a versatile existing matching engine.

 
 
  It's about using the right tool for the job. OF is (generally
 speaking)
  focused on L2, while LISP is (generally speaking) focused on L3.
 That's
  why the 5-tuple makes more sense for LISP as a flow identifier than,
  let's say, ETH or ARP fields. Hope I had brought some light here ;)
 
 Well, OpenFlow is slowly adding support for L3 only flows, and LISP is
 slowly adding support for L2 encaps. 
 
 
 That's why I said generally speaking ;)

I thought so :)  But I still wrote the comment because I think we should
be forward looking!

Thanks for the discussion,
-Lori

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

Re: [lisp] Android feature request for LISP

[Lori Jakab]

Hi Rene,

While not integrated deep into the Android operating system, there is an open 
source project implementing LISP for Android:http://lispmob.org/  Not sure if 
you're already familiar with it, but you may want to take a look.

HTH,
-Lori

On Nov 7, 2013, at 4:56 PM, Rene Bartsch i...@bartschnet.de wrote:

 I've created a LISP feature request for Android 
 (http://code.google.com/p/android/issues/detail?id=61794).
 
 Please second that feature request with your names and companies showing it's 
 a serious feature request to encourage Google to implement LISP into Android! 
 :-)
 
 
 -- 
 Best regards,
 
 Rene Bartsch, B. Sc. Informatics
 ___
 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] AD Evaluation: draft-ietf-lisp-deployment

[Lori Jakab]

Hi Fred,

On 05/29/2013 08:32 PM, Templin, Fred L wrote:
 Hi Lori,

 -Original Message-
 From: Lori Jakab [mailto:lja...@ac.upc.edu]
 Sent: Wednesday, May 29, 2013 9:58 AM
 To: Templin, Fred L
 Cc: Paul Vinciguerra; Lori Jakab; Brian Haberman; draft-ietf-lisp-
 deploym...@tools.ietf.org; lisp@ietf.org
 Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment

 On 05/28/2013 11:38 PM, Templin, Fred L wrote:
 -Original Message-
 From: Paul Vinciguerra [mailto:pvi...@vinciconsulting.com]
 Sent: Tuesday, May 28, 2013 12:58 PM
 To: Templin, Fred L; Lori Jakab; Brian Haberman
 Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org
 Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment

   Encapsulation results in an end-to-end path MTU of less than
   1500 bytes, if encapsulated packets need to travel over links
   with MTU lower than 1500 bytes + LISP encapsulation overhead.

 Thanks - Fred
 fred.l.temp...@boeing.com

 [PV]
 How about
 Packet Encapsulation may exceed the MTU of the underlying physical
 media.   To address the MTU constraints of a given physical media,
 the
 MTU of the original payload may need to be reduced or be fragmented
 and
 encapsulated in multiple packets.
 LISP and other tunnel types need to concern themselves with the path
 MTU between the tunnel ingress and egress, so it is about more than
 just the underlying physical media of the first hop into the tunnel.
 I think the wording by Brian is both clear and concise, and addresses
 your concerns (doesn't use may and refers to the end-to-end path).
 Unless there is strong objection, I will use that wording.
 Almost. Suggest changing Brian's wording slightly as follows:

   Encapsulation increases the amount of overhead associated with each
packet.  For LISP, this added overhead decreases the effective
end-to-end path MTU.

 Reason is that this statement is true for LISP, but not necessarily
 true for all other tunnel types.

I tried finding a tunneling protocol where it isn't true, but I came up
empty.  Can you please give an example of a tunnel where the
encapsulation overhead does not result in a decrease of the E2E PMTU? 
Even if the subject matter is LISP, and even if there is an exception, I
wouldn't single it out when *most* tunneling protocols have the same issue.

-Lori


 Thanks - Fred
 fred.l.temp...@boeing.com


 Thanks,
 -Lori

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

Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment

[Lori Jakab]

On 05/28/2013 11:38 PM, Templin, Fred L wrote:

 -Original Message-
 From: Paul Vinciguerra [mailto:pvi...@vinciconsulting.com]
 Sent: Tuesday, May 28, 2013 12:58 PM
 To: Templin, Fred L; Lori Jakab; Brian Haberman
 Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org
 Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment

   Encapsulation results in an end-to-end path MTU of less than
   1500 bytes, if encapsulated packets need to travel over links
   with MTU lower than 1500 bytes + LISP encapsulation overhead.

 Thanks - Fred
 fred.l.temp...@boeing.com

 [PV]
 How about
 Packet Encapsulation may exceed the MTU of the underlying physical
 media.   To address the MTU constraints of a given physical media, the
 MTU of the original payload may need to be reduced or be fragmented and
 encapsulated in multiple packets.
 LISP and other tunnel types need to concern themselves with the path
 MTU between the tunnel ingress and egress, so it is about more than
 just the underlying physical media of the first hop into the tunnel.

I think the wording by Brian is both clear and concise, and addresses
your concerns (doesn't use may and refers to the end-to-end path). 
Unless there is strong objection, I will use that wording.

Thanks,
-Lori
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Shepherd writeup for draft-ietf-lisp-deployment-07

[Lori Jakab]

Hi Wassim,

On 04/27/2013 08:34 AM, Wassim Haddad wrote:
 Dear all,

 I am the document shepherd for draft-ietf-lisp-deployment-07. In order
 for me to complete the shepherd writeup, I would like first to ask the
 authors and the WG if any and all appropriate IPR disclosures required
 for full conformance with the provisions of BCP 78 and BCP 79 have
 already been filed.

Nothing has been filed that applies to this draft, and I'm are unaware
of any IPR outstanding.

Best regards,
-Lori
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] comments on 'draft-ietf-lisp-deployment-06'

[Lori Jakab]

Sender: lisp-boun...@ietf.org
On-Behalf-Of: lja...@ac.upc.edu
Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06'
Message-Id: 512e3492.9010...@ac.upc.edu
Recipient: buxt...@cintas.com
---BeginMessage---
Hi Fred,

Thank you very much for the feedback.  See responses in-line below:

On 02/26/13 00:55, Templin, Fred L wrote:
 Hi,

 I am reading this document for the first time and had a few
 comments to share below.

 Thanks - Fred
 fred.l.temp...@boeing.com

 1) Section 2.5 (Tunnel Routers Behind NAT), this seems to
show a limitation in that there can be only one xTR behind
a NAT. I would like to address the case when there may be
many xTRs behind the NAT - can LISP do that?

There is specification being worked on that will enable many xTRs behind
NAT.  It will, however require a Re-encapsulating Tunnel Router (RTR) to
proxy all data packets for it to work. See
https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal


 2) Section 2.6, I don't understand why it says MTU/PMTUD
issues minimized for the recursive scenario?

It's a typo, thanks for catching this!


 3) Section 6.1, number 4, should say request increase in MTU
to 1556 *or greater* on service provider connections.

Indeed, will fix.

However, controlling just the first-hop interface MTU
does not assure MTU mitigations across the entire path.
Similarly, care must be taken that ICMP is not being
filtered cannot be assured along the entire path. And,
studies have shown that ICMP filtering does impact MTU
handling in current operational practices:


 http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

True, we are citing RFC 4459 at the end of section 2.1 with regard to
this issue.  Would it help if we referenced it in this section as well?


 Additionally, I have a use case that I'm not sure is well addressed by
 the document. I would like to address the use case of mobile networks
 configured as stub sites that connect to ISPs via a mobile router. Each
 mobile router may have multiple ISP connections, and can change its ISP
 addresses dynamically as it moves around. Some of the ISP addresses may
 be global and others may be private, such as behind a carrier-grade NAT.
 Many such mobile routers may be located behind the same NAT.

 I want to give each mobile router an EID prefix that it can use to number
 interfaces within the mobile network. The mobile network may contain just
 one interface, a few interfaces, or it may contain many interfaces.

 I now want that the mobile network can remain reachable from the outside
 world by the same EID prefix addresses even as the mobile router travels
 around dynamically. The mobile router will need an xTR so that its ISPs
 will not filter its packets that use EID source addresses. I also want
 the mobile router to be able to traffic engineer in both the outgoing
 *and* incoming directions. For this, there needs to be some sort of
 server sitting outside of any NATs that the mobile router can register
 itself with. The mobile router should be able to change between different
 servers as it moves around, e.g., to reduce path stretch or in the
 event of a server failure. The servers in turn associate with proxy
 xTRs so that outgoing packets destined to EIDs located in distant
 networks can be routed appropriately.

 This is the way IRON sets things up. Can it also be done with LISP?

Yes, using the NAT traversal specification I mentioned above.  The
mobile router should be an xTR itself, and will receive a list of RTRs
(what you call servers above) it can use for traversing the NAT (for the
connections where a NAT is detected).  Path stretch optimizations are
certainly possible, they depend on the implementation of the
Map-Server.  Incoming traffic engineering is possible with LISP,
however, outgoing traffic engineering is not LISP specific, it should be
done with existing mechanisms.

Would you like this scenario added to the document?

Best regards,
-Lori
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?

[Lori Jakab]

On 01/22/13 12:22, Damien Saucez wrote:

 On 22 Jan 2013, at 10:15, Luigi Iannone g...@gigix.net
 mailto:g...@gigix.net wrote:

 Hi All,

 the definition of LSB as of the to-be-soon-rfc lisp specification is:

 LISP Locator Status Bits (LSBs):  When the L-bit is also set, the
   locator status bits field in the LISP header is set by an ITR to
   indicate to an ETR the up/down status of the Locators in the
   source site. 

 I think that this clears Damien's question since LSB has no
 reachability meaning, rather it is a message from the site telling
 from my perspective ETR X is up and running.


 Yes, it is not a problem of reachability but a question of status.
 However, how is the
 status defined but the router that sends the LSB? How does it know
 that the locator
 is up or down? How can we make sure that the LSB will be the same,
 whatever router
 is building it?

I think this depends a lot on the implementation. For example, if you
wanted to have the LSBs synced, you could use the status from the
locator records in the Map-Notify messages, and you would get the Map
Server view of status. With a more complex implementation, you could
probably get a better view. But I think it depends a lot on the
implementation.


 Another question, how bad/good would it be for the traffic if two
 routers give different
 LSBs?

Again, that's something implementation specific, I don't think it's specced.


 (BTW this may help debugging, since if the ETR is running but not
 reachable from the outside this clearly shows that the problem is
 along the path somewhere. Yeah… could be a long path… but it is still
 useful information).

 I agree, that in a controlled environment LSB can be very helpful to debug
 the network. In the Internet where the topology is unknown I don't know if
 it is a very relevant information, but it depends how the LSB is
 constructed.

Exactly, depends on the implementation. But the document we discuss is
about deployment, so operators can only do what implementations allow
them to do.



 The main concern is about security. Obviously LSB can be easily
 spoofed in a public environment and this is documented in section
 6.4.1 of the draft-ietf-lisp-threats, which recommends:

Locator Status Bits can be blindly trusted only in secure
environments.  In the general unsecured Internet environment, the
safest practice for xTRs is to confirm the status change
through the mapping system.


 So IMHO the thing to do is to simply put a reference to the
 lisp-threats draft about the use of LSBs.



 If the LSB has to be verified, I would then prefer to use versioning.

I will put a reference to the threats draft, and suggest versioning as
an alternative.

Thanks for all the input!

-Lori


 Damien Saucez


 ciao

 Luigi





 On 22 Jan. 2013, at 04:15 , Dino Farinacci farina...@gmail.com
 mailto:farina...@gmail.com wrote:

 They have the same meaning in all environment. It is a question when
 they should be verified. An LSB that changes in a public environment
 can cause a Map-Request to be sent and a signed Map-Reply can verify
 the LSB in an authenticated matter.

 Dino

 On Jan 21, 2013, at 6:05 PM, Ronald Bonica rbon...@juniper.net
 mailto:rbon...@juniper.net wrote:

 Dino,

 But isn't it troubling that the bits have one meaning in a
 controlled environment and another in the great-wide Internet?

 Ron


 -Original Message-
 From: lisp-boun...@ietf.org mailto:lisp-boun...@ietf.org
 [mailto:lisp-boun...@ietf.org mailto:boun...@ietf.org] On Behalf Of
 Dino Farinacci
 Sent: Monday, January 21, 2013 5:51 PM
 To: Noel Chiappa
 Cc: lisp-inter...@cisco.com mailto:lisp-inter...@cisco.com;
 lisp@ietf.org mailto:lisp@ietf.org; lisp-
 b...@external.cisco.com mailto:b...@external.cisco.com
 Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet
 deployment?

 (I don't remember off the top of my head why I didn't like them: I
 think it was a combination of the fixed number of bits, the fact that
 it might be difficult for ETR X to know the state of ETR Y, the fact
 that 'reachable from ITR A' [which you _really_ need to have anyway]
 is a subset of 'up', etc, etc. But we didn't desperately need the
 header bits, and the mechanism wasn't positively harmful, so I didn't
 bother to put up a big fight over it... :-)

 Maybe because they could be spoofed?

 But they are good in control environments to take ETRs out of service
 without having to update the mapping database.

 Dino


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


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

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



 ___
 

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

[Lori Jakab]

Hi Damien,

Many thanks for the review. See responses inline:

On 01/15/13 00:15, Damien Saucez wrote:
 Hello,

 Comments inline

[...]

LISP site:  A single host or a set of network elements in an edge
   network under the administrative control of a single organization,
   delimited from other networks by LISP Tunnel Router(s).

Since LISP is a protocol which can be used for different purposes, it
is important to identify possible deployment scenarios and the
additional requirements they may impose on the protocol specification
and other protocols.  Additionally, this document is intended as a
guide for the operational community for LISP deployments in their
networks.  It is expected to evolve as LISP deployment progresses,
and the described scenarios are better understood or new scenarios
are discovered.

 maybe describe rapidly what an network element is.

Not sure it is really necessary, but how about something like:

Network element: active or passive device that is used for
transporting packet switched data.


Each subsection considers an element type, discussing the impact of
deployment scenarios on the protocol specification.  For definition
of terms, please refer to the appropriate documents (as cited in the
respective sections).
 2.  Tunnel Routers

LISP is a map-and-encap protocol, with the main goal of improving
global routing scalability.  To achieve its goal, it introduces
several new network elements, each performing specific functions
necessary to separate the edge from the core. 

 wouldn't this clearer in Sec. 1? It is important for the general
 understanding.

Agree, will move.

[...]


From the LISP site perspective the main advantage of this type of
deployment (compared to the one described in the next section) is
having direct control over its ingress traffic engineering.  This
makes it is 
 remove is?

Thanks for catching this.

[...]


Another thing to consider when placing tunnel routers are MTU issues.
Since encapsulating packets increases overhead, the MTU of the end-
to-end path may decrease, when encapsulated packets need to travel
over segments having close to minimum MTU.  Some transit networks are
known to provide larger MTU than the typical value of 1500 bytes of
popular access technologies used at end hosts (e.g., IEEE 802.3 and
802.11).  However, placing the LISP router connecting to such a
network at the customer edge could possibly bring up MTU issues,
depending on the link type to the provider as opposed to the
following scenario.

 counter measures for that (e.g.,  any special setup that can be done
 to minimise the risk
 a client is not working properly because of MTU)

That could be a lenghty discussion.  LISP sites should check with their
providers and make sure they offer links with the required MTU. They
should also be able to check for themselves.

 2.2.  Provider Edge

The other location at the core-edge boundary for deploying LISP
routers is at the Internet service provider edge.  The main incentive
for this case is that the customer does not have to upgrade the CE
router(s), or change the configuration of any equipment.
Encapsulation/decapsulation happens in the provider's network, which
may be able to serve several customers with a single device.  For
large ISPs with many residential/business customers asking for LISP
this can lead to important savings, since there is no need to upgrade
the software (or hardware, if it's the case) at each client's
location.  Instead, they can upgrade the software (or hardware) on a
few PE routers serving the customers.  This scenario is depicted in
Figure 2.









 Jakab, et al.Expires April 23, 2013 [Page 5]
 
 Internet-Draft   LISP DeploymentOctober 2012


   +--++--+
   |   ISP1   ||   ISP2   |
   |  ||  |
   |  ++  ||  ++  ++  |
   +--|xTR1|--++--|xTR2|--|xTR3|--+
  ++  ++  ++
 |  |   |
 |  |   |
 +--[LISP site]---+---+

   Figure 2: xTR at the PE

While this approach can make transition easy for customers and may be
cheaper for providers, the LISP site looses one of the main benefits
of LISP: ingress traffic engineering.  Since the provider controls
the ETRs, additional complexity would be needed to allow customers to
modify their mapping entries.

 or the client can have some form of access to the configuration (a bit
 like tagging route with
 special communities in BGP to tell the ISP to 

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

[Lori Jakab]

On 01/21/13 19:06, Damien Saucez wrote:
 comments inline

 On 21 Jan 2013, at 10:42, Lori Jakab lja...@ac.upc.edu wrote:

 Hi Damien,

 Many thanks for the review. See responses inline:

 On 01/15/13 00:15, Damien Saucez wrote:
 Hello,

 Comments inline
 [...]

   LISP site:  A single host or a set of network elements in an edge
  network under the administrative control of a single organization,
  delimited from other networks by LISP Tunnel Router(s).

   Since LISP is a protocol which can be used for different purposes, it
   is important to identify possible deployment scenarios and the
   additional requirements they may impose on the protocol specification
   and other protocols.  Additionally, this document is intended as a
   guide for the operational community for LISP deployments in their
   networks.  It is expected to evolve as LISP deployment progresses,
   and the described scenarios are better understood or new scenarios
   are discovered.

 maybe describe rapidly what an network element is.
 Not sure it is really necessary, but how about something like:

Network element: active or passive device that is used for
transporting packet switched data.
 ok

   Each subsection considers an element type, discussing the impact of
   deployment scenarios on the protocol specification.  For definition
   of terms, please refer to the appropriate documents (as cited in the
   respective sections).
 2.  Tunnel Routers

   LISP is a map-and-encap protocol, with the main goal of improving
   global routing scalability.  To achieve its goal, it introduces
   several new network elements, each performing specific functions
   necessary to separate the edge from the core. 
 wouldn't this clearer in Sec. 1? It is important for the general
 understanding.
 Agree, will move.

 [...]

   From the LISP site perspective the main advantage of this type of
   deployment (compared to the one described in the next section) is
   having direct control over its ingress traffic engineering.  This
   makes it is 
 remove is?
 Thanks for catching this.

 [...]

   Another thing to consider when placing tunnel routers are MTU issues.
   Since encapsulating packets increases overhead, the MTU of the end-
   to-end path may decrease, when encapsulated packets need to travel
   over segments having close to minimum MTU.  Some transit networks are
   known to provide larger MTU than the typical value of 1500 bytes of
   popular access technologies used at end hosts (e.g., IEEE 802.3 and
   802.11).  However, placing the LISP router connecting to such a
   network at the customer edge could possibly bring up MTU issues,
   depending on the link type to the provider as opposed to the
   following scenario.
 counter measures for that (e.g.,  any special setup that can be done
 to minimise the risk
 a client is not working properly because of MTU)
 That could be a lenghty discussion.  LISP sites should check with their
 providers and make sure they offer links with the required MTU. They
 should also be able to check for themselves.
 is there any IETF document that could be pointed out for that?

RFC4459 could be a good candidate.

 2.2.  Provider Edge

   The other location at the core-edge boundary for deploying LISP
   routers is at the Internet service provider edge.  The main incentive
   for this case is that the customer does not have to upgrade the CE
   router(s), or change the configuration of any equipment.
   Encapsulation/decapsulation happens in the provider's network, which
   may be able to serve several customers with a single device.  For
   large ISPs with many residential/business customers asking for LISP
   this can lead to important savings, since there is no need to upgrade
   the software (or hardware, if it's the case) at each client's
   location.  Instead, they can upgrade the software (or hardware) on a
   few PE routers serving the customers.  This scenario is depicted in
   Figure 2.









 Jakab, et al.Expires April 23, 2013 [Page 5]

 Internet-Draft   LISP DeploymentOctober 2012


  +--++--+
  |   ISP1   ||   ISP2   |
  |  ||  |
  |  ++  ||  ++  ++  |
  +--|xTR1|--++--|xTR2|--|xTR3|--+
 ++  ++  ++
|  |   |
|  |   |
+--[LISP site]---+---+

  Figure 2: xTR at the PE

   While this approach can make transition easy for customers and may be
   cheaper for providers, the LISP site looses one of the main benefits
   of LISP: ingress traffic engineering.  Since the provider controls
   the ETRs, additional complexity would be needed to allow customers to
   modify

Re: [lisp] draft-ietf-lisp-deployment review

[Lori Jakab]

Hi Joel,

Thank you for reviewing.  See inline for answers.

On Dec 13, 2012, at 4:02 AM, Joel M. Halpern wrote:

 In conjunction with the WG last call on this document, I performed my own 
 review.
 
 
 It appears that the text in section 3.1 on Map Server deployment asserts that 
 (for EIDs outside of an allocated IPv6 block) Map Servers will need to be run 
 by the RIRs.  I strongly hope this is not the case.  The RIRs have not signed 
 up to run this service.  Given that there are already existing ways for sites 
 to prove provenance for PI address blocks, some other mechanism would seem 
 achievable.

How about this simplified text for the second paragraph of Section 3.1 
(removing the bullets)?

The Map-Server is provided by a Mapping Service Provider (MSP).  The MSP 
participates in the global distributed mapping database infrastructure, by 
setting up connections to other participants, according to the specific mapping 
system that is employed (e.g., ALT, DDT). Participation in the mapping 
database, and the storing of EID-to-RLOC mapping data is subject to the 
policies of the root operators, who SHOULD check ownership rights for the EID 
prefixes stored in the database by participants.  These policies are out of the 
scope of this document.

I didn't enter too much into specifics, because I think mapping system specific 
deployment description should go into separate documents, and EID allocation 
was mentioned as candidate for a separate document too.  However, since we seem 
to move forward on DDT for the global mapping system, should we have a bit more 
detail about joining the DDT?  What does the WG think?

 
 
 Minor issues:
I find the characterization of site edge in section 2.1, can be 
 approximated as the the set of DFZ routers belonging to non-transit ASes To 
 be a weak approximation.  It fails basically because the CE and PE routers 
 for many sites are either non-BGP speakers, or use default routes.  Also, the 
 BGP properties of the site do not seem relevant to the LISP deployment 
 issues, so I wonder why they are even mentioned here.

Well, the document was written with the goals of RFC4984 in mind, to reduce the 
size of the DFZ, so we focused on stub ASes that are BGP speakers.  Would it 
address your concern if we replaced

   LISP was designed with deployment at the core-edge boundary in mind,
   which can be approximated as the set of DFZ routers belonging to non-
   transit ASes.  For the purposes of this document, we will consider
   this boundary to be consisting of the routers connecting LISP sites
   to their upstreams.

with

   The first scenario we discuss is customer edge, when xTR functionality
   is placed on the router(s) that connect the LISP site to its upstream(s),
   but are under its control.

 
Should section 2.3 on split ITR/ETR note that in placing the ITRs inside 
 the site, the ITRs will still need global RLOCs, and this may add complexity 
 to intra-site routing configuration, and further intra-site issues when there 
 is a change of providers?

Thanks for this suggestion, I think it's valuable information to the reader.  
Will include in the next revision.

 
In the last sentence of section 2.5.1 on ITR behind NAT, cold we add an 
 only?  The sentence would become This setup supports only a single ITR 
 behind the NAT device.

Sure.  Will do.

 
Should sections 5.2 and 5.3 on P-ITR deployment note that there are likely 
 to be additional costs involved, to be borne by some party, since the P-ITR 
 devices under consideration are handling all non-LISP-originated traffic for 
 the customer sites?

Here's suggested text for 5.2:

   Routing all non-LISP ingress traffic through a third party which is
   not one of its ISPs is only feasible for sites with modest amounts of
   traffic (like those using the IPv6 tunnel broker services today),
   especially in the first stage of the transition to LISP, with a
   significant number of legacy sites.
This is because the handling of
   said traffic is likely to result in additional costs, which would be
   passed down to the client.
   When the LISP/non-LISP site
   ratio becomes high enough, this approach can prove increasingly
   attractive.

And 5.3:

   The PSP manages a set of distributed P-ITR(s) that will advertise the
   corresponding EID prefixes through BGP to the DFZ.  These P-ITR(s)
   will then encapsulate the traffic they receive for those EIDs towards
   the RLOCs of the LISP site, ensuring their reachability from non-LISP
   sites.
   Note that handling non-LISP-originated traffic may incur
   additional costs for the PSP, which may be passed down to the client.

Thanks,
-Lori

 
 Yours,
 Joel M. Halpern

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

Re: [lisp] I-D Action: draft-ietf-lisp-deployment-05.txt

[Lori Jakab]

This revision only updates the references, as previsously discussed here.

Regards,
-Lori Jakab

On 10/20/12 21:45, 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.

   Title   : LISP Network Element Deployment Considerations
   Author(s)   : Lorand Jakab
   Albert Cabellos-Aparicio
   Florin Coras
   Jordi Domingo-Pascual
   Darrel Lewis
   Filename: draft-ietf-lisp-deployment-05.txt
   Pages   : 25
   Date: 2012-10-20

 Abstract:
This document discusses the different scenarios for the deployment of
the new network elements introduced by the Locator/Identifier
Separation Protocol (LISP).


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

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lisp-deployment-05

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-deployment-05


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

 ___
 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-ietf-lisp-deployment-04.txt

[Lori Jakab]

This version contains mainly editorial changes, improving clarity. Also,
all references have been made informational, since this is an
informational draft.

-Lori

On 09/12/12 22:19, 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.

   Title   : LISP Network Element Deployment Considerations
   Author(s)   : Lorand Jakab
   Albert Cabellos-Aparicio
   Florin Coras
   Jordi Domingo-Pascual
   Darrel Lewis
   Filename: draft-ietf-lisp-deployment-04.txt
   Pages   : 24
   Date: 2012-09-12

 Abstract:
This document discusses the different scenarios for the deployment of
the new network elements introduced by the Locator/Identifier
Separation Protocol (LISP).


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

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lisp-deployment-04

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-deployment-04


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

 ___
 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] Can not reach IPv6 site via LISP network

[Lori Jakab]

Hi Markus,

On 12/11/11 14:27, Markus PlusNet wrote:
 Hi Lori,

  Apologies if I sent it to the wrong list.

  When you say However, the third column shows that is not active at
 the moment. What is not active ?

LISP introduces an additional component, called the mapping system,
which maps the identifier 2610:d0:2113:3::3 to a routing locator. This
mapping fails currently. See this IP Journal article for an overview of
how LISP works, or check the latest drafts for details:
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_lisp.html

   If I check www.ipv6-db.com at
 http://ipv6-test.com/validate.php the site is responding as

 Checking for  DNS record2610:d0:2113:3::3

This only means that the DNS lookup for www.ipv6-db.com works.

 Checking for IPv6 web serverApache/2.2.10 (Linux/SUSE)

This is strange, I assume it might be related to caching results on the
ipv6-test.com web site? I certainly cannot telnet to port 80 of
www.ipv6-db.com.

Regards,
-Lori


 Thank you
 Markus

 - Original Message - From: Lori Jakab lja...@ac.upc.edu
 To: Markus Moeller mar...@moeller.plus.com
 Cc: lisp@ietf.org; lisp-supp...@cisco.com
 Sent: Sunday, December 11, 2011 10:43 AM
 Subject: Re: [lisp] Can not reach IPv6 site via LISP network


 Hi Markus,

 The LISP WG mailing list is dedicated to the LISP standardization
 effort, so these kind of questions are better directed to the people
 operating the LISP beta network.

 Here are a few things you can try when debugging LISP related issues:

  * Check if the LISP mapping system knows about the destination you
want to reach. You can use the open source 'lig' utility from one of
your hosts not behind a firewall/NAT, or simply this LISP looking
glass: http://lispmon.net/lig.cgi
  * Check the status page of all LISP sites
 http://www.lisp4.net/lisp-site/

 If you try the first step, you will see:
 # lig -m intouch-ams-mr-ms-1.rloc.lisp4.net www.ipv6-db.com
 Send map-request to intouch-ams-mr-ms-1.rloc.lisp4.net for
 www.ipv6-db.com ...
 Received map-reply from 85.184.2.42 with rtt 0.05900 secs

 Mapping entry for EID '2610:d0:2113:3::3':
 2610:d0:2113::/48, via map-reply, record ttl: 1, not auth, not mobile
  Negative cache entry, action: forward-native

 The negative cache entry hints at one of two things: the destination is
 either not a LISP site, or if it is, it is currently not registering to
 the LISP mapping system.

 If you check the second step, and you seach that page for the prefix
 2610:d0:2113, you will find it on the list, so it is a LISP site.
 However, the third column shows that is not active at the moment. You
 should probably contact the people managing the LISP routers for that
 prefix, but I think that contact info is not public, the LISP beta
 network operators can put you in contact.

 Regards,
 -Lori

 On 12/10/11 14:20, Markus Moeller wrote:
 Hi,

   I try to connect to a website on the ipv network and my ISP tells me
 it is a problem with the LISP prefix. I was asked to rais it with
 the WG.

 Thank you
 Markus



 *Can not reach server on ipv6 network*
 [gb] Markus Moeller on Friday, 09 December 2011 19:59:04
 Here are the traceroute details for the not working site:
 C:\My Program Files\Windows Resource Kits\Toolstracert www.ipv6-db.com

 Tracing route to www.ipv6-db.com [2610:d0:2113:3::3]
 over a maximum of 30 hops:

 1 31 ms 28 ms 29 ms gw-1326.lon-02.gb.sixxs.net [2a01:348:6:52d::1]
 2 28 ms 28 ms 29 ms ge-0-0-5-20.cs0.thw.uk.goscomb.net
 [2a01:348:0:4:0:3:0:1]
 3 30 ms 31 ms 29 ms xe-0-0-0.rt0.the.uk.goscomb.net [2a01:348::27:0:1]
 4 28 ms 31 ms 30 ms lonap.he.net [2001:7f8:17::1b1b:1]
 5 97 ms 100 ms 96 ms 10gigabitethernet7-4.core1.nyc4.he.net
 [2001:470:0:3e::1]
 6 120 ms 116 ms 124 ms 10gigabitethernet8-3.core1.chi1.he.net
 [2001:470:0:1c6::2]
 7 189 ms 190 ms 187 ms 2001:470:1:34::2
 8 187 ms 188 ms 191 ms iana.r1.ord1.isc.org [2001:500:71:6::1]
 9 189 ms 207 ms 204 ms int-0-0-1-8.r1.pao1.isc.org [2001:4f8:0:1::4a:1]
 10 190 ms 191 ms 191 ms int-0-1-0-0.r1.sql1.isc.org
 [2001:4f8:1b:1::8:2]
 11 187 ms * 187 ms lisp-r1.sql1.isc.org [2001:4f8:3:d::60]
 12 * * * Request timed out.
 13 * * * Request timed out.
 14 * * * Request timed out.
 15 * * * Request timed out.
 16 * * * Request timed out.
 17 * * * Request timed out.
 18 * * * Request timed out.
 19 * * * Request timed out.
 20 * * * Request timed out.
 21 * * * Request timed out.
 22 * * * Request timed out.
 23 * * * Request timed out.
 24 * * * Request timed out.
 25 * * * Request timed out.
 26 * * * Request timed out.
 27 * * * Request timed out.
 28 * * * Request timed out.
 29 * * * Request timed out.
 30 * * * Request timed out.

 Trace complete.


  Jeroen Massar SixXS on Friday, 09 December 2011 20:15:39
  Tracing route to www.ipv6-db.com [2610:d0:2113:3::3]

 That is a LISP prefix, there is some kind of magical routing involved
 there and it is all quite experimental.

 See Cisco's LISP and the LISP beta site site for more details

[lisp] Announcing the first public release of LISPmob

[Lori Jakab]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The LISPmob development team is pleased to announce the first public
release of LISPmob for Linux. LISPmob was developed by Cisco Systems
and it is now being released under the GPLv2, hosted and maintained at
the Technical University of Catalonia (UPC).


About LISPmob
- -

LISPmob is an open source IP mobility solution for Linux hosts,
implementing the LISP Mobile Node [1] specification, which is
based on the Locator/Identifier Separation Protocol (LISP) [2].
LISP is being developed within the IETF as a potential solution to
the routing scalability problem documented in RFC 4984 [3].


Getting LISPmob
- ---

LISPmob source code is available from the project web site,
http://lispmob.org/ and the public git repository is available
from Github: https://github.com/LISPmob/lispmob


Features
- 

LISPmob supports the following features:

* IPv4-in-IPv4 encapsulation and decapsulation of LISP data
  packets, based on the map-cache
* Map-Register
* Map-Request/Map-Reply
* SMR
* RLOC probing

A more detailed feature list is available in the project wiki:

https://github.com/LISPmob/lispmob/wiki/Features


Getting Help
- 

The 'users' mailing list offers community support, see the project
web site for subscription information and web archives. Community
support is also available on the Freenode Internet Relay Chat
(IRC) network, by joining the #lispmob channel.


References
- --

[1] https://tools.ietf.org/html/draft-meyer-lisp-mn
[2] https://tools.ietf.org/html/draft-ietf-lisp
[3] https://tools.ietf.org/html/rfc4984

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk5pEEIACgkQlUwN75BxDXSoMACgsaW+0NnDroyV3fCiJBDGiZ/s
MeMAnRb42gR43wtSy5uAa3bIFWilKM8Z
=3DkK
-END PGP SIGNATURE-

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