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

[Fabio Maino (fmaino)]

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

Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished

[Fabio Maino (fmaino)]

Dino, 
Back then Albert Lopez, Vina and others invested quite some time addressing in 
draft-ermagan-lisp-nat-traversal a lot of corner cases that were coming from 
mobiity. 

Before we move forward with a NAT document we should make sure we either 
explicitly leave out those use cases, or address them. 

Thanks,
Fabio

On 3/21/23, 12:37 PM, "lisp on behalf of Dino Farinacci" 
mailto:lisp-boun...@ietf.org> on behalf of 
farina...@gmail.com > wrote:


draft-farinacci-lisp-lispers-net-nat proposes an implemented solution for the 
problem.


Dino


> On Mar 21, 2023, at 6:25 AM, Albert López  > wrote:
> 
> On 14/3/23 10:46, Luigi Iannone wrote:
>> LISP NAT Traversal: we have a candidate document
> 
> Here we have the problem of handovers between RTRs. Some time ago I proposed 
> a possible solution but I believe we need to think a little more to find a 
> more optimal solution.
> Albert López
> 
> ___
> 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] Supporting lisp-geo [Was: Re: lisp - Requested session has been scheduled for IETF 115]

[Fabio Maino (fmaino)]

Chairs, 
I would like to support Dino's request for WG adoption of 
https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/. 

It's a well written document that defines the Geo-coordinate LCAF type. The 
draft brings up a couple of good use cases that illustrates how the LCAF type 
would be used. 

It's a fairly simple document, and I can't think of anything that I would do 
differently. I'm also supportive of getting this to last call as soon as IETF 
procedure allows. 

Thanks,
Fabio 

On 10/15/22, 10:37 AM, "lisp on behalf of Dino Farinacci" 
 wrote:

And I would like to request WG document for draft-farinacci-lisp-geo again. 
It has been around for a long time and has an LCAF encoding code point in RFC 
8060. I can present this draft too in London. 

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

Re: [lisp] LISP Specifications Published!! :-)

[Fabio Maino (fmaino)]

Now it’s time to pull the Prosecco!

Thanks and congratulations to all those that have made this possible…

Fabio

From: lisp  on behalf of Dino Farinacci 

Date: Thursday, October 20, 2022 at 2:43 PM
To: Alvaro Retana 
Cc: "lisp@ietf.org list" 
Subject: Re: [lisp] LISP Specifications Published!! :-)

Phew I am exhausted. LOL.

Thank you to the 100s of people who contributed to the requirements, design, 
implementation, documentation, and deployment of these set of standards.

Dino


On Oct 20, 2022, at 2:34 PM, Alvaro Retana  wrote:
FYI

The RFC Editor just published the group of 8 RFCs that include the base 
specifications! :-)

RFC9299 through RFC9306

Thank you for all the hard work and congratulations!!!

Alvaro.

___
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: draft-ietf-lisp-name-encoding-00.txt

[Fabio Maino (fmaino)]

I support handing this document over to the AD.

Encoding Distinguished Names in LISP is a simple but important feature, and the 
document does a very good job of articulating how it should be done providing a 
few good examples of why is relevant.

Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Wednesday, September 28, 2022 at 6:46 AM
To: Dino Farinacci , "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: [lisp] WG Last Call: draft-ietf-lisp-name-encoding-00.txt

Hi All,

As you can see from the email exchange Dino asked for Working Group Last Call 
for  draft-ietf-lisp-name-encoding-00.txt

This email open the usual two weeks Working Group Last Call, to end October 
14th, 2022.

Please review!

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! Please review!

Thanks



On 6 Sep 2022, at 17:52, Dino Farinacci 
mailto:farina...@gmail.com>> wrote:

I would like to request WG last call on this document.

Dino


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lisp-name-encoding-00.txt
Date: September 6, 2022 at 4:31:12 AM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lisp@ietf.org
Reply-To: internet-dra...@ietf.org, 
lisp@ietf.org


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-ietf-lisp-name-encoding-00.txt
 Pages   : 8
 Date: 2022-09-05

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-ietf-lisp-name-encoding/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-name-encoding-00


Internet-Drafts are also available by rsync at rsync.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] New lisp WG Co-Chair

[Fabio Maino (fmaino)]

Joel, thanks for the steady guidance and strong support you have provided to 
the WG over the years. I can think of so many reasons why we really wouldn't be 
where we are without your help. Good luck with whatever is your next challenge 
at the IETF.

Padma, congratulations and welcome in your new role, and thanks for the work 
done over the years as WG secretary. I'm really looking forward to work with 
you, Deborah, Luigi and the whole WG to bring home the RFCs and continue the 
evolution of LISP.


Fabio

On 8/18/22, 9:52 AM, "lisp on behalf of Dino Farinacci"  wrote:

And we can’t discard the team player you were Deborah in supporting them!

Thanks to you too. 

Dino

> On Aug 18, 2022, at 6:51 AM, BRUNGARD, DEBORAH A  wrote:
> 
> +1 on Dino's sincere words - Joel and Luigi were instrumental in guiding 
LISP to where it is today as a standards track working group!
> All the best Joel!
> Welcome Padma!
> 
> Deborah
> 
> 
> -Original Message-
> From: lisp  On Behalf Of Dino Farinacci
> Sent: Wednesday, August 17, 2022 5:57 PM
> To: Alvaro Retana 
> Cc: lisp@ietf.org list 
> Subject: Re: [lisp] New lisp WG Co-Chair
> 
> I'd like to say a few words about Joel. 
> 
> Not only did he run this WG for quite a long time, he was also involved 
in the Routing Research Group (as was Luigi) and started a lot of the seed 
ideas for LISP. I have worked with Joel for many decades and his ability to 
spot architecture bugs and issues is unique and makes him one of a kind. His 
expertise will be missed but I gather he will still be involved technically.
> 
> I want to say, on behalf of the original LISP authors, a huge thank you 
Joel for your huge contributions. I think the protocol and its deployments are 
better off because of your consultation and effort.
> 
> Appreciative,
> Dino
> 
>> On Aug 17, 2022, at 2:42 PM, Alvaro Retana  
wrote:
>> 
>> Dear lisp WG:
>> 
>> Joel has decided to step down as lisp Co-Chair.   For the last 12+
>> years, he has been instrumental in the focus of the WG, including
>> bringing the updated Standards Track specifications to publication
>> (which we expect anytime!).  Joel: thank you for all the time and
>> effort you have put into the WG; we all look forward to your continued
>> contributions to the IETF!
>> 
>> In consultation with Luigi and the other ADs, we have asked Padma
>> Pillay-Esnault to take on the role of lisp Co-Chair.  As you know,
>> Padma has served as the WG's Secretary since 2017.  In addition, she
>> has been an active IETF contributor for many years.  Welcome Padma!
>> 
>> This change is effective immediately.
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lisp__;!!BhdT!m6eMzIsJkPrQVPhjYY_YWdzYl48H-J5Wn5uKluz1b-_3oCSWw97UPuyDvES-5IHLRukeIwPCd6AyjNXT$
  
> 
> ___
> lisp mailing list
> lisp@ietf.org
> 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lisp__;!!BhdT!m6eMzIsJkPrQVPhjYY_YWdzYl48H-J5Wn5uKluz1b-_3oCSWw97UPuyDvES-5IHLRukeIwPCd6AyjNXT$
  

___
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 Review of draft-ietf-lisp-sec-25

[Fabio Maino (fmaino)]

Thanks Alvaro, 
I believe Damien and Luigi are already taking a first pass. 

After a quick review between the authors, we should be able to return it back 
to you. 

Fabio 

On 4/28/22, 9:17 AM, "Alvaro Retana"  wrote:

Hi!

I'm just moving this message up in people's mailer to make sure everyone
saw it.

If you’re already working in it, sorry for the interruption.

Alvaro.

On April 21, 2022 at 3:27:18 PM, Alvaro Retana (aretana.i...@gmail.com)
wrote:


Dear authors:

Thank you for the work on this document!

I put detailed comments inline below.

As we have a constrained timeline for this document, I would like to start
the IETF Last-Call in no more than a couple of weeks.  I don't think my
comments will be hard to address.  In fact, there are comments that I
repeat in different sections, and some overlap.

Please reply inline to this message to expedite my review of any updates.
Also, if you think talking would clear things up faster, feel free to find
time on my calendar:  https://doodle.com/mm/alvaroretana/book-a-time

Thanks!

Alvaro.


[Line numbers from idnits.]

...
15 Abstract

17   This memo specifies LISP-SEC, a set of security mechanisms that
18   provides origin authentication, integrity and anti-replay protection
19   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
20   process.  LISP-SEC also enables verification of authorization on EID-
21   prefix claims in Map-Reply messages.

[nit] s/via mapping lookup process/via the mapping lookup process/g


...
100 1.  Introduction
...
120   This memo specifies LISP-SEC, a set of security mechanisms that
121   provides origin authentication, integrity and anti-replay protection
122   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
123   process.  LISP-SEC also enables verification of authorization on EID-
124   prefix claims in Map-Reply messages, ensuring that the sender of a
125   Map-Reply that provides the location for a given EID-prefix is
126   entitled to do so according to the EID prefix registered in the
127   associated Map-Server.  Map-Register/Map-Notify security, including
128   the right for a LISP entity to register an EID-prefix or to claim
129   presence at an RLOC, is out of the scope of LISP-SEC as those
130   protocols are protected by the security mechanisms specified in
131   [I-D.ietf-lisp-rfc6833bis].  However, LISP-SEC extends the Map-
132   Register message to allow an ITR to securely downgrade to non LISP-
133   SEC Map-Requests.  Additional security considerations are described
134   in Section 6.

[major] "securely downgrade to non LISP-SEC Map-Requests"

To "securely downgrade" to no security doesn't sound right to me.  See more
comments in §6.7.


...
176 4.  LISP-SEC Threat Model

178   LISP-SEC addresses the control plane threats, described in section
179   3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including
180   manipulations of Map-Request and Map-Reply messages, and malicious
181   ETR EID prefix overclaiming.  LISP-SEC makes two main assumptions:
182   (1) the LISP mapping system is expected to deliver a Map-Request
183   message to their intended destination ETR as identified by the EID,
184   and (2) no man-in-the-middle (MITM) attack can be mounted within the
185   LISP Mapping System.  How the Mapping System is protected from MITM
186   attacks depends from the particular Mapping System used, and is out
187   of the scope of this memo.  Furthermore, while LISP-SEC enables
188   detection of EID prefix overclaiming attacks, it assumes that Map-
189   Servers can verify the EID prefix authorization at registration time.

[] As part of the efforts to make the language in IETF documents more
inclusive, consider using "on-path attack" instead of MITM.  This term in
already in use in some parts of this document.

https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/


...
202 5.  Protocol Operations
...
210   LISP-SEC builds on top of the security mechanisms defined in
211   [I-D.ietf-lisp-rfc6833bis] to address the threats described in
212   Section 4 by leveraging the trust relationships existing among the
213   LISP entities participating to the exchange of the Map-Request/Map-
214   Reply messages.  Those trust relationships are used to securely
215   distribute, as described in Section 8.4, a per-message One-Time Key
216   (OTK) that provides origin authentication, integrity and anti-replay
217   protection to mapping data conveyed via the mapping lookup process,
218   and that effectively prevent overclaiming attacks.  The processing of
219   security parameters during the Map-Request/Map-Reply exchange is as
220   

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

[Fabio Maino (fmaino)]

As an author, I support the document.

I think it’s a very interesting use case,  that shows how LISP can support a 
global geo-localization index infrastructure. A good example of how a fast, 
scalable lookup infrastructure can support, up to a certain extent,  use cases 
that are typically considered the domain of peer-to-peer architectures.

The document articulates the peculiarities of the use case, providing a guide 
on how to leverage the H3 geospatial  indexing system on top of LISP.

Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, February 23, 2021 at 11:17 PM
To: "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

Folks,

while this document has gathered attention during face to face meetings, we 
received very few email in support of WG LC!

In order to gather more consensus we prefer to extend the Last Call period by 
two weeks, to end by March 10th.

Please speak up and state whether or not this document is ready to be published.

Ciao

Luigi & Joel



On 3 Feb 2021, at 16:25, Luigi Iannone mailto:g...@gigix.net>> 
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

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

[Fabio Maino (fmaino)]

As a contributor I support handing this draft to the AD.

Pubsub operations are an important extension for the LISP architecture. There 
are a number of use cases where ITRs need to be notified of rapidly changing 
mappings. This draft leverages the Map-Request/Mao-Notify messages to handle 
subscribe and notify operations that implement the LISP pubsub semantic.

Thanks,
Fabio



From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, January 12, 2021 at 11:20 PM
To: "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: [lisp] WG Last Call for draft-ietf-lisp-pubsub

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] Moving forward with lisp-nexagon

[Fabio Maino (fmaino)]

It’s indeed a very interesting use case and application for the LISP protocol. 
As an author, I would like to see the WG involved with this topic.

Thanks,
Fabio

From: lisp  on behalf of Sharon Barkai 

Date: Sunday, August 2, 2020 at 9:45 AM
To: "lisp@ietf.org list" 
Subject: [lisp] Moving forward with lisp-nexagon

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

Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Magnus, 
sounds good, I'll update that text as soon the publication window reopens. 

Thanks!
Fabio

On 7/14/20, 2:45 AM, "Magnus Westerlund"  
wrote:

Hi,

From my perspective the below is still a normative reference formulation. 
You
have to read the reference to be able to determine if you SHOULD follow 
them or
not. 

Maybe adopting the paragraph which draft-ietf-tsvwg-ecn-encap-guidelines
proposes to update RFC 3819 with: 

  By following the guidelines in [RFC], subnetwork designers can
  enable a layer-2 protocol to participate in congestion control
  without dropping packets via propagation of explicit congestion
  notification (ECN [RFC3168]) to receivers.

Into the below text can make it inforamtive. 


   Keeping in mind the recommendation above, new encapsulated payloads,
   when registered with LISP-GPE, should be designed for explicit
   congestion signals to propagate consistently from lower layer
   protocols into IP.  Then the IP internetwork layer can act as a
   portability layer to carry congestion notification from non-IP-aware
   congested nodes up to the transport layer (L4).  Such new
   encapsulated payloads, when registered with LISP-GPE, MUST be
   accompanied by a set of guidelines derived from [RFC6040]. 
   Following the guidelines in [I-D.ietf-tsvwg-ecn-encap-guidelines],
   designers of new LISP-GPE encapsualtions can enable LISP GPE and the 
   encapsulated payload to participate in congestion control without 
dropping 
   packets via propagation of explicit congestion notification (ECN 
[RFC3168]) 
   to receivers.

Please word smith. I still think this is borde line case for a informative
reference but at least it is not directly part of an RFC 2119 language 
sentence.

Cheers

Magnus


On Mon, 2020-07-13 at 19:04 +0000, Fabio Maino (fmaino) wrote:
> Magnus, 
> here is how we modified the latest version of the draft trying to reflect 
your
> concerns, and to deal with the status of the ecn-encap-guidelines draft. 
> 
> 4.2.  Congestion Control Functionality
> 
>LISP-GPE does not natively provide congestion control functionality
>and relies on the payload protocol traffic for congestion control.
>As such LISP-GPE MUST be used with congestion controlled traffic or
>within a network that is traffic managed to avoid congestion (TMCE).
>An operator of a traffic managed network (TMCE) may avoid congestion
>by careful provisioning of their networks, rate-limiting of user data
>traffic and traffic engineering according to path capacity.
> 
>Keeping in mind the recommendation above, new encapsulated payloads,
>when registered with LISP-GPE, should be designed for explicit
>congestion signals to propagate consistently from lower layer
>protocols into IP.  Then the IP internetwork layer can act as a
>portability layer to carry congestion notification from non-IP-aware
>congested nodes up to the transport layer (L4).  Such new
>encapsulated payloads, when registered with LISP-GPE, MUST be
>accompanied by a set of guidelines derived from [RFC6040] and SHOULD
>follow the guidelines defined in  
[I-D.ietf-tsvwg-ecn-encap-guidelines].
> 
> 
> Thanks,
> Fabio
> 
> On 7/10/20, 6:54 AM, "Magnus Westerlund" 
> wrote:
> 
> On Thu, 2020-07-09 at 13:57 -0400, Joel M. Halpern wrote:
> > Magnus, while it is possible we will still get hold ups on the LISP 
> > documents, I would really prefer to avoid creating a normative 
> > dependency on something that at best is 6 months away.  
Particularly 
> > since the TSVWG has not cared enough to maintain the document.
> 
> I can understand that. So then think you need to figure out what
> requirements
> from that document that you thought was relevant to say that they 
MUST be
> included in a future specification and include them in the GPE 
document so
> that 
> the ecn-encap-guidelines would only be inforamtional reference. 
> 
> Cheers
> 
> Magnus
> 
> > 
> > Yours,
> > Joel
> > 
> > On 7/9/2020 1:50 PM, Magnus Westerlund wrote:
> > > Hi,
> > > 
> > > No, RFC 3819 is not a good replacement for the draft. I would note
> that only
> > > a
> > > minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap-
> guidelines.
> > > 
> > 

Re: [lisp] Robert Wilton's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Rob, 
Thanks for your review. Please see below. 

On 7/7/20, 3:41 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Hi,

I found this document easy to read and understand.

A couple of minor comments:

4.3.  UDP Checksum

   By default, UDP checksum MUST be used when LISP-GPE is transported
   over IPv6.  A tunnel endpoint MAY be configured for use with zero UDP
   checksum if additional requirements in Section 4.3.1 are met.

This paragraph could probably be moved/merged into section 4.3.1?

[FM] good catch. We have moved it there in rev-17

4.4.  DSCP, ECN and TTL

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped
   to, or used to determine the LISP Instance IDentifier (IID) field.

This text doesn't appear to be related to DSCP, ECN or TTL.  Perhaps tweak 
the
title of this section to cover this text?

[FM] Good point. Changed to " DSCP, ECN, TTL, and 802.1Q". 

Thanks,
Fabio


Regards,
Rob




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

Re: [lisp] Martin Duke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Thanks for your comments, Martin. Please see below. 

On 7/6/20, 9:18 PM, "Martin Duke via Datatracker"  wrote:

Martin Duke has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

I found the requirements in Section 4.3.1 (IPv6 zero checksum) quite onerous
and can’t help but wonder if it’s worth the complexity, or just that people
already have it implemented in hardware.

[FM] There was quite a lot of discussion in the WG around this, and the "MAY" 
use UDP zero check sum text seem to have reached some consensus that allows 
implementors to make an informed decision. 

This seems like a very useful extension for LISP.


s/octet/octet

s/payolads/payloads

[FM] typos are now fixed in rev-17. 


Thanks,
Fabio


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

Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Thanks for your review Eric. Please see below our replies. 

On 7/7/20, 1:02 AM, "lisp on behalf of Éric Vyncke via Datatracker" 
 wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Thank you for the work put into this document. This is really useful work 
and
the document is easy to read.

Please find below a couple of non-blocking COMMENTs (and I would appreciate 
a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
As this document is in the same 'batch'/timing as the RFC 6830 bis, is 
there a
reason why this extension is not in the bis document itself?

[FM] there were quite a few changes and discussions introduced in 6830bis. The 
WG thought that keeping lisp-gpe as a separate document would simplify the 
review process. 

-- Section 3 --
What is the reason why not reusing an existing 'next protocol' registry? Or
using a 16-bit Ethernet type like field (as in GRE) ?

[FM] the LISP header uses the last 3 octets in the first 32-bit word for the 
nonce/versioning features. We designed a reduced NP field to try to squeeze a 
limited version of those features using octets 2-3 of lisp-gpe. It turned out 
that the limitations imposed by the shorter field where too much, and 
eventually the WG decided to eliminate the nonce/versioning features altogether 
from lisp-gpe. Reversing now back to 16-bit NP field, would impact the early 
lisp-gpe implementations that have been built so far. 

As a side cosmetic note, I would have preferred to have 0x04 for IPv4 and 
0x06
for IPv6.

[FM] we decided to assign them incrementally. We really didn’t have enough 
meaningful payloads to get up to 6... 


"the shim header MUST come before the further protocol" but, if there are 
other
headers defined in LISP (I must confess my ignorance on this), should the 
shim
header be just after the LISP header ? I.e. the first one of a potential 
chain
(cfr IPv6 extension header chains) ?

It is unclear whether a shim header 'next protocol' field can also have a 
value
associated to yet another shim header.

[FM] Good catch. We have re-phrased the text to make clear that there might be 
multiple shim headers, and they should be in front of the actual payload 
identified by NP 0x01-0x7F. 
This is ithe new text:  " When shim headers are used with other protocols 
identified by next protocol values from 0x0 to 0x7D, all the shim headers MUST 
come first."

== NITS ==
The document title "LISP Generic Protocol Extension" is generic while the
document is mainly about "multi-protocol encapsulation". Should the title be
changed? As a non-English speaker, I read the title as how to make 
any/generic
extension to the LISP protocol and not as a LISP extension to support the
transport of generic/any protocol.

[FM] one can use lisp-gpe to extend the LISP encapsulation protocol to support 
generic payloads (IPv6, ethernet, NSH, iOAM, GBP, ...) in addition to IP. 
However it is also possible to use lisp-gpe to extend LISP features. For 
example, one could use a shim header to implement a nonce/versioning field of 
arbitrary size. That's the reason we think of the draft as a LISP Generic 
Protocol Extension.  

-- Section 3 --

[FM] all the suggestions below are addressed in rev-17

Strongly suggest to make it clear by adding a MUST in  "and ignored on
receipt", i.e., "and MUST be ignored on receipt"

"0x05 to 0x7D " the final ':' is missing.

Why not writing " 0x7E, 0x7F:" ?

"deploy new GPE features", GPE is not expanded before this first use (even 
if
quite obvious in this document).

s/octect/octet/

Thanks,
Fabio

___
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] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Thanks anyway Mirja, 
your help along all of this was much appreciated! 

Fabio



On 6/8/20, 12:42 PM, "Mirja Kuehlewind"  wrote:

Thanks a lot! I believe all my comments are addressed but I’m also not an 
AD anymore…



> On 1. Jun 2020, at 07:55, Fabio Maino (fmaino) 
 wrote:
> 
> Hi Mirja, 
> Rev -15, that was just published, should address your comments: 
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
> 
> Let me know if you have any further comment. 
> 
> Thanks,
> Fabio
> 
> On 3/13/20, 4:19 AM, "Mirja Kuehlewind"  wrote:
> 
>Hi authors, hi Deborah,
> 
>Sorry for being super later on this but I was looking at this document 
again and I realised that there is still one open issue that needs fixing: I 
noticed that I also had a discuss point on guidance on DSCP which is not 
addressed yet. However, the more important and really critical point is that 
the doc talks about setting the 3-bit Type of Service (ToS) that does exist 
anymore: RFC1349 was obsoleted by RFC2474, so there is now only a 6-bit DSCP 
field. This is really a pain point in todays Internet and needs to be fixed! I 
also recommend to add a reference to RFC2474 (then this problem would maybe 
have been detected earlier). And still as my discuss says some more guidance on 
the use of DCSP would be good as well!
> 
>Thanks!
>Mirja
> 
> 
> 
>> On 10. Jan 2020, at 20:03, BRUNGARD, DEBORAH A  wrote:
>> 
>> Hi Mirja,
>> 
>> The plan is to Last Call the set of documents (gpe, bis's) and put on a 
future telechat. First, the author teams want to ensure they have addressed all 
the current Discusses/comments and they are working to get the documents ready.
>> 
>> Thanks all - the documents are much improved!
>> Deborah
>> 
    >> 
    >> -Original Message-
>> From: Mirja Kuehlewind  
>> Sent: Wednesday, January 08, 2020 5:22 AM
>> To: Fabio Maino (fmaino) ; BRUNGARD, DEBORAH A 

>> Cc: The IESG ; lisp-cha...@ietf.org; lisp@ietf.org; 
magnus.westerl...@ericsson.com; draft-ietf-lisp-...@ietf.org; Luigi Iannone 

>> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with 
DISCUSS and COMMENT)
>> 
>> Hi Fabio,
>> 
>> Thanks for all the work. Changes look good to me and I think my discuss 
comments are addressed.
>> 
>> One small comment/nit: I think you also should define the “Reserved” 
field in Figure 2. It’s not mention in the text, and even though the meaning is 
obvious, I assume it was an oversight that it's not described.
>> 
>> Given the large set of changes, it’s good that another wg last call took 
place. I think given more or less whole document has changes, it could be 
approbate to also have another IETF last call and put it back on a future 
telechat agenda. But I let Deborah decide about this. 
>> 
>> Deborah what's your plan here?
>> 
>> Mirja
>> 
>> 
>> 
>>> On 8. Jan 2020, at 00:02, Fabio Maino (fmaino)  wrote:
>>> 
>>> Hi Mirja,
>>> It took quite some time, but I think we are finally making progress 
>>> with the review of draft-ietf-lisp-gpe and the related LISP RFCbis 
>>> drafts 
>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>>> ..org_doc_draft-2Dietf-2Dlisp-2Drfc6830bis_=DwIFaQ=LFYZ-o9_HUMeMTSQ
>>> icvjIg=6UhGpW9lwi9dM7jYlxXD8w=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVl
>>> PPk33Nw=oRnVaMWUr_mvYyEiDEkkNTuBOAIOJ_vBnr3COsvsMrI=
>>> , 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_=DwIFaQ=LFYZ-o9_HUMeMTSQicvjIg=6UhGpW9lwi9dM7jYlxXD8w=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw=3I9q-AoB6EQNPtTNvKH36_EP-xCFPQESZPH7CeFoVuo=
  ).
>>> 
>>> Could you please take a look at the latest rev -13 of 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Dgpe_=DwIFaQ=LFYZ-o9_HUMeMTSQicvjIg=6UhGpW9lwi9dM7jYlxXD8w=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw=BueHq0NVA0sDhX7r1hme2y4YHEnu52LCy7alSTn3nIc=
 , and let us  know if we have addressed your comments?
>>> 
>>> Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have 
done two main changes that might help addressing your DISCUSS: 
>>> 1.  We have introduced the concept of shim header, along the line 
of what Mirja suggested in her comment. The chairs thought that the change was 
significant enough to require a new last call wi

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Done!

Fabio

From: Fabio Maino 
Date: Wednesday, June 3, 2020 at 9:43 AM
To: Luigi Iannone 
Cc: "lisp@ietf.org" , "draft-ietf-lisp-...@ietf.org" 

Subject: Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

Sounds good Luigi.

I’ll publish an updated version that reflects your suggestions later today.

Fabio

From: Luigi Iannone 
Date: Tuesday, June 2, 2020 at 10:45 PM
To: Fabio Maino 
Cc: "lisp@ietf.org" , "draft-ietf-lisp-...@ietf.org" 

Subject: Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt
Resent-From: 
Resent-To: Fabio Maino , , 
, Darrel Lewis , 
Resent-Date: Tuesday, June 2, 2020 at 10:44 PM

Hello again,

if you agree to change the text as for may previous email table in section 6 
IANA Considerations must be updated as well.

Ciao

L.








On 3 Jun 2020, at 07:38, Luigi Iannone mailto:g...@gigix.net>> 
wrote:

Hi Fabio,

thanks for the clarification. I think that I finally got it:

0x7E to 0x7F is for just experimentation.

 0xFE to 0xFF is for shim headers experimentation

My confusion came from the fact that is not clearly stated.

Can we modify the text as:

0x7E to 0x7F:  Experimentation and testing
0x80 to 0xFD:  Unassigned (shim headers)
0xFE to 0xFF:  Experimentation and testing (shim headers)

So that the difference  is clearly stated.

Ciao

L.





On 2 Jun 2020, at 19:34, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciso Luigi, please see below...

On 6/2/20, 12:11 AM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:





On 1 Jun 2020, at 07:53, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciao Luigi,
The reason is to allow to experiment with shim headers and non-shim headers at 
the same time. As you may remember shim headers have a more fixed encodng and 
must be located before non-shim headers.

   That is OK for me.

   But my question is why this:



0x7E to 0x7F:  Experimentation and testing

FM> The two above are for experimentation of NON shim headers



   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing



FM These two are for experimentation of shim headers.

Shim headers are placed (and processed) first, so we want to give the freedom 
to experiment with both.

For example, one would want to experiment with a shim header (identified by 
0xFE) that carries some special metadata for IPv4 payloads, while someone else 
would want to experiment with IPv8 payloads (identified with 0x7E). A third 
person might want to experiment, at the same time, with a shim header that 
carries special metadata for IPv8.

Fabio






   Instead of this (range has been adapted):

   0x7E to 0xFB:  Unassigned (shim headers)
   0xFC to 0xFF:  Experimentation and testing

   ??

   Certainly I am missing something ;-)

   Ciao

   L.






Thanks,
Fabio



On 5/31/20, 10:47 PM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:

  Thank you for updating the document.

  I have a quick question.

  Looking at the next protocol values we now see:

   0x7E to 0x7F:  Experimentation and testing
   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing

  Can you provide a rationale why not having just one bigger experimentation 
and testing range instead of two with an unassigned range in the middle?

  Thanks

  Ciao

  L.





On 1 Jun 2020, at 07:41, 
internet-dra...@ietf.org<mailto: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 Generic Protocol Extension
 Authors : Fabio Maino
   Jennifer Lemon
   Puneet Agarwal
   Darrel Lewis
   Michael Smith
Filename: draft-ietf-lisp-gpe-15.txt
Pages   : 15
Date: 2020-05-31

Abstract:
This document describes extentions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation.


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

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

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


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


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

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Sounds good Luigi.

I’ll publish an updated version that reflects your suggestions later today.

Fabio

From: Luigi Iannone 
Date: Tuesday, June 2, 2020 at 10:45 PM
To: Fabio Maino 
Cc: "lisp@ietf.org" , "draft-ietf-lisp-...@ietf.org" 

Subject: Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt
Resent-From: 
Resent-To: Fabio Maino , , 
, Darrel Lewis , 
Resent-Date: Tuesday, June 2, 2020 at 10:44 PM

Hello again,

if you agree to change the text as for may previous email table in section 6 
IANA Considerations must be updated as well.

Ciao

L.







On 3 Jun 2020, at 07:38, Luigi Iannone mailto:g...@gigix.net>> 
wrote:

Hi Fabio,

thanks for the clarification. I think that I finally got it:

0x7E to 0x7F is for just experimentation.

 0xFE to 0xFF is for shim headers experimentation

My confusion came from the fact that is not clearly stated.

Can we modify the text as:

0x7E to 0x7F:  Experimentation and testing
0x80 to 0xFD:  Unassigned (shim headers)
0xFE to 0xFF:  Experimentation and testing (shim headers)

So that the difference  is clearly stated.

Ciao

L.




On 2 Jun 2020, at 19:34, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciso Luigi, please see below...

On 6/2/20, 12:11 AM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:




On 1 Jun 2020, at 07:53, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciao Luigi,
The reason is to allow to experiment with shim headers and non-shim headers at 
the same time. As you may remember shim headers have a more fixed encodng and 
must be located before non-shim headers.

   That is OK for me.

   But my question is why this:


0x7E to 0x7F:  Experimentation and testing

FM> The two above are for experimentation of NON shim headers


   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing


FM These two are for experimentation of shim headers.

Shim headers are placed (and processed) first, so we want to give the freedom 
to experiment with both.

For example, one would want to experiment with a shim header (identified by 
0xFE) that carries some special metadata for IPv4 payloads, while someone else 
would want to experiment with IPv8 payloads (identified with 0x7E). A third 
person might want to experiment, at the same time, with a shim header that 
carries special metadata for IPv8.

Fabio






   Instead of this (range has been adapted):

   0x7E to 0xFB:  Unassigned (shim headers)
   0xFC to 0xFF:  Experimentation and testing

   ??

   Certainly I am missing something ;-)

   Ciao

   L.





Thanks,
Fabio



On 5/31/20, 10:47 PM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:

  Thank you for updating the document.

  I have a quick question.

  Looking at the next protocol values we now see:

   0x7E to 0x7F:  Experimentation and testing
   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing

  Can you provide a rationale why not having just one bigger experimentation 
and testing range instead of two with an unassigned range in the middle?

  Thanks

  Ciao

  L.




On 1 Jun 2020, at 07:41, 
internet-dra...@ietf.org<mailto: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 Generic Protocol Extension
 Authors : Fabio Maino
   Jennifer Lemon
   Puneet Agarwal
   Darrel Lewis
   Michael Smith
Filename: draft-ietf-lisp-gpe-15.txt
Pages   : 15
Date: 2020-05-31

Abstract:
This document describes extentions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation.


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

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

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


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


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

[lisp] support for INT in LISP-GPE

[Fabio Maino (fmaino)]

In-Band Network Telemetry (INT) is specified in 
https://p4.org/assets/INT-current-spec.pdf.

We’ve been asked by implementors to include a codepoint in lisp-gpe to support 
that header.

I understand that the normal procedure to follow would be to write a INT draft 
that would request IANA to assign the needed codepoint. However, I believe that 
such a draft doesn’t exist and I don’t know of anyone writing it.

Is there any way we can reference in lisp-gpe that external spec and ask IANA 
to allocate a codepoint for INT?

Thanks,
Fabio

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

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Ciso Luigi, please see below...

On 6/2/20, 12:11 AM, "Luigi Iannone"  wrote:



> On 1 Jun 2020, at 07:53, Fabio Maino (fmaino)  wrote:
> 
> Ciao Luigi, 
> The reason is to allow to experiment with shim headers and non-shim 
headers at the same time. As you may remember shim headers have a more fixed 
encodng and must be located before non-shim headers.

That is OK for me. 

But my question is why this:

> 0x7E to 0x7F:  Experimentation and testing

FM> The two above are for experimentation of NON shim headers

> 0x80 to 0xFD:  Unassigned (shim headers)  
> 0xFE to 0xFF:  Experimentation and testing

>FM These two are for experimentation of shim headers. 

Shim headers are placed (and processed) first, so we want to give the freedom 
to experiment with both. 

For example, one would want to experiment with a shim header (identified by 
0xFE) that carries some special metadata for IPv4 payloads, while someone else 
would want to experiment with IPv8 payloads (identified with 0x7E). A third 
person might want to experiment, at the same time, with a shim header that 
carries special metadata for IPv8. 

Fabio

  




Instead of this (range has been adapted):

0x7E to 0xFB:  Unassigned (shim headers)
0xFC to 0xFF:  Experimentation and testing

??

Certainly I am missing something ;-)

Ciao

L.



> 
> Thanks,
> Fabio
> 
> 
> 
> On 5/31/20, 10:47 PM, "Luigi Iannone"  wrote:
> 
>Thank you for updating the document.
> 
>I have a quick question.
> 
>Looking at the next protocol values we now see:
> 
> 0x7E to 0x7F:  Experimentation and testing
> 0x80 to 0xFD:  Unassigned (shim headers)  
> 0xFE to 0xFF:  Experimentation and testing
> 
>Can you provide a rationale why not having just one bigger 
experimentation and testing range instead of two with an unassigned range in 
the middle?
> 
>Thanks
> 
>Ciao
> 
>L.
> 
> 
> 
>> On 1 Jun 2020, at 07:41, 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 Generic Protocol Extension
>>   Authors : Fabio Maino
>> Jennifer Lemon
>> Puneet Agarwal
>> Darrel Lewis
>> Michael Smith
>>  Filename: draft-ietf-lisp-gpe-15.txt
>>  Pages   : 15
>>  Date: 2020-05-31
>> 
>> Abstract:
>>  This document describes extentions to the Locator/ID Separation
>>  Protocol (LISP) Data-Plane, via changes to the LISP header, to
>>  support multi-protocol encapsulation.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-lisp-gpe-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-15
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-15
>> 
>> 
>> 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
> 
> 


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

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Hi Mirja, 
Rev -15, that was just published, should address your comments: 
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

Let me know if you have any further comment. 

Thanks,
Fabio

On 3/13/20, 4:19 AM, "Mirja Kuehlewind"  wrote:

Hi authors, hi Deborah,

Sorry for being super later on this but I was looking at this document 
again and I realised that there is still one open issue that needs fixing: I 
noticed that I also had a discuss point on guidance on DSCP which is not 
addressed yet. However, the more important and really critical point is that 
the doc talks about setting the 3-bit Type of Service (ToS) that does exist 
anymore: RFC1349 was obsoleted by RFC2474, so there is now only a 6-bit DSCP 
field. This is really a pain point in todays Internet and needs to be fixed! I 
also recommend to add a reference to RFC2474 (then this problem would maybe 
have been detected earlier). And still as my discuss says some more guidance on 
the use of DCSP would be good as well!

Thanks!
Mirja



> On 10. Jan 2020, at 20:03, BRUNGARD, DEBORAH A  wrote:
> 
> Hi Mirja,
> 
> The plan is to Last Call the set of documents (gpe, bis's) and put on a 
future telechat. First, the author teams want to ensure they have addressed all 
the current Discusses/comments and they are working to get the documents ready.
> 
> Thanks all - the documents are much improved!
> Deborah
> 
> 
> -Original Message-
> From: Mirja Kuehlewind  
> Sent: Wednesday, January 08, 2020 5:22 AM
> To: Fabio Maino (fmaino) ; BRUNGARD, DEBORAH A 

> Cc: The IESG ; lisp-cha...@ietf.org; lisp@ietf.org; 
magnus.westerl...@ericsson.com; draft-ietf-lisp-...@ietf.org; Luigi Iannone 

> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with 
DISCUSS and COMMENT)
> 
> Hi Fabio,
> 
> Thanks for all the work. Changes look good to me and I think my discuss 
comments are addressed.
> 
> One small comment/nit: I think you also should define the “Reserved” 
field in Figure 2. It’s not mention in the text, and even though the meaning is 
obvious, I assume it was an oversight that it's not described.
> 
> Given the large set of changes, it’s good that another wg last call took 
place. I think given more or less whole document has changes, it could be 
approbate to also have another IETF last call and put it back on a future 
telechat agenda. But I let Deborah decide about this. 
> 
> Deborah what's your plan here?
> 
> Mirja
> 
> 
> 
>> On 8. Jan 2020, at 00:02, Fabio Maino (fmaino)  wrote:
>> 
>> Hi Mirja,
>> It took quite some time, but I think we are finally making progress 
>> with the review of draft-ietf-lisp-gpe and the related LISP RFCbis 
>> drafts 
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dietf-2Dlisp-2Drfc6830bis_=DwIFaQ=LFYZ-o9_HUMeMTSQ
>> icvjIg=6UhGpW9lwi9dM7jYlxXD8w=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVl
>> PPk33Nw=oRnVaMWUr_mvYyEiDEkkNTuBOAIOJ_vBnr3COsvsMrI=
>> , 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_=DwIFaQ=LFYZ-o9_HUMeMTSQicvjIg=6UhGpW9lwi9dM7jYlxXD8w=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw=3I9q-AoB6EQNPtTNvKH36_EP-xCFPQESZPH7CeFoVuo=
  ).
>> 
>> Could you please take a look at the latest rev -13 of 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Dgpe_=DwIFaQ=LFYZ-o9_HUMeMTSQicvjIg=6UhGpW9lwi9dM7jYlxXD8w=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw=BueHq0NVA0sDhX7r1hme2y4YHEnu52LCy7alSTn3nIc=
 , and let us  know if we have addressed your comments?
>> 
>> Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have done 
two main changes that might help addressing your DISCUSS: 
>> 1.   We have introduced the concept of shim header, along the line 
of what Mirja suggested in her comment. The chairs thought that the change was 
significant enough to require a new last call with the WG, that we did after 
Singapore
>> 2.We have introduced section 4 that, following what done in 
RFC8085 and RFC8086, defines the scope of applicability of LISP-GPE and makes 
considerations related with congestion control, UDP checksum, and ethernet 
payload encapsulation. 
>> 
>> Please, let me know if you have any further question or suggestion. 
>> 
>> I have attached a diff from rev -05 that is the one to which your ballot 
comments were referring to. 
>> 
>> Thanks,
>> Fabio
>> 
>> 
>> On 9/20/18, 1:22 PM, "Fabio Maino&quo

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Ciao Luigi, 
The reason is to allow to experiment with shim headers and non-shim headers at 
the same time. As you may remember shim headers have a more fixed encodng and 
must be located before non-shim headers. 

Thanks,
Fabio



On 5/31/20, 10:47 PM, "Luigi Iannone"  wrote:

Thank you for updating the document.

I have a quick question.

Looking at the next protocol values we now see:

 0x7E to 0x7F:  Experimentation and testing 
 0x80 to 0xFD:  Unassigned (shim headers)   
 0xFE to 0xFF:  Experimentation and testing

Can you provide a rationale why not having just one bigger experimentation 
and testing range instead of two with an unassigned range in the middle?

Thanks

Ciao

L.



> On 1 Jun 2020, at 07:41, 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 Generic Protocol Extension
>Authors : Fabio Maino
>  Jennifer Lemon
>  Puneet Agarwal
>  Darrel Lewis
>  Michael Smith
>   Filename: draft-ietf-lisp-gpe-15.txt
>   Pages   : 15
>   Date: 2020-05-31
> 
> Abstract:
>   This document describes extentions to the Locator/ID Separation
>   Protocol (LISP) Data-Plane, via changes to the LISP header, to
>   support multi-protocol encapsulation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lisp-gpe-15
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-15
> 
> 
> 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


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

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Thanks for the quick turnaround Mirja. 

I'll add text that refers to the Reserved field in the the next rev. 

Thanks,
Fabio



On 1/8/20, 2:22 AM, "Mirja Kuehlewind"  wrote:

Hi Fabio,

Thanks for all the work. Changes look good to me and I think my discuss 
comments are addressed.

One small comment/nit: I think you also should define the “Reserved” field 
in Figure 2. It’s not mention in the text, and even though the meaning is 
obvious, I assume it was an oversight that it's not described.

Given the large set of changes, it’s good that another wg last call took 
place. I think given more or less whole document has changes, it could be 
approbate to also have another IETF last call and put it back on a future 
telechat agenda. But I let Deborah decide about this. 

Deborah what's your plan here?

Mirja



> On 8. Jan 2020, at 00:02, Fabio Maino (fmaino)  wrote:
> 
> Hi Mirja,
> It took quite some time, but I think we are finally making progress with 
the review of draft-ietf-lisp-gpe and the related LISP RFCbis drafts 
(https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
> , https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ).
> 
> Could you please take a look at the latest rev -13 of 
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/, and let us  know if we 
have addressed your comments?
> 
> Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have done 
two main changes that might help addressing your DISCUSS: 
> 1.We have introduced the concept of shim header, along the line 
of what Mirja suggested in her comment. The chairs thought that the change was 
significant enough to require a new last call with the WG, that we did after 
Singapore
> 2. We have introduced section 4 that, following what done in 
RFC8085 and RFC8086, defines the scope of applicability of LISP-GPE and makes 
considerations related with congestion control, UDP checksum, and ethernet 
payload encapsulation. 
> 
> Please, let me know if you have any further question or suggestion. 
> 
> I have attached a diff from rev -05 that is the one to which your ballot 
comments were referring to. 
> 
> Thanks,
> Fabio
> 
> 
> On 9/20/18, 1:22 PM, "Fabio Maino"  wrote:
> 
>Thanks for your notes Mirja.
> 
>I'll publish an updated rev this evening to consolidate the changes 
that 
>I believe we have agreed upon, and then I'll work on those that are 
>still open.
> 
>Please see below.
> 
> 
>On 9/19/18 12:42 PM, Mirja Kühlewind wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-lisp-gpe-05: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> Thanks for addressing the TSV-ART review (and Magnus for doing the 
review)! I
>> assume that the proposed text will be incorporated in the next version. 
(Would
>> have been even better if those (larger) changes would have been added 
before
>> the doc was put on the telechat; please update as soon as possible so 
other AD
>> can review that text as well).
>> 
>> However, I think the text still needs to say more about HOW the PCP 
should be
>> mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 
802.11.
>> Is the same mapping applicable here?
> 
>Agree. As pointed out by Magnus' latest email there's more 
investigation 
>needed here. I'll get back on this.
> 
>> 
>> Also, I'm not an expert for that part, but I guess there also is further
>> guidance needed on HOW to map the VID...?
> 
>This is really straightforward, as the VID is a 12-bit field, and the 
>IID is 24-bit. Implementation that I'm aware of typically carve a 
>portion of the IID space to encode the VID.
> 
>

Re: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Ben, 
Thanks for your comments, and happy new year! 

Please see below. 

On 12/30/19, 11:49 AM, "Benjamin Kaduk via Datatracker"  
wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Thanks for the updates in -10 through -12 to leave nonce/versioning to
additional shim headers/extensions; that does alleviate the concerns that
left me balloting Abstain on the -09.

I do have some (new) comments on the -12.

Section 3

Conceptually, I'm thinking about this document as allocating the 'P' bit in
the header and specifying its format when the P bit is set to 1; I don't
expect it to be making changes to generic non-GPE LISP behavior.  So it's
a little surprising to see that bits 0-3 are now marked as Reserved (though
that could probably be wordsmithed away, and the existing Section 2 probably
sets the reader up to do the right thing already), and fairly surprising to
see the following in the P-Bit description:

  If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
  to the definition in [I-D.ietf-lisp-rfc6830bis] with bits N, L, E
  and V set to 0.

Is the claim that once an implementation supports GPE, it will never use the
non-shim-header versions of echo-nonce, map-versioning, etc?  If not, then I
don't think it's appropriate to say "with bits N, L, E, and V set to 0"
here.

[FM] I think you make a good point, especially that we don't want to alter the 
behavior of the protocol when P=0. We can re-word the document accordingly: we 
leave NLEV bits in the header definition, and we limit the document to specify 
the behavior for the case when P=1. 

I'm also not sure I fully understand the motivation for pulling out
the Locator-Status-Bits, as that field's width is unchanged from stock
6830bis.  Leaving them to a TBD shim-header does prevent the conflict with
the Instance ID field, and perhaps the current usage patterns justify such a
shift, so this may be more of a side note than an indication of a flaw in
the document.

[FM] Indeed, there isn't a strong rationale to prevent the use of LSBs with 
GPE. Following your suggestion of specifying GPE as "allocating the P bit in 
LISP" we can leave that feature available even when P=1. 


Section 7

   LISP-GPE, as many encapsulations that use optional extensions, is
   subject to on-path adversaries that by manipulating the g-Bit and the
   packet itself can remove part of the payload.  Typical integrity

Is "g-Bit" supposed to be "P-Bit"?  I am failing to remember what the g-Bit
is, at least...

[FM] yes, typo. Will fix in next rev. 

   With LISP-GPE, issues such as data-plane spoofing, flooding, and
   traffic redirection may depend on the particular protocol payload
   encapsulated.

I'd consider adding another clause, "noting that an attacker that is
spoofing LISP-GPE traffic can claim to encapsulate any protocol payload
type" -- the risk here is based on what types the receiver's implementation
supports, not just what the legitimate sender is encapsulating.

[FM] Ok, we will address this in the next rev. 

I'll post an updated version to reflect the comments above asap. 


Thanks,
Fabio




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

Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf-lisp-gpe-09: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Ben, 
this is to pop up the lisp-gpe review as per conversation in Singapore. 

Thanks,
Fabio 

On 11/19/19, 12:00 AM, "Fabio Maino (fmaino)"  wrote:

Hi Benjamin, 
We have published rev -12 of LISP-GPE that shoukd address the down ref to 
RFC8060 that you brought up, and some changes discussed this morning in the 
LISP WG. 

Please find attached the diff file from rev. -11. 

I hope this, together with the removal of nonce, map-versioning and LSB 
features that was done in rev -11, can help to turn your Abstain into a Yes.

The document is going back into last call. 

Thanks,
Fabio

On 11/8/19, 2:09 PM, "Benjamin Kaduk"  wrote:

Hi Fabio,

That seems like a reasonable approach -- thanks for taking my comments 
into
consideration!

-Ben

On Mon, Nov 04, 2019 at 07:53:41PM +, Fabio Maino (fmaino) wrote:
> Hi Ben, 
> Here is how we propose to move forward. 
> 
> Given that with LISP-GPE we have the opportunity to add additional 
protocol features defining new shim headers, we have removed the Nonce, 
Map-Versioning, and LSBs fields from the main LISP-GPE header. 
> 
> It will then be possible to define a LISP-GPE shim header that 
includes a 64-bit (or even 128-bit) Nonce, as well as a proper Map-versioning 
and LSBs fields. That could be done with an appropriate separate draft, that 
hopefully will address the concerns about those 3 features that have been 
expressed in the review of 6830bis. 
> 
> I have attached rev -11 of the draft and a diff file that reflects 
the approach above.
> 
> It'd be great to hear your thoughts. 
> 
> We will discuss this approach with the WG in Singapore, and if 
there's support, we could go to LC right after the meeting. 
> 
> Thanks,
> Fabio
> 
>  
> 
> 
> 
> 
> 
> On 10/25/19, 5:20 PM, "Benjamin Kaduk via Datatracker" 
 wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lisp-gpe-09: Abstain
> 
> When responding, please keep the subject line intact and reply to 
all
> email addresses included in the To and CC lines. (Feel free to 
cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found 
here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
> 
> 
> 
> 
--
> COMMENT:
> 
--
> 
> Thank you for addressing my Discuss-level points (I can accept 
that for the -09
> that RFC 8060 need not be a normative reference).  I am balloting 
Abstain because
> I am uncomfortable with only 16 bits of nonce, but I recognize 
that there is a need
> for this sort of encapsulation and it must fit within the 
constraints of the core protocol.
> Though, given Alissa's Discuss, it is technically still possible 
for the core protocol to
> grow a larger nonce that would alleviate my concerns.  But, since 
the issue stems from
> a different document (and because I did not raise the issue 
earlier), it is not appropriate
> for me to ballot Discuss on this document for that point.
> 
> [original COMMENT section unchanged; contents presumably stale]
> 
> Section 1
> 
>LISP-GPE MAY also be used to extend the LISP Data-Plane 
header, that
>has allocated all by defining a Next Protocol "shim" header 
that
> 
> nit: allocated all of what?
> 
> Section 3
> 
> This is not exactly the responsibility of LISP-GPE merely because 
it
> allocates the last bit in this bitmap, but it seems like it would 
be quite
> useful to have a table of which combinations of values are valid 
vs.
> nonsensical, given the somewhat complicated interaction between 
some of
> these flag bits.
> 
>   Similarly, the en

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-12.txt

[Fabio Maino (fmaino)]

Sounds good. 

Next version will reflect this change.. 

Fabio

On 11/21/19, 10:29 AM, "Dino Farinacci"  wrote:

Ack.

Dino

> On Nov 21, 2019, at 10:27 AM, Luigi Iannone  wrote:
> 
> may be we can drop that and keep only LISP-GPE.
> 
> L.
> 
> 
> 
>> On 21 Nov 2019, at 10:26, Luigi Iannone  wrote:
>> 
>> the shim headers.
>> 
>> L.
>> 
>>> On 21 Nov 2019, at 10:25, Dino Farinacci  wrote:
>>> 
>>> What are “related features”.
>>> 
>>> Dino
>>> 
>>>> On Nov 21, 2019, at 10:17 AM, Luigi Iannone  wrote:
>>>> 
>>>> Hi Fabio,
>>>> 
>>>> I would suggest that you change the text in section 5.1 as follows:
>>>> 
>>>> OLD:
>>>> 
>>>>The detection of ETR capabilities to support multiple data 
plane 
>>>>encapsulations and shim headers is out of the scope of this 
document. 
>>>>Given that the applicability domain of LISP-GPE is a 
traffic-managed
>>>>controlled environment, ITR/ETR (xTR) configuration mechanisms 
>>>>may be used for this purpose.
>>>> 
>>>> NEW:
>>>> 
>>>>The discovery of xTR capabilities to support LISP-GPE and 
related features 
>>>>is out of the scope of this document. 
>>>>Given that the applicability domain of LISP-GPE is a 
traffic-managed
>>>>controlled environment, ITR/ETR (xTR) configuration mechanisms 
>>>>may be used for this purpose.
>>>> 
>>>> 
>>>> Other than that, the document looks good to me.
>>>> 
>>>> Ciao
>>>> 
>>>> L.
>>>> 
>>>> 
>>>> 
>>>>> On 19 Nov 2019, at 16:00, Fabio Maino (fmaino)  
wrote:
>>>>> 
>>>>> ___
>>>> 
>>>> ___
>>>> 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

[Fabio Maino (fmaino)]

Hi Luigi,
as a co-author I support adoption of this document.

It’s a very interesting use case that leverages LISP aspects such as signal 
free multicast and pub-sub that are some of the most interesting features of 
the LISP protocol stack. It’s also a very interesting example of how LISP can 
support applications that have very unique mobility requirements.

Fabio



From: lisp  on behalf of Luigi Iannone 
Date: Wednesday, November 20, 2019 at 10:41 AM
To: Sharon Barkai 
Cc: "lisp-cha...@ietf.org" , "lisp@ietf.org list" 

Subject: Re: [lisp] Support draft-nexagon wg adoption

Hi,

happy to see that there is already support for this document.

This email formally opens the two weeks WG adoption call.

Please have a look at the document and send an email on whether you agree or 
not to adopt it.
(Silence is NOT consensus)


Thanks


Ciao


L.








On 19 Nov 2019, at 13:36, Sharon Barkai 
mailto:sharon.bar...@getnexar.com>> 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

Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-08: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Thanks Benjamin, 
Moving 8060 to normative was my unintentional mistake, sorry. We had actually 
reduced the dependency from 8060 in rev -08. 

I've just published -09 that brings 8060 back to informative (and also 
addresses the 'partial mitigation' comment). 
 
Thanks,
Fabio


On 10/24/19, 5:45 PM, "Benjamin Kaduk via Datatracker"  
wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
DISCUSS:
--

Thank you for the updates in the -08!
Can you please say "partially mitigates" instead of "mitigates" in "However,
the use of common anti-spoofing mechanisms such as uRPF mitigates this
form of attack."?

Now that RFC 8060 is a normative reference, it's a downref that I believe 
will
need to be IETF LC'd again.


--
COMMENT:
--

[original COMMENT section unchanged; contents presumably stale]

Section 1

   LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
   has allocated all by defining a Next Protocol "shim" header that

nit: allocated all of what?

Section 3

This is not exactly the responsibility of LISP-GPE merely because it
allocates the last bit in this bitmap, but it seems like it would be quite
useful to have a table of which combinations of values are valid vs.
nonsensical, given the somewhat complicated interaction between some of
these flag bits.

  Similarly, the encoding of the Source and Dest Map-Version fields,
  compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
  bits.  This still allows to associate 256 different versions to
  each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
  to inform commmunicating ITRs and ETRs about modifications of the
  mapping.

Are we limited to 256 versions total, or is there some sort of larger
version space that we truncate to send (a la a wraparound process)?
I understand that map-versioning is primarily in a separate document but it
seems important for this document to describe to what extent it is limiting
functionality.

Section 3.1

   To ensure that protocols that are encapsulated in LISP-GPE will work
   well from a transport interaction perspective, the specification of a
   new encapsulated payload MUST contain an analysis of how LISP-GPE
   SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
   Congestion Notification (ECN) bits whenever they apply to the new
   encapsulated payload.

This MUST is duplicated in the next three paragraphs; I would suggest
leaving this introduction as non-normative, with something like "needs to
contain an analysis of how LISP-GPE will deal with [...]"
Also, nit: "the outer UDP Checksum"

Section 4

   When encapsulating IP packets to a non LISP-GPE capable router the
   P-bit MUST be set to 0.  [...]

   A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
   P-bit set to 1) to a non-LISP-GPE capable router.

I'm failing to see how these two sentences are not redundant.

Section 5.1

Just to be clear, the intent is that if there is some non-IETF protocol
that we want to encapsulate, we write a two-page Standards-Track RFC that
says "this GPE codepoint means to do what this non-IETF document says"?

Section 6

   However, the use of common anti-spoofing
   mechanisms such as uRPF prevents this form of attack.

I think "mitigates" is probably better than "prevents" in this case.

   LISP-GPE, as many encapsulations that use optional extensions, is
   subject to on-path adversaries that by manipulating the g-Bit and the
   packet itself can remove part of the payload.  Typical integrity
   protection mechanisms (such as IPsec) SHOULD be used in combination
   with LISP-GPE by those protocol extensions that want to protect from
   on-path attackers.

The g-Bit is present in the Map-Reply message, which can in the general

Re: [lisp] [Call for Agenda Items] IETF 105 Preliminary Agenda

[Fabio Maino (fmaino)]

Luigi,
Sorry this is coming very late, but can I  have 10 min for an update on 
LISP-SEC?

Thanks,
Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, June 25, 2019 at 12:04 AM
To: "lisp@ietf.org list" 
Subject: [lisp] [Call for Agenda Items] IETF 105 Preliminary Agenda

All,

The preliminary agenda for our meeting in Montreal has been published: 
https://datatracker.ietf.org/meeting/105/agenda.html

We will meet Monday Afternoon 13:30 -> 15:30 on July 22.

While the agenda is still subject to changes it is time to think about 
presentation slots.

Please send your requests for agenda items (Presenter’s name, title, slot 
duration)
to lisp-cha...@tools.ietf.org

Ciao

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

Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt)

[Fabio Maino (fmaino)]

Hi Mohamed,
Thanks again for your comments.

They should be addressed by rev -18.

See my previous message to the list for the details.

Thanks,
Fabio

From: lisp  on behalf of "mohamed.boucad...@orange.com" 

Date: Monday, January 28, 2019 at 11:50 PM
To: Luigi Iannone , "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt)

Hi Luigi, all,

FWIW, please find some comments to this document at :


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-lisp-sec-17-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-lisp-sec-17-rev%20Med.doc

These are easy to fix.

Cheers,
Med

De : lisp [mailto:lisp-boun...@ietf.org] De la part de Luigi Iannone
Envoyé : lundi 28 janvier 2019 14:30
À : lisp@ietf.org list
Cc : lisp-cha...@ietf.org
Objet : [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt)

Hi All,

since work on bis documents is re-starting to move forward it is about time to 
move forward other pieces of the LISP ecosystem.

As such the LISP Security document has been revised a while ago for two reason:
- Make sure is PS quality
- Make sure it is compliant with latest changes in the bis documents.

The second point has been re-checked by the authors just last week, and seems 
we are ready to move the document forward.

This email open the usual two weeks Working Group Last Call, to end February 
11th, 2019.

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-iannone-6834bis in state "In WG Last Call"

[Fabio Maino (fmaino)]

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

Re: [lisp] Preliminary Agenda Available

[Fabio Maino (fmaino)]

Given that the impact draft is mentioned in the charter, can we push that item 
as the first of the non wg docs in the agenda?


Thanks,
Fabio

--
Sent via my LISP-MN phone
(LISPmob.org)



 Original message 
From: Luigi Iannone g...@gigix.net
Date: 10/28/2014 4:42 AM (GMT-08:00)
To: LISP mailing list list lisp@ietf.org
Subject: [lisp] Preliminary Agenda Available


Hi All,

the preliminary agenda is now available at 
http://www.ietf.org/proceedings/91/agenda/agenda-91-lisp

Please let the chairs know if you have any comment/correction by Monday 
November 3 at latest

ciao

L.

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