[lisp] Re: Call for adoption for documents 6831bis and 8378bis

[Prakash Jain (prakjain)]

Support!

From: Luigi Iannone 
Date: Thursday, August 1, 2024 at 5:04 AM
To: LISP mailing list list 
Cc: lisp-cha...@ietf.org 
Subject: [lisp] Call for adoption for documents 6831bis and 8378bis
Hi All,

the bis documents about multicast, namely:

The Locator/ID Separation Protocol (LISP) for Multicast Environments 
https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6831bis/
Signal-Free Locator/ID Separation Protocol (LISP) Multicast 
https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc8378bis/

Were discussed in Vancouver 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.
Comments with motivation or explanation are preferred.

Silence does NOT mean consent.

This call will last for 2 weeks.
Thank you,
Luigi, Padma, Alberto
___
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org

[lisp] Re: draft-ietf-pim-jp-extensions-lisp wglc

[Prakash Jain (prakjain)]

Support!



From: Michael McBride 
Sent: Wednesday, May 22, 2024 9:35:13 PM
To: p...@ietf.org 
Cc: lisp@ietf.org 
Subject: [lisp] draft-ietf-pim-jp-extensions-lisp wglc

Hi all,

Today begins a 2 week wglc for 
https://datatracker.ietf.org/doc/draft-ietf-pim-jp-extensions-lisp/. We had a 
wglc a year ago and we didn’t get much response and our AD didn’t think it was 
quite ready. It’s been updated and ready for another wglc. It’s experimental 
and would update 8059 (which is also experimental). Please respond over the 
next two weeks.

Thanks,
mike

___
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org

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

[Prakash Jain (prakjain)]

Support.
-Prakash

From: lisp  on behalf of Lori Jakab 

Date: Tuesday, January 23, 2024 at 2:02 AM
To: lisp@ietf.org 
Subject: Re: [lisp] Moving draft-ietf-lisp-name-encoding to standard track?
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é 
mailto:jordi.pailli...@upc.edu>> 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 work items list [WAS: Re: Proposed WG Charter on GitHub]

[Prakash Jain (prakjain)]

Never mind, confusion was due to ‘-‘ in the unchanged text of the unified diff. 
Split diff shows correctly that LISP External Connectivity text is not removed, 
so I am good with it.
Thanks,
Prakash

From: lisp  on behalf of Prakash Jain (prakjain) 

Date: Monday, October 23, 2023 at 11:26 AM
To: Padma Pillay-Esnault , Alberto Rodriguez-Natal 
(natal) 
Cc: lisp-cha...@ietf.org , LISP mailing list list 

Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Apologies for jumping little late and if I missed some part of the discussion. 
I thought we agreed to add external connectivity work, are we removing it now 
(In diff I only see – sign, don’t see + sign)?


- LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be 
used to connect LISP sites with non-LISP sites. However, LISP deployments could 
benefit from more advanced internetworking, for instance by defining mechanism 
to discover such external connectivity.

Thanks,
Prakash

From: lisp  on behalf of Padma Pillay-Esnault 

Date: Sunday, October 22, 2023 at 11:38 PM
To: Alberto Rodriguez-Natal (natal) 
Cc: lisp-cha...@ietf.org , LISP mailing list list 

Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Hi All

I have made another pass to integrate Alvaro's editorial changes.
Please review and approve.

https://github.com/lisp-wg/wg-charter/pull/12/files

Thanks
Padma

On Sat, Oct 21, 2023 at 1:06 AM Padma Pillay-Esnault 
mailto:padma.i...@gmail.com>> wrote:
Approved and Merged.

Padma

On Fri, Oct 20, 2023 at 8:15 AM Alberto Rodriguez-Natal (natal) 
mailto:na...@cisco.com>> wrote:
Sounds good, updated.

Alberto

From: Dino Farinacci mailto:farina...@gmail.com>>
Date: Friday, October 20, 2023 at 4:02 PM
To: Alberto Rodriguez-Natal (natal) mailto:na...@cisco.com>>
Cc: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>, 
Luigi Iannone mailto:g...@gigix.net>>, LISP mailing list list 
mailto:lisp@ietf.org>>, 
lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> 
mailto:lisp-cha...@ietf.org>>
Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
I would phrase it “LISP xTRs” rather than “tunnel routers”.

Dino

On Oct 20, 2023, at 2:26 AM, Alberto Rodriguez-Natal (natal) 
mailto:na...@cisco.com>> wrote:

Hi Padma,

Fixes seem fine to me, thanks!

Maybe another suggestion, how about this text for mobility?

“Mobility: Some LISP deployment scenarios include endpoints that move across 
different tunnel routers and/or tunnel routers that are themselves mobile, 
hence, support needs to be provided in order to achieve seamless connectivity.”

https://github.com/lisp-wg/wg-charter/pull/11/

Thanks!
Alberto
From: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>
Date: Friday, October 20, 2023 at 7:53 AM
To: Alberto Rodriguez-Natal (natal) mailto:na...@cisco.com>>
Cc: Luigi Iannone mailto:g...@gigix.net>>, Dino Farinacci 
mailto:farina...@gmail.com>>, LISP mailing list list 
mailto:lisp@ietf.org>>, 
lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> 
mailto:lisp-cha...@ietf.org>>
Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Hi everyone,

I fixed some nits and addressed my previous editorial comments on "Moving to 
Standards Track:" and "Yang Model:".
It can be found here https://github.com/lisp-wg/wg-charter/pull/10/files.

Let me know if you have any further comments.

Thanks
Padma

On Wed, Oct 18, 2023 at 11:38 PM Padma Pillay-Esnault 
mailto:padma.i...@gmail.com>> wrote:
Approved and merged.


On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) 
mailto:na...@cisco.com>> wrote:
Hi all,

I just sent a PullRequest in GitHub with some edits. You can find it here: 
https://github.com/lisp-wg/wg-charter/pull/9

To keep the discussion on the list, here are the main points:

- I switched the Name Encoding and Yang deliverable dates. I have action items 
on both (shepherd for the first and author for the second), and I feel Yang 
might require some time to get it done, while Name Encoding is almost there. I 
don’t think flipping these two dates has major implications.

- I removed this sentence from the Yang item: “These management methods should 
be considered for both the data-plane, control plane, and mapping system 
components.” I think it is probably redundant and it might confuse more than 
clarify (isn’t mapping system a subset of control plane?)

- I polished the language on the milestones to be consistent across the 
different items (using the same sentence structure, etc). I also use 
“document(s)” for the document bundles and those items further in the future, 
so we are flexible in how to address them.

Other than that, it’s just minor edits. Let me know if you have any comment.

Thanks!
Alberto


From: Luigi Iannone mailto:g...@gigix.net>>
Date: Tuesday, October 17

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Prakash Jain (prakjain)]

Apologies for jumping little late and if I missed some part of the discussion. 
I thought we agreed to add external connectivity work, are we removing it now 
(In diff I only see – sign, don’t see + sign)?


- LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be 
used to connect LISP sites with non-LISP sites. However, LISP deployments could 
benefit from more advanced internetworking, for instance by defining mechanism 
to discover such external connectivity.

Thanks,
Prakash

From: lisp  on behalf of Padma Pillay-Esnault 

Date: Sunday, October 22, 2023 at 11:38 PM
To: Alberto Rodriguez-Natal (natal) 
Cc: lisp-cha...@ietf.org , LISP mailing list list 

Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Hi All

I have made another pass to integrate Alvaro's editorial changes.
Please review and approve.

https://github.com/lisp-wg/wg-charter/pull/12/files

Thanks
Padma

On Sat, Oct 21, 2023 at 1:06 AM Padma Pillay-Esnault 
mailto:padma.i...@gmail.com>> wrote:
Approved and Merged.

Padma

On Fri, Oct 20, 2023 at 8:15 AM Alberto Rodriguez-Natal (natal) 
mailto:na...@cisco.com>> wrote:
Sounds good, updated.

Alberto

From: Dino Farinacci mailto:farina...@gmail.com>>
Date: Friday, October 20, 2023 at 4:02 PM
To: Alberto Rodriguez-Natal (natal) mailto:na...@cisco.com>>
Cc: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>, 
Luigi Iannone mailto:g...@gigix.net>>, LISP mailing list list 
mailto:lisp@ietf.org>>, 
lisp-cha...@ietf.org 
mailto:lisp-cha...@ietf.org>>
Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
I would phrase it “LISP xTRs” rather than “tunnel routers”.

Dino

On Oct 20, 2023, at 2:26 AM, Alberto Rodriguez-Natal (natal) 
mailto:na...@cisco.com>> wrote:

Hi Padma,

Fixes seem fine to me, thanks!

Maybe another suggestion, how about this text for mobility?

“Mobility: Some LISP deployment scenarios include endpoints that move across 
different tunnel routers and/or tunnel routers that are themselves mobile, 
hence, support needs to be provided in order to achieve seamless connectivity.”

https://github.com/lisp-wg/wg-charter/pull/11/

Thanks!
Alberto
From: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>
Date: Friday, October 20, 2023 at 7:53 AM
To: Alberto Rodriguez-Natal (natal) mailto:na...@cisco.com>>
Cc: Luigi Iannone mailto:g...@gigix.net>>, Dino Farinacci 
mailto:farina...@gmail.com>>, LISP mailing list list 
mailto:lisp@ietf.org>>, 
lisp-cha...@ietf.org 
mailto:lisp-cha...@ietf.org>>
Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Hi everyone,

I fixed some nits and addressed my previous editorial comments on "Moving to 
Standards Track:" and "Yang Model:".
It can be found here https://github.com/lisp-wg/wg-charter/pull/10/files.

Let me know if you have any further comments.

Thanks
Padma

On Wed, Oct 18, 2023 at 11:38 PM Padma Pillay-Esnault 
mailto:padma.i...@gmail.com>> wrote:
Approved and merged.


On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) 
mailto:na...@cisco.com>> wrote:
Hi all,

I just sent a PullRequest in GitHub with some edits. You can find it here: 
https://github.com/lisp-wg/wg-charter/pull/9

To keep the discussion on the list, here are the main points:

- I switched the Name Encoding and Yang deliverable dates. I have action items 
on both (shepherd for the first and author for the second), and I feel Yang 
might require some time to get it done, while Name Encoding is almost there. I 
don’t think flipping these two dates has major implications.

- I removed this sentence from the Yang item: “These management methods should 
be considered for both the data-plane, control plane, and mapping system 
components.” I think it is probably redundant and it might confuse more than 
clarify (isn’t mapping system a subset of control plane?)

- I polished the language on the milestones to be consistent across the 
different items (using the same sentence structure, etc). I also use 
“document(s)” for the document bundles and those items further in the future, 
so we are flexible in how to address them.

Other than that, it’s just minor edits. Let me know if you have any comment.

Thanks!
Alberto


From: Luigi Iannone mailto:g...@gigix.net>>
Date: Tuesday, October 17, 2023 at 2:01 PM
To: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>
Cc: Dino Farinacci mailto:farina...@gmail.com>>, LISP 
mailing list list mailto:lisp@ietf.org>>, 
lisp-cha...@ietf.org 
mailto:lisp-cha...@ietf.org>>
Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Hi Dino, Padma,

The list of milestones I proposed does not have more than 2 item per deadline, 
which is reasonable to me.
However, some milestones do indeed refer to several documents like Privacy and 
Security, Multicast, and mobility.
IMO there is no need to list the detailed documents and if we finish

Re: [lisp] Call for adoption for document draft-farinacci-lisp-decent

[Prakash Jain (prakjain)]

I support as it could help in scaling of co-located MSMR (with xTRs) which many 
of LISP Enterprise deployments use today (and if those need to scale out).
Thanks,
Prakash

From: lisp  on behalf of Luigi Iannone 
Date: Thursday, October 12, 2023 at 5:35 AM
To: LISP mailing list list 
Cc: lisp-cha...@ietf.org 
Subject: [lisp] Call for adoption for document draft-farinacci-lisp-decent
Hi All,

As you may have seen in the thread about the WG rechartering, authors of the 
document "A Decent LISP Mapping System (LISP-Decent)” did ask the chairs to 
open a call for adoption.
See message: 
https://mailarchive.ietf.org/arch/msg/lisp/6QXqTtDYalSIN9740queg7ZuvYc/
You can find the document at: 
https://datatracker.ietf.org/doc/draft-farinacci-lisp-decent/

This email formally opens the two weeks Call for Adoption.

If you are supporting adoption, please state so.
If you have concerns, please detail them.

The call will close on October 26, 2023.

Luigi, Padma, Alberto
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Prakash Jain (prakjain)]

Thanks a lot, I am fine with it.
Cheers,
Prakash

From: Luigi Iannone 
Date: Tuesday, October 10, 2023 at 6:13 AM
To: Prakash Jain (prakjain) 
Cc: Alberto Rodriguez-Natal (natal) , Padma 
Pillay-Esnault , LISP mailing list list , 
lisp-cha...@ietf.org 
Subject: Re: Proposed WG Charter on GitHub
I submitted a new PL to add this item and the TE document (as pointed out by 
Dino);

Please review at: https://github.com/lisp-wg/wg-charter/pull/6

Ciao

L.



On Oct 10, 2023, at 00:58, Prakash Jain (prakjain)  wrote:

Hi All,
Should we include ‘External connectivity’ 
(https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/) 
work too in the charter as its close to the adoption or it needs to be adopted 
first?
Thanks,
Prakash


From: lisp mailto:lisp-boun...@ietf.org>> on behalf of 
Alberto Rodriguez-Natal (natal) 
mailto:natal=40cisco@dmarc.ietf.org>>
Date: Monday, October 9, 2023 at 3:25 PM
To: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>, 
LISP mailing list list mailto:lisp@ietf.org>>
Cc: lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> 
mailto:lisp-cha...@ietf.org>>
Subject: Re: [lisp] Proposed WG Charter on GitHub
Hi all,

I need to catch up with the conversation on this thread (I’ll get to that soon).

I wanted to send a quick note that we missed Reliable Transport on the new 
charter, but I see that Luigi has opened a PR on that today, thanks Luigi!

Alberto

From: Padma Pillay-Esnault mailto:padma.i...@gmail.com>>
Date: Sunday, October 1, 2023 at 7:46 PM
To: LISP mailing list list mailto:lisp@ietf.org>>
Cc: lisp-cha...@ietf.org<mailto:lisp-cha...@ietf.org> 
mailto:lisp-cha...@ietf.org>>
Subject: Proposed WG Charter on GitHub
Hello all,

We have created a repository to gather input for the proposed LISP WG charter 
presented in our last meeting.

A pointer to the repo below
https://github.com/lisp-wg/wg-charter

We welcome your comments and contributions.

Thanks
Padma and Luigi

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

Re: [lisp] Proposed WG Charter on GitHub

[Prakash Jain (prakjain)]

Hi All,
Should we include ‘External connectivity’ 
(https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/) 
work too in the charter as its close to the adoption or it needs to be adopted 
first?
Thanks,
Prakash


From: lisp  on behalf of Alberto Rodriguez-Natal (natal) 

Date: Monday, October 9, 2023 at 3:25 PM
To: Padma Pillay-Esnault , LISP mailing list list 

Cc: lisp-cha...@ietf.org 
Subject: Re: [lisp] Proposed WG Charter on GitHub
Hi all,

I need to catch up with the conversation on this thread (I’ll get to that soon).

I wanted to send a quick note that we missed Reliable Transport on the new 
charter, but I see that Luigi has opened a PR on that today, thanks Luigi!

Alberto

From: Padma Pillay-Esnault 
Date: Sunday, October 1, 2023 at 7:46 PM
To: LISP mailing list list 
Cc: lisp-cha...@ietf.org 
Subject: Proposed WG Charter on GitHub
Hello all,

We have created a repository to gather input for the proposed LISP WG charter 
presented in our last meeting.

A pointer to the repo below
https://github.com/lisp-wg/wg-charter

We welcome your comments and contributions.

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

Re: [lisp] I-D Action: draft-jain-lisp-site-external-connectivity-08.txt

[Prakash Jain (prakjain)]

Thanks Dino, appreciate the review feedbacks from you, Padma and others in LISP 
WG.
Hoping it to be adopted by WG to further work on it.
Cheers,
Prakash


From: lisp  on behalf of Dino Farinacci 

Sent: Friday, March 31, 2023, 8:47 AM
To: internet-dra...@ietf.org 
Cc: lisp@ietf.org list 
Subject: Re: [lisp] I-D Action: 
draft-jain-lisp-site-external-connectivity-08.txt

Prakash, I reviewed the diff and the changes look real good to me.

Thanks,
Dino

> On Mar 28, 2023, at 4:02 AM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>   Title   : LISP Site External Connectivity
>   Authors : Prakash Jain
> Victor Moreno
> Sanjay Hooda
>   Filename: draft-jain-lisp-site-external-connectivity-08.txt
>   Pages   : 7
>   Date: 2023-03-27
>
> Abstract:
>   This draft defines how to register/retrieve pETR mapping information
>   in LISP when the destination is not registered/known to the local
>   site and its mapping system (e.g. the destination is an internet or
>   external site destination).
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-jain-lisp-site-external-connectivity-08
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-jain-lisp-site-external-connectivity-08
>
> 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] draft-jain-lisp-site-external-connectivity comments/discussion

[Prakash Jain (prakjain)]

FYI, updated the latest draft with comments taken care.

https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/08/

Thanks,
Prakash


On 1/10/23, 5:16 PM, "Prakash Jain (prakjain)" mailto:prakj...@cisco.com>> wrote:


Hi Dino,
Thanks for the reply, follow-up clarification inline (PJ>>>),




On 1/10/23, 3:24 PM, "Dino Farinacci" mailto:farina...@gmail.com> <mailto:farina...@gmail.com 
<mailto:farina...@gmail.com>>> wrote:




> • (Dino): Elaborate on the update mechanisms/message types ( legacy LISP or 
> pub-sub preferred??).
> (Authors): A shorter TTL would be a simple measure to allow update in non 
> pub-sub (Standard/Legacy LISP) mode. With pub-sub, N-bit would be set in a 
> Map-Request, then Map-Notify messages would be sent to subscribed ITRs as per 
> the PubSub specification. With pub-sub, later option could be preferred as it 
> would be faster.








I don't believe we should have a non PubSub option. Its what we have now to 
update xTRs map-caches. Its slow and we can do better. Since we have PubSub in 
a mature state, we should have this design depend on it fully.


PJ>>> As per current draft, both options are available, however we are open to 
discuss and conclude it either way for the best solution. Would like to hear if 
any other opinion on this.




> • (Padma): Elaborate of how pETR map-reply would be installed/used at ITR (so 
> that no forwarding inefficiencies to send every packet to pxTR)
> (Authors): ITR would encapsulate the packets to the pETRs for only non-EIDs 
> destinations (for both “EIDs not registered with the Mapping System, or 
> simply are not known" as mentioned in the draft) since more specific entries 
> would already be present for known overlay subnets/EID-block-range at ITR to 
> generate map-request. 




EIDs not registered are not non-EIDs. Destinations that are unknown are 
non-EIDs. Your parantetical comment is misleading. 


PJ>>> Ok, will clarify. Parenthetical comment is the text from the draft for 
the EIDs not registered to the mapping system which can be encapsulated to 
pETRs (implementation can still choose what to encapsulate at ITR), its not the 
definition of 'non-EIDs'.




What we agreed on was this:




(1) Define an EID-block. Destinations that match this block are map-requested.
(2) Destinations not in an EID-block are non-EIDs and are encapsulated to the 
pETR.




PJ>>> Correct.


Thanks,
Prakash















___
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

[Prakash Jain (prakjain)]

Please include/keep draft-jain-lisp-site-external-connectivity as a work item 
for moving forward, we are currently working on it.



Thanks,

Prakash


From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, March 14, 2023 at 2:46 AM
To: "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: [lisp] Rechartering Thread 1: Promised work item: work items currently 
in the charter but not finished

Hi LISP WG,




As for the subject, this email starts the discussion about: Promised work item: 
work items currently in the charter but not finished

There are a bunch of unfinished WG drafts promised in the charter, namely:

LISP Mobility: candidate document LISP-MN but does not solve everything should 
we enlarge the scope?
LISP Yang Model: We are pretty close to finish this one
LISP NAT Traversal: we have a candidate document

The above documents look like we should make an effort and finish them.

There are also a bunch of WG documents that for which we should decide what to 
do (https://datatracker.ietf.org/wg/lisp/documents/)

Does the WG consider we need to move all of them forward (and in this case we 
need people to commit in finishing them) or should some of them be dropped?

Please send us back your thoughts.


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

Re: [lisp] draft-jain-lisp-site-external-connectivity comments/discussion

[Prakash Jain (prakjain)]

Will do.
Thanks,
Prakash

On 1/10/23, 6:25 PM, "Dino Farinacci" mailto:farina...@gmail.com>> wrote:






> On Jan 10, 2023, at 5:16 PM, Prakash Jain (prakjain)  <mailto:prakj...@cisco.com>> wrote:
> 
> PJ>>> As per current draft, both options are available, however we are open 
> to discuss and conclude it either way for the best solution. Would like to 
> hear if any other opinion on this.


Please lead the design with Pubsub and then in a trailing paragraph indicate 
“If pubsub is not available in the mapping system, then use the procedures from 
RFC 9301 for updating map-caches”. 


Dino

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

Re: [lisp] draft-jain-lisp-site-external-connectivity comments/discussion

[Prakash Jain (prakjain)]

Hi Dino,
Thanks for the reply, follow-up clarification inline (PJ>>>),


On 1/10/23, 3:24 PM, "Dino Farinacci" mailto:farina...@gmail.com>> wrote:


> • (Dino): Elaborate on the update mechanisms/message types ( legacy LISP or 
> pub-sub preferred??).
> (Authors): A shorter TTL would be a simple measure to allow update in non 
> pub-sub (Standard/Legacy LISP) mode. With pub-sub, N-bit would be set in a 
> Map-Request, then Map-Notify messages would be sent to subscribed ITRs as per 
> the PubSub specification. With pub-sub, later option could be preferred as it 
> would be faster.




I don't believe we should have a non PubSub option. Its what we have now to 
update xTRs map-caches. Its slow and we can do better. Since we have PubSub in 
a mature state, we should have this design depend on it fully.

PJ>>> As per current draft, both options are available, however we are open to 
discuss and conclude it either way for the best solution. Would like to hear if 
any other opinion on this.


> • (Padma): Elaborate of how pETR map-reply would be installed/used at ITR (so 
> that no forwarding inefficiencies to send every packet to pxTR)
> (Authors): ITR would encapsulate the packets to the pETRs for only non-EIDs 
> destinations (for both “EIDs not registered with the Mapping System, or 
> simply are not known" as mentioned in the draft) since more specific entries 
> would already be present for known overlay subnets/EID-block-range at ITR to 
> generate map-request. 


EIDs not registered are not non-EIDs. Destinations that are unknown are 
non-EIDs. Your parantetical comment is misleading. 

PJ>>> Ok, will clarify. Parenthetical comment is the text from the draft for 
the EIDs not registered to the mapping system which can be encapsulated to 
pETRs (implementation can still choose what to encapsulate at ITR), its not the 
definition of 'non-EIDs'.


What we agreed on was this:


(1) Define an EID-block. Destinations that match this block are map-requested.
(2) Destinations not in an EID-block are non-EIDs and are encapsulated to the 
pETR.


PJ>>> Correct.

Thanks,
Prakash






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

[lisp] draft-jain-lisp-site-external-connectivity comments/discussion

[Prakash Jain (prakjain)]

Happy New Year All,
Thanks for the comments on 
draft-jain-lisp-site-external-connectivity
 during IETF 115, London as well as the offline discussions with the reviewers 
afterwards. Here is the follow-up of that discussion to update on the mailing 
list as well to solicit any further comments (apologies for the delay in the 
update due to holidays and availability of the authors),

  1.  (WG) Overall WG showed interest in the draft as it addresses/provides the 
capability of the dynamic pxTR updates or dynamic external connectivity of LISP 
site.
(Authors): Really appreciate the interest, would like to work with WG to take 
it further.

  1.  (Dino): Elaborate on the update mechanisms/message types  ( legacy LISP 
or pub-sub preferred??).

(Authors): A shorter TTL would be a simple measure to allow update in non 
pub-sub (Standard/Legacy LISP) mode. With pub-sub, N-bit would be set in a 
Map-Request, then Map-Notify messages would be sent to subscribed ITRs as per 
the PubSub specification. With pub-sub, later option could be preferred as it 
would be faster.

  1.  (Padma): Elaborate of how pETR map-reply would be installed/used at ITR 
(so that no forwarding inefficiencies to send every packet to pxTR)
(Authors): ITR would encapsulate the packets to the pETRs for only non-EIDs 
destinations (for both “EIDs not registered with the Mapping System, or simply 
are not known" as mentioned in the draft) since more specific entries would 
already be present for known overlay subnets/EID-block-range at ITR to generate 
map-request.
To decide on encapsulate to pETRs, one or more of the following map-cache 
entries could be installed/used at ITRs,
a) “Hole prefix” entries as part of “pETR Resolution” mentioned in this draft 
for the destination prefix map-requests.
b) Catch-all or 0/0 entries as part of “pETR Request” for the registered 
"Distinguished Name EID-Prefix” on the boot up or initialization.
Please let us know if any additional comments/questions or if we missed 
anything.
From the discussions so far, authors and reviewers are in sync, we (authors) 
would publish a new draft with all the comments addressed.
 Thanks,
Prakash

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

Re: [lisp] LISP PubSub to Proposed Standard?

[Prakash Jain (prakjain)]

+1
- Prakash

On 12/8/22, 8:09 AM, "lisp on behalf of Sharon Barkai"  wrote:

++

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Dec 8, 2022, at 18:02, Dino Farinacci  wrote:
> 
> 
>> 
>> Hi Luigi, all,
>> 
>> I also think that it is reasonable to publish this spec as a proposed 
standard.
> 
> +1. 
> 
> 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] lisp - Requested session has been scheduled for IETF 115

[Prakash Jain (prakjain)]

We would like to present draft-jain-lisp-site-external-connectivity.

Thanks,
Prakash



From: lisp  on behalf of Dino Farinacci 

Sent: Saturday, October 15, 2022, 10:37 AM
To: Sharon Barkai 
Cc: lisp-cha...@ietf.org ; lisp@ietf.org 
Subject: Re: [lisp] lisp - Requested session has been scheduled for IETF 115

I would like to give an update on draft-farinacci-lisp-satellite-network.

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.

I would like  to make it official because it tracks the same encoding of 
geo-coordinates that is proposed for OSPF, ISIS, and BGP. Like name-encoding 
it’s a very short draft. So I encourage the WG to please review it.

Thanks,
Dino

> On Oct 15, 2022, at 2:20 AM, Sharon Barkai 
>  wrote:
>
> 
> Dear Chairs,
>
> Would like to give update on ietf-lisp-nexagon progress since Vienna:
>
> 1) H3 EID LCAF specification added
>
> 2) H3geo.org and BDD reviews and fixes
> - calculating H3EID from H3 detection ID
> - enumerating frequently changing signs
>
> 3) Public AECC PoC by Nexar, KDDI, Oracle
> - detect free parking spaces
> - KDDI Access RTRs, Oracle Edge RTRs
> - Nexar AICam, Edge application stacks
> - Next: + lane blockages, Equinix, P5G
>
> 4) LISP nexagon RTM economics:
> - app-routing own mobility and elasticity
> - 15x cost reduction (commercially viable)
> - 100x frequency increase (ext. use-cases)
>
> *RTM: realtime mapping enumerated channels of road conditions and base-map 
> change detections tile by tile.
>
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
>
>> On Oct 15, 2022, at 01:48, IETF Secretariat  wrote:
>>
>> Dear Luigi Iannone,
>>
>> The session(s) that you have requested have been scheduled.
>> Below is the scheduled session information followed by
>> the original request.
>>
>>
>>   lisp Session 1 (1:00 requested)
>>   Tuesday, 8 November 2022, Session IV 1630-1730
>>   Room Name: Richmond 2 size: 80
>>   -
>>
>>
>> iCalendar: https://datatracker.ietf.org/meeting/115/sessions/lisp.ics
>>
>> Request Information:
>>
>>
>> -
>> Working Group Name: Locator/ID Separation Protocol
>> Area Name: Routing Area
>> Session Requester: Luigi Iannone
>>
>>
>> Number of Sessions: 1
>> Length of Session(s):
>> Number of Attendees: 30
>> Conflicts to Avoid:
>>
>>
>> Can't meet: Wednesday morning, Wednesday early afternoon, Wednesday late 
>> afternoon, Thursday morning, Thursday early afternoon, Thursday late 
>> afternoon, Friday morning, Friday early afternoon, Friday late afternoon
>>
>> People who must be present:
>> Alvaro Retana
>> Joel M. Halpern
>> Luigi Iannone
>> Padma Pillay-Esnault
>>
>> Resources Requested:
>>
>> Special Requests:
>> Would be preferable if LISP can meet Monday or Tuesday because of 
>> unavailability of one of the main contributors the other days. Yet, no big 
>> deal if not possible.
>> -
>>
>>
>> ___
>> 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] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)

[Prakash Jain (prakjain)]

> But even with same vendor but old implementation, the LCAF type should be 
> ignored by old when new sends to old.

Yes, agree.
Thanks,
Prakash

On 4/13/22, 2:39 PM, "Dino Farinacci"  wrote:



> On Apr 13, 2022, at 2:33 PM, Prakash Jain (prakjain)  
wrote:
> 
> Since its vendor specific LCAF, vendor might intend to use this for its 
vendor spefic usage/purpose in generic lisp message. Means, if recever is same 
vendor as transmitter, that usage is applicable, otherwise ignore/drop vendor 
specific LCAF but generic lisp message should still be procssed as per lisp 
specification.

Agree.

But even with same vendor but old implementation, the LCAF type should be 
ignored by old when new sends to old. 

Dino

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

Re: [lisp] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)

[Prakash Jain (prakjain)]

Since its vendor specific LCAF, vendor might intend to use this for its vendor 
spefic usage/purpose in generic lisp message. Means, if recever is same vendor 
as transmitter, that usage is applicable, otherwise ignore/drop vendor specific 
LCAF but generic lisp message should still be procssed as per lisp 
specification.

Hence, for unknown LCAF, only tlv should be droped and not whole message.

My 2 cents..
Thanks,
Prakash



From: lisp  on behalf of Alvaro Retana 

Sent: Wednesday, April 13, 2022, 4:39 AM
To: lisp@ietf.org
Cc: lisp-cha...@ietf.org; draft-ietf-lisp-vendor-l...@ietf.org
Subject: [lisp] Unknown LCAF Types (?) (draft-ietf-lisp-vendor-lcaf)

Hi!

The recent GenArt review and the comment about unknown OUIs got me
thinking.  What should a LISP device do if it receives an unknown LCAF
Type?

It seems to me that the intent is to tightly control the use of
specific LCAFs in specific deployments.  Nonetheless, there's always a
chance than an unknown Type is received.  I looked at rfc8060 but
found no indication there.  Did I miss it?


I assume that the message containing an unknown Type MUST be dropped.
Or should it just be the specific TLV?

In either case, if that is not specified then we could use
draft-ietf-lisp-vendor-lcaf to specify that behavior -- and formally
update rfc8060.

??

Thanks!

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] Virtual meeting

[Prakash Jain (prakjain)]

Hi Joel,
Sorry, missed this earlier. I have earlier asked a slot in Vancouver to present 
lisp-site-external-connectivity draft 
(https://tools.ietf.org/html/draft-jain-lisp-site-external-connectivity-00).

If slots are still available in virtual session, we would like to have 10 min 
slot to discuss this.

Thanks,
Prakash

On 3/10/20, 2:44 PM, "lisp on behalf of Joel M. Halpern" 
 wrote:

Vancouver has been cancelled.
We have several ways we can hold a virtual interim.  (The chairs have a 
webex available, and Fabio has offered one.)

I understand that folks want to present their work.
But what I am looking for if we are going to get folks together is 
actual engagement on the list.  Indication that there are things worth 
discussing.

Yours,
Joel

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


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

[lisp] Clarification on draft-ietf-lisp-rfc6833bis

[Prakash Jain (prakjain)]

Hi Authors,


Came across following in (draft-ietf-lisp-rfc6833bis-24) ,

Page 14, under EID Prefix:

"When a Map-Request is sent by an ITR because a data
  packet is received for a destination where there is no mapping
  entry, the EID-Prefix is set to the destination IP address of the
  data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4
  or IPv6, respectively.  When an xTR wants to query a site about
  the status of a mapping it already has cached, the EID-Prefix used
  in the Map-Request has the same mask-length as the EID-Prefix
  returned from the site when it sent a Map-Reply message."

Page 15, under  EID-to-RLOC UDP Map-Request Message:


"A Map-Request is sent from an ITR when it needs a mapping for an EID,

   wants to test an RLOC for reachability, or wants to refresh a mapping

   before TTL expiration.  For the initial case, the destination IP

   address used for the Map-Request is the data packet's destination

   address (i.e., the destination EID) that had a mapping cache lookup

   failure.  For the latter two cases, the destination IP address used

   for the Map-Request is one of the RLOC addresses from the Locator-Set

   of the Map-Cache entry.  The source address is either an IPv4 or IPv6

   RLOC address, depending on whether the Map-Request is using an IPv4

   or IPv6 header, respectively."

Isn't second case above referring to map-cache refresh for EID Prefix and 
"Destination IP address" as EID Prefix (instead of RLOC)?

Typo or I am missing something?

Thanks,
Prakash


[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/logo/Cisco_Logo_no_TM_Medium_Gray-RGB_43px.png]
Prakash Jain
TECHNICAL LEADER.ENGINEERING
prakj...@cisco.com
Tel: +1 408 525 1273




Cisco Systems, Inc.
821 Alder Drive
MILPITAS
95035
United States
cisco.com
[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.


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

Re: [lisp] New name for upcoming LISP -OAM- document

[Prakash Jain (prakjain)]

Agree, OAM has much bigger scope than traceroute, so naming it with 'traceroute 
considerations' makes more sense.
Thanks,
Prakash

-Original Message-
From: lisp  On Behalf Of Fabio Maino (fmaino)
Sent: Wednesday, March 21, 2018 9:06 AM
To: lisp@ietf.org
Subject: Re: [lisp] New name for upcoming LISP -OAM- document

I suggest "Considerations on LISP Mobility, Deployment and Traceroute" 
that puts a little less emphasis on mobility.

I second Luigi's call to get done with this document and move on.


Thanks,
Fabio

On 3/19/18 4:25 PM, Luigi Iannone wrote:
> Hi All,
>
> during today f2f meeting concern has been expressed about the name to use for 
> the document that will collect what is neither data-plane nor control-plane.
>
> The name OAM was found not accurate because the document will not cover all 
> of what is normally in a OAM document.
>
> The suggested name is “LISP Mobility, Deployment and Traceroute 
> considerations”.
>
> The chairs would like to hear from the mailing list if there is any objection 
> or you have a better name to suggest.
>
> Please send an email by the end of the week.
>
> Thanks
>
> Jole and 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
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp