[lisp] Re: Call for WG Adoption for LISP Multicast Overlay Group to Underlay RLOC Mappings (draft-vdas-lisp-group-mapping-03)

[Luigi Iannone]

Just approved the submission.

Ciao

L.

> On 18 Sep 2024, at 18:02, Dino Farinacci  wrote:
> 
>> The authors are invited to submit a new revsion named 
>> draft-ietf-lisp-group-mapping-00 at their earliest convinience.
> 
> Done, submitted.
> 
> Dino
> 

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

[lisp] Re: Call for WG Adoption for LISP Multicast Overlay Group to Underlay RLOC Mappings (draft-vdas-lisp-group-mapping-03)

[Luigi Iannone]

Hi All,

this call is now closed.

Several emails have been received in support of this document, clearly showing 
interest and consensus for WG adoption.

The authors are invited to submit a new revsion named 
draft-ietf-lisp-group-mapping-00 at their earliest convinience.

Ciao

Luigi & Padma 

> On 2 Sep 2024, at 13:31, Luigi Iannone  wrote:
> 
> All,
> 
> the document LISP Multicast Overlay Group to Underlay RLOC Mappings 
> (https://datatracker.ietf.org/doc/draft-vdas-lisp-group-mapping/)
> 
> was presented 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/support.
> 
> 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] Call for WG Adoption for LISP Multicast Overlay Group to Underlay RLOC Mappings (draft-vdas-lisp-group-mapping-03)

[Luigi Iannone]

All,

the document LISP Multicast Overlay Group to Underlay RLOC Mappings 
(https://datatracker.ietf.org/doc/draft-vdas-lisp-group-mapping/)

was presented 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/support.

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: Call for adoption for documents 6831bis and 8378bis

[Luigi Iannone]

Hi all,

thi call is now over. 
We received several emails in support of adoption of these documents, clearly 
showing consensus.

As such the documents are adopted and the authors are invited to submit new 
revisions with the conventional naming draft-ietf-lisp-….

Ciao

L. 

> On 1 Aug 2024, at 14:03, Luigi Iannone  wrote:
> 
> 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] Call for adoption for documents 6831bis and 8378bis

[Luigi Iannone]

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] LISP WG Minutes

[Luigi Iannone]

Hi All,

a first draft of the minutes of our last meeting are now available: 
https://datatracker.ietf.org/doc/minutes-120-lisp-202407240030/

Please review and if you have any comment send an email to: 
lisp-cha...@ietf.org 

Ciao

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

[lisp] Slides for tomorrow's meeting

[Luigi Iannone]

Hi,

For the presenters at tomorrow’s meeting, please submit your slides by this 
evening so that we have time to upload them on the material page.

Ciao

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

[lisp] BOF on Network Attestation for Secure Routing

[Luigi Iannone]

Hi All,

The BOF in object may be of some interest for people in this mailing list.

Network Attestation for Secure Routing
Thursday July 25 9:30 

Main topic:

The goal of Network Attestation for Secure Routing WG is to address the 
challenges
 associated with routing data on top of trusted devices, trusted operating 
environments, 
trusted links and trusted services only, so as to achieve transparent and 
predictable f
orwarding behavior. Verifiable operational correctness proofs should also be 
given to 
serve as a trusted evidence for visualization, internal inspection and external 
auditing.

Agenda: https://datatracker.ietf.org/meeting/120/materials/agenda-120-nasr-08

Ciao

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

[lisp] Re: LISP Preliminary agenda available

[Luigi Iannone]

Hi Dino,

Yes, both are multicast, but the first slot is about bis documents which is a 
specific milestone in the charter, while the second is about an individual 
submission (at this stage).

You can still handle the 25 minutes as you like, you do not need to respect the 
10/15 split..

Ciao

L.

> On 11 Jul 2024, at 15:58, Dino Farinacci  wrote:
> 
> Luigi my two agenda items don’t have to be two slots. Both are multicast 
> related so will present together. 
> 
> Thanks,
> Dino
> 
>> On Jul 11, 2024, at 2:46 AM, Luigi Iannone  wrote:
>> 
>> Hi All,
>> 
>> the preliminary agenda for the LISP WG meeting is avialble at: 
>> https://datatracker.ietf.org/doc/agenda-120-lisp/
>> 
>> Please let us know if you see any mistake or have suggestions/feedback.
>> 
>> Ciao
>> 
>> L. 
>> ___
>> lisp mailing list -- lisp@ietf.org
>> To unsubscribe send an email to lisp-le...@ietf.org

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

[lisp] LISP Preliminary agenda available

[Luigi Iannone]

Hi All,

the preliminary agenda for the LISP WG meeting is avialble at: 
https://datatracker.ietf.org/doc/agenda-120-lisp/

Please let us know if you see any mistake or have suggestions/feedback.

Ciao

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

[lisp] Re: Rtgdir early review of draft-ietf-lisp-geo-06

[Luigi Iannone]

Hi Ines,

Do you consider that the document is now ready for publication from the RTGDir  
perspective?

Thanks

Ciao

L.

> On 4 Jul 2024, at 07:35, Ines Robles  wrote:
> 
> Ok, Thank you Dino for the clarification,
> 
> BR, 
> Ines
> 
> On Thu, Jul 4, 2024 at 1:39 AM Dino Farinacci  > wrote:
>> Ines, thanks for your comments. Here is one response to your commentary.
>> 
>> > > 9- In the security considerations, what about add description on attacks
>> > > related to geo-coordinates such as location spoofing?
>> > 
>> > We had added that from previous reviews. Tell us exactly what you are 
>> > looking for.
>> > 
>> > Ok, thanks. I was wondering about potential consequences of location 
>> > spoofing within the LISP environment, such as misleading network path 
>> > selection. What do you think? 
>> 
>> I think we have covered this and there is no way to validate a "good 
>> geo-coordinate". If you authenticate the source who registered the mapping, 
>> you are trusting them. There is no way to do a back-door check to see if the 
>> location is correct or precise. 
>> 
>> We don't want the draft to spec out to validate something this:
>> 
>> EID: London, UK
>> RLOC: geo lat: 37, geo long: -121
>> 
>> Meaning, you don't want to say, "hey those coordinates are in San Jose, CA 
>> but you used a name called London, this is suspect, we probably shouldn't 
>> register this".
>> 
>> This sort of validation should be done in the implementation at the source 
>> (and not the LISP implementation) but the admins who decide London needs to 
>> be San Jose. ;-)
>> 
>> Dino
>> 
>> 
>> 

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

[lisp] Re: Request LISP-Decent

[Luigi Iannone]

Hi Dino,

Jim, Padma and myself discussed about your request concerning lisp-decent.

It is our opinion that since the current charter does not support the work  and 
because less than a year ago the WG did not show interest in the work [1]
it is more appropriate if this document is submitted to the ISE stream.

Thanks

Ciao

L.

[1] https://mailarchive.ietf.org/arch/msg/lisp/h36AtLQY_7zsz9Ytw-gafFaonU8/
  


> On 18 Jun 2024, at 00:10, Dino Farinacci  wrote:
> 
> Since multiple LISP mapping systems *was* in the charter, I would like to 
> request this document to be a working group document:
> 

> 
> This mapping system scales really well and is easier to configure and 
> requires less multi-organizational coordination than LISP-DDT. I have 
> implemented it and test scaled it to 1M mapping entries across a 10 
> map-server cluster size.
> 
> Are there any objections to making this a working group document?
> 
> Dino___
> lisp mailing list -- lisp@ietf.org
> To unsubscribe send an email to lisp-le...@ietf.org

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

[lisp] Re: Request for working group documents

[Luigi Iannone]

Noted.

Thanks

L.

> On 24 Jun 2024, at 21:05, Dino Farinacci  wrote:
> 
> I would need 10 minutes for the bis documents. And 15 minutes for the 
> group-mapping document. 
> 
> Dino
> 
>> On Jun 24, 2024, at 4:51 AM, Luigi Iannone  wrote:
>> 
>> Hi Dino,
>> 
>> Padma and myself did talk about this set of documents.
>> 
>> The best way forawrd is to present the documents to the WG so that they can 
>> be disucssed.
>> We can do this in Vancouver.
>> 
>> One slot to present the two bis documents. Highlight qny major change and 
>> deployment experience.
>> 
>> Another slot to present the third document. The usuql overview with the 
>> addition of how it completes the bis documens.
>> 
>> How mush time do you think would you need?
>> 
>> Ciao
>> 
>> L. 
>> 
>> 
>>> On 18 Jun 2024, at 00:03, Dino Farinacci  wrote:
>>> 
>>> Since the LISP multicast documents are in the charter for standardization, 
>>> we have started to create bis level drafts here:
>>> 
>>> 
>>> 
>>> And to complete the set, this individual contribution compliments the above 
>>> and is essential for underlay interoperation:
>>> 
>>> 
>>> 
>>> The set was published the beginning of May and the authors would like to 
>>> request they go to working group documents. In fact, we would like to 
>>> request last call when they become WG drafts.
>>> 
>>> Are there any objections to this?
>>> 
>>> Thanks,
>>> Dino___
>>> lisp mailing list -- lisp@ietf.org
>>> To unsubscribe send an email to lisp-le...@ietf.org
>> 
> 

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

[lisp] Re: Request for working group documents

[Luigi Iannone]

Hi Dino,

Padma and myself did talk about this set of documents.

The best way forawrd is to present the documents to the WG so that they can be 
disucssed.
We can do this in Vancouver.

One slot to present the two bis documents. Highlight qny major change and 
deployment experience.

Another slot to present the third document. The usuql overview with the 
addition of how it completes the bis documens.

How mush time do you think would you need?

Ciao

L. 
 

> On 18 Jun 2024, at 00:03, Dino Farinacci  wrote:
> 
> Since the LISP multicast documents are in the charter for standardization, we 
> have started to create bis level drafts here:
> 
> 
> 
> And to complete the set, this individual contribution compliments the above 
> and is essential for underlay interoperation:
> 
> 
> 
> The set was published the beginning of May and the authors would like to 
> request they go to working group documents. In fact, we would like to request 
> last call when they become WG drafts.
> 
> Are there any objections to this?
> 
> Thanks,
> Dino___
> lisp mailing list -- lisp@ietf.org
> To unsubscribe send an email to lisp-le...@ietf.org

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

[lisp] Re: Rtgdir early review of draft-ietf-lisp-geo-06

[Luigi Iannone]

Hi Ines,

Did you get the opportunity to check the latest revision of the lisp-geo 
document? Do you consider your concerns addressed?

Thanks

Ciao

L.


> On 7 Jun 2024, at 01:53, Dino Farinacci  wrote:
> 
>> Reviewer: Ines Robles
>> Review result: Not Ready
>> 
>> Reviewer: Ines Robles
>> Date: 01-06-2024
>> Version reviewed:draft-ietf-lisp-geo-06
> 
> Thanks for your comments. I have posted -07. See my responses to your 
> comments below.
> 
>> Suggestions/Issues:
>> 
>> It would be nice to add information about:
>> 
>> 1- The document mentions compatibility with OSPF, IS-IS, and BGP. It is
>> suggested to provide examples of how LISP with geo-coordinates interoperates
>> with these protocols.
> 
> LISP does not interoperate directly with these protocols. The text indicates 
> the geo-coordinate packet format is the same to adhere to a more holistic 
> consistency.
> 
>> 2- The draft doesn't mention which LISP messages the geo-coordinates encoding
>> should be used in. It is suggested to add explicitly in which LISP messages
>> (such as Map-Register?) the geo-coordinates encoding should be used, to 
>> provide
>> clearer guidance for implementers and newcomers.
> 
> They are the messages that contain EID-records and RLOC-records. I put in a 
> reference to rfc9301.
> 
>> 3- How the geo-coordinates encoding will interoperate with existing LISP
>> deployments, including any backward compatibility issues.
> 
> Added a new section.
> 
>> 4- How to handle errors such as invalid geo-coordinate data or missing 
>> fields.
> 
> Fixed in the section 5.
> 
>> 5- The performance impact of including geo-coordinates in LISP messages, such
>> as increased message size and processing overhead.
> 
> Did not add this. There is no impact.
> 
>> 6-  Are the geo-coordinates incorporated in control plane operations?
> 
> Yes. RFC9301 and RFC8060 references make this clear.
> 
>> 7- Perhaps to include some Manageability Considerations?
> 
> For what? All the management of this new type or any type is in RFC9301.
> 
>> 8- How geo-coordinates can aid in selecting alternate paths and improving
>> network resilience. how geo-coordinates could help manage dynamic and mobile
>> topologies.
> 
> We have already provided the use-cases we intend to support. There is no 
> plans to add new features.
> 
>> 9- In the security considerations, what about add description on attacks
>> related to geo-coordinates such as location spoofing?
> 
> We had added that from previous reviews. Tell us exactly what you are looking 
> for.
> 
>> Nits:
>> 
>> 10 - Abstract: "Geo-Coordinates can used in..." -> "Geo-Coordinates can be 
>> used
>> in ..." 11 - Introduction: "...introduces two..." -> "...introduce two..." 
>> 12 -
>> Section 4.2: "... in any on the inner ..." -> "... in any of the inner ..." 
>> 13
>> - Sometimes "Geo-Coordinates" is used and sometimes "geo-coordinates".
>> Suggestion to use one format. 14 - Suggestion to expand on First use the
>> acronyms: LISP, LCAF, ETR and RTR. 15 - Add a caption for the LCAF encoding
>> figure and an introductory sentence to introduce the figure. 16- In the LCAF
>> encoding figure, two AFI fields are depicted. Add a description for each one.
>> For example, "The AFI field is set to 16387 to indicate that the address is
>> using the LCAF format." And for the other AFI, "The AFI field indicates the
>> Address Family Identifier for the following address...?" Also, add an
>> explanation for the Address field.
> 
> Made all these changes. It was alraedy commented to not redefine the terms so 
> hence not expanded.
> 
>> Thanks for this document,
> 
> Thanks again for the review,
> Dino
> 
> 
> 

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

[lisp] Fwd: Nomcom 2024-2025 Third Call For Volunteers

[Luigi Iannone]

FYI

> Begin forwarded message:
> 
> From: NomCom Chair 2024 
> Subject: Nomcom 2024-2025 Third Call For Volunteers
> Date: 6 June 2024 at 19:55:22 GMT+2
> To: "IETF Announcement List" 
> Cc: i...@ietf.org
> Reply-To: nomcom-chair-2...@ietf.org
> 
> The IETF tools development team identified an error in the interface between 
> the IETF registration system and the datatracker that mistakenly marked 
> people as volunteers for the 2024 NomCom. (Please note that volunteering via 
> the registration system is not offered for IETF 120 registration.)
> 
> This error was corrected, and the fix was deployed on June 4. The correction 
> for the bug can be viewed at 
> https://github.com/ietf-tools/datatracker/pull/7484.
> 
> We have removed the incorrect volunteer records as of June 5. However, this 
> has led to a severely reduced number of eligible volunteers (below 90). 
> Please review your status and consider volunteering for NomCom 2024-2025. 
> Please check your status at https://datatracker.ietf.org/accounts/profile/ 
> after signing in under the "NomCom Eligible" section,. If you have already 
> explicitly volunteered using the datatracker, you will see "You have 
> volunteered for the Nominating Committee 2024/2025.” If you are not yet 
> volunteered, you will see a Volunteer button.
> 
> You can also volunteer via
> CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer
> 
> or directly emailing me at nomcom-chair-2...@ietf.org
> 
> Thanks to everyone who has volunteered so far. However, we currently have 
> only eligible 90 volunteers. We need many more. So, please, please volunteer.
> 
> Dean Bogdanovic
> nomcom-chair-2...@ietf.org
> 
> ___
> IETF-Announce mailing list -- ietf-annou...@ietf.org
> To unsubscribe send an email to ietf-announce-le...@ietf.org

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

[lisp] Re: Review draft-ietf-lisp-te

[Luigi Iannone]

> On 27 May 2024, at 16:49, Dino Farinacci  wrote:
> 
> I don’t see the need to fix it. And the working group doesn’t seem to care. 
> If you can’t give me a compelling reason to fix it, I’m not going to. 
> 
> You clearly don’t understand what a network path is. It includes nodes AND 
> links. 
> 
> Dino

Dino,

Private emails, with insulting content, will not help progress the document.

Since apparently we are not able to converge, my co-chair Padma accepted to 
handle this document from now on.

Please wait her review of the draft.



As a participant of the LISP WG, and with no hats on, my concerns remain 
unaddressed (despite proposing very detailed and easy fixes). 

Second example in  section 4 remains unclear and misleading. See: 
https://mailarchive.ietf.org/arch/msg/lisp/CzJjLCgCZquCPOkhv56-q3DZTRE/

The general organisation of the document can be improved.
As of now it is a bunch of use cases where for each one we see the same 
structure:

Here is a cool thing you can do using LISP ELPs….  
In order to do it you MUST do this or SHOULD do that….. 

In other words the specifications that need to be implemented are scattered all 
over the document. The risk is that people interested in one single use case 
will implement only part of the specs.

My suggestion is to move a few paragraph in one single place so to have the 
document organized in two main parts: A section with all the specifications; A 
section with all the use cases.
My first review included detailed suggestions of the few simple cut & paste to 
be done: https://mailarchive.ietf.org/arch/msg/lisp/3zIUevHl8ZbqfKgwjXhJ8Z-FUlA/

Ciao

L.



 

> 
>> On May 27, 2024, at 8:19 AM, Luigi Iannone  wrote:
>> 
>> Hi Dino,
>> 
>> I do not see a reply to my last email.
>> Can you fix the figure of the example so that we can move forward?
>> 
>> The concerned part is:
>> 
>>>> 
>>>>> This is exactly the point. I do not see an alternate path. I see only an 
>>>>> alternate tunnel.
>>>>> The current text is still confusing. You want "to route around the path 
>>>>> from B to C” and to do it you route "through link B—>C”. This looks like 
>>>>> a contradiction to me.
>>>> 
>>>> B and C have other links. Don’t you see the link between B and X. That is 
>>>> “another” path. 
>>> 
>>> But the figure has no “other path” in it. I added one in my first review 
>>> but you did not like it.
>>> 
>>> The text:
>>> 
>>> if it is desirable to route around the path from B to C through link B-->C, 
>>> 
>>> Still look like a contradiction. Furthermore, in figure 1 you were already 
>>> routing through link B—>C, so it looks like you “route around” through the 
>>> very same link…..
>>> 
>>> 
>> 
>> 
>> 
>> For clarity, according to the convention you are using the figure 2 show a 
>> tunnel between X and Y but not a path. I put back my very first email with 
>> the suggested correct figure.
>> 
>>Source site   ()Destination Site
>>++() +-+
>>| \   ()/  |
>>| seid ITR ---(-> A -> B > C -> D -)---> ETR  deid |
>>| / ||(|   ^   ) ^^ \  |
>>|/  ||(|   |   ) ||  \ |
>>+---+   ||(v   |   ) ||   ++
>>||(    X > Y   ) ||
>>||(  ^^ ||   ^^ || ) || <>
>>||(--||-||---||-||-) ||
>> ||   || ||   || ||
>>||   || ||===|| ||   ||
>> ===LISP===
>>  LISP Tunnel  TunnelLISP Tunnel
>> 
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> On 13 May 2024, at 13:58, Luigi Iannone  wrote:
>>> 
>>> 
>>> 
>>>> On 7 May 2024, at 16:36, Dino Farinacci  wrote:
>>>> 
>>>> 
>>>>> The text still assumes that an ELP must be returned.
>>>> 
>>>> That is correct.
>>>> 
>>>>> 
>>>>> Just replace the words:
>>>>> 
>>>>>   “which returns a ELP-based locator record for a path to RTR 'y', and 
>>>>

[lisp] Re: Review draft-ietf-lisp-te

[Luigi Iannone]

Hi Dino,

I do not see a reply to my last email.
Can you fix the figure of the example so that we can move forward?

The concerned part is:

>> 
>>> This is exactly the point. I do not see an alternate path. I see only an 
>>> alternate tunnel.
>>> The current text is still confusing. You want "to route around the path 
>>> from B to C” and to do it you route "through link B—>C”. This looks like a 
>>> contradiction to me.
>> 
>> B and C have other links. Don’t you see the link between B and X. That is 
>> “another” path. 
> 
> But the figure has no “other path” in it. I added one in my first review but 
> you did not like it.
> 
> The text:
> 
> if it is desirable to route around the path from B to C through link B-->C, 
> 
> Still look like a contradiction. Furthermore, in figure 1 you were already 
> routing through link B—>C, so it looks like you “route around” through the 
> very same link…..
> 
> 



For clarity, according to the convention you are using the figure 2 show a 
tunnel between X and Y but not a path. I put back my very first email with the 
suggested correct figure.

   Source site   ()Destination Site
   ++() +-+
   | \   ()/  |
   | seid ITR ---(-> A -> B > C -> D -)---> ETR  deid |
   | / ||(|   ^   ) ^^ \  |
   |/  ||(|   |   ) ||  \ |
   +---+   ||(v   |   ) ||   ++
   ||(X > Y   ) ||
   ||(  ^^ ||   ^^ || ) || <>
   ||(--||-||---||-||-) ||
   ||   || ||   || ||
   ||   || ||===|| ||   ||
   ===LISP===
 LISP Tunnel  TunnelLISP Tunnel


Ciao

L.


> On 13 May 2024, at 13:58, Luigi Iannone  wrote:
> 
> 
> 
>> On 7 May 2024, at 16:36, Dino Farinacci  wrote:
>> 
>> 
>>> The text still assumes that an ELP must be returned.
>> 
>> That is correct.
>> 
>>> 
>>> Just replace the words:
>>> 
>>>   “which returns a ELP-based locator record for a path to RTR 'y', and 
>>> encapsulates packets…"
>> 
>> The example is illustrating nesting so I believe it is not needed.
> 
> I understand the example, but the text is a bit misleading because seems to 
> suggest that lookup _must_ return an ELP. 
> Anyway, in the last revision is already better.  
> 
> 
>> 
>>>>>> Luigi, the terms are used in self contained sections. They are fine. 
>>>>>> S-EID is ONLY used in the multicast section because the is the 
>>>>>> convention we use to look up a multicast mapping (S-EID, G-EID).
>>> 
>>> I think a unique term makes more sense, but this is not a blocking point.
>> 
>> It is a unique term. The term S-EID is used in all the multicast drafts to 
>> describe an (S,G).
> 
> Fine.
> 
>> 
>>> This is exactly the point. I do not see an alternate path. I see only an 
>>> alternate tunnel.
>>> The current text is still confusing. You want "to route around the path 
>>> from B to C” and to do it you route "through link B—>C”. This looks like a 
>>> contradiction to me.
>> 
>> B and C have other links. Don’t you see the link between B and X. That is 
>> “another” path.
> 
> But the figure has no “other path” in it. I added one in my first review but 
> you did not like it.
> 
> The text:
> 
> if it is desirable to route around the path from B to C through link B-->C, 
> 
> Still look like a contradiction. Furthermore, in figure 1 you were already 
> routing through link B—>C, so it looks like you “route around” through the 
> very same link…..
> 
> 
> 
>> 
>>> The sentence remains superfluous. Of course you can do it with ODL, but 
>>> this is out of the scope of the IETF and I do not see why it should be 
>>> there.
>>> The other LISP documents never mention a provision system, so why this one 
>>> has to mention it? Is there a compelling reason?
>> 
>> Because in other cases ETRs register their own RLOCs because they know them. 
>> With an ELP, a provisioning system knows the topology and can register all 
>> the addresses in the ELP.  It has a broader view

[lisp] Fwd: Nomcom 2024-2025 Second Call For Volunteers

[Luigi Iannone]

> Begin forwarded message:
> 
> From: NomCom Chair 2024 
> Subject: Nomcom 2024-2025 Second Call For Volunteers
> Date: 20 May 2024 at 14:43:50 GMT+2
> To: "IETF Announcement List" 
> Cc: i...@ietf.org
> Reply-To: nomcom-chair-2...@ietf.org
> 
> This is the second call for volunteers for the 2024/25 NomCom. 
> 
> Thank you all that volunteered so far, but we could use some more volunteers.
> 
> To simplify, here is the link to volunteer:
> 
> https://datatracker.ietf.org/nomcom/volunteer
> 
> and quick reminder what to expect as NomCom member
> NomCom activity is expected to start in July 2024 and run through to November 
> 2024. The goal is to do the bulk of the work at IETF 120 and 121, with 
> supplemental conference calls between those times. Remote participation will 
> be supported.
> 
> ___
> IETF-Announce mailing list -- ietf-annou...@ietf.org
> To unsubscribe send an email to ietf-announce-le...@ietf.org

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

[lisp] Publication has been requested for draft-ietf-lisp-name-encoding-07

[Luigi Iannone via Datatracker]

Luigi Iannone has requested publication of draft-ietf-lisp-name-encoding-07 as 
Proposed Standard on behalf of the LISP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/


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

[lisp] Re: Review draft-ietf-lisp-te

[Luigi Iannone]

> On 7 May 2024, at 16:36, Dino Farinacci  wrote:
> 
> 
>> The text still assumes that an ELP must be returned.
> 
> That is correct.
> 
>> 
>> Just replace the words:
>> 
>>   “which returns a ELP-based locator record for a path to RTR 'y', and 
>> encapsulates packets…"
> 
> The example is illustrating nesting so I believe it is not needed.

I understand the example, but the text is a bit misleading because seems to 
suggest that lookup _must_ return an ELP. 
Anyway, in the last revision is already better.  


> 
> Luigi, the terms are used in self contained sections. They are fine. 
> S-EID is ONLY used in the multicast section because the is the convention 
> we use to look up a multicast mapping (S-EID, G-EID).
>> 
>> I think a unique term makes more sense, but this is not a blocking point.
> 
> It is a unique term. The term S-EID is used in all the multicast drafts to 
> describe an (S,G).

Fine.

> 
>> This is exactly the point. I do not see an alternate path. I see only an 
>> alternate tunnel.
>> The current text is still confusing. You want "to route around the path from 
>> B to C” and to do it you route "through link B—>C”. This looks like a 
>> contradiction to me.
> 
> B and C have other links. Don’t you see the link between B and X. That is 
> “another” path.

But the figure has no “other path” in it. I added one in my first review but 
you did not like it.

The text:

if it is desirable to route around the path from B to C through link B-->C, 

Still look like a contradiction. Furthermore, in figure 1 you were already 
routing through link B—>C, so it looks like you “route around” through the very 
same link…..



> 
>> The sentence remains superfluous. Of course you can do it with ODL, but this 
>> is out of the scope of the IETF and I do not see why it should be there.
>> The other LISP documents never mention a provision system, so why this one 
>> has to mention it? Is there a compelling reason?
> 
> Because in other cases ETRs register their own RLOCs because they know them. 
> With an ELP, a provisioning system knows the topology and can register all 
> the addresses in the ELP.  It has a broader view. 
> 
> There are deployments that take an ISIS topology, compute paths offline as an 
> SDN controller, and can build an ELP path based on policy rules (where 
> re-encapsulation points can be placed in the network). 
> 

The sentence is still superfluous. The fact that some LISP deployments use some 
SDN approach has no place in the document. This is a technical document for 
implementation of a feature, not a LISP advertisement.
You can leave the sentence there if you really wish, but remains superfluous.


Fix the example and we tackle the text.

Ciao

L.


> Dino

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

[lisp] Re: Review draft-ietf-lisp-te

[Luigi Iannone]

Hi Dino,

Thanks for the update.
My comments inline.

> On 6 May 2024, at 19:54, Dino Farinacci  wrote:
> 
> Copying the WG. I have submitted -16 to make things more clear to reflect 
> your comments. Here is the diff.
> 
> Dino
>> On May 6, 2024, at 5:26 AM, Luigi Iannone  wrote:
>> 
>> Dino,
>> 
>> The document is WG document and the WG has a say. 
>> Please post your reply to the mailing list. I will reply there.
>> 
>> At least we make the WG aware of how we work to move the document forward. 
>> ;-)
>> 
>> Ciao
>> 
>> L.
>> 
>>> On 4 May 2024, at 01:32, Dino Farinacci  wrote:
>>> 
>>> Going private.
>>> 
>>>> On May 3, 2024, at 4:41 AM, Luigi Iannone  wrote:
>>>> 
>>>> Dino,
>>>> 
>>>> Let’s go step by step.
>>>> 
>>>> Let’s postpone the text relocation and focus first on the other concerns I 
>>>> have.
>>> 
>>> Good.
>>> 
>>>> On 2 May 2024, at 22:29, Dino Farinacci  wrote:
>>>>> 
>>>>> Luigi, see the diff file for most of your comments. I still cannot follow 
>>>>> your move suggestions. Just moving text around away from where they are, 
>>>>> are going to lose points I intended. You need to be crystal clear what 
>>>>> text needs to move where and be precise why you think so. I feel the text 
>>>>> doesn't need moving. So if you think it does you need to make compelling 
>>>>> reasons without destroying the flow and meaning I have intended.
>>>>> 
>>>>> I made all the changes you requested in this diff file. I have comments 
>>>>> for what I didn't change (I didn't comment on the move text since I did 
>>>>> above).
>>>>> 
>>>>>> Dino, you correct text mixes specifications and use cases. By 
>>>>>> concentrating the specifications in one section (namely section 5) you 
>>>>>> will improve readability and clarity of the document.
>>>>> 
>>>>> No it doesn't. You are using the term use-cases in a high level sense. We 
>>>>> are discuss functionality and why the ELP is needed.
>>>> 
>>>> No Dino. You are mixing examples and procedures, hence my suggestion to 
>>>> move around some text. But we will deal with this later.  
>>> 
>>> I am presenting the material as I see fit to make it understandable.

Let’s deal with this later.

>>> 
>>>> 
>>>>>> What really request is a mapping, which may or may not be an ELP.
>>>>>> What happens if it receives a negative map-reply?
>>>>> 
>>>>> It follows the procedures of RFC9301. And we don't need to state this 
>>>>> everywhere. We are assuming the reader knows how LISP works at a high 
>>>>> level.
>>>> 
>>>> So your text is wrong because it states "requests the ELP for RTR ‘y’”. 
>>>> You request a mapping and act upon what you receive, you do not request an 
>>>> ELP for ‘y’.
>>> 
>>> I will fix this to be more clear.

The text still assumes that an ELP must be returned.

Just replace the words: 

“which returns a ELP-based locator record for a path to RTR 'y', and 
encapsulates packets…"

With

“assuming it returns an ELP-based locator record for a path to RTR 'y', 
it encapsulates packets…"


>>> 
>>>> 
>>>>>> You mean that this second lookup can be done on a mapping system that is 
>>>>>> different from the one who delivered the initial ELP, right?
>>>>>> If yes, can you state so?
>>>>> 
>>>>> It means the ELP entry is an EID, so to get the RLOC for that EID, you do 
>>>>> another lookup. It gives another level of indirection within an ELP.
>>>> 
>>>> The sentence I referring to is:  This can be done when using a public or 
>>>> private mapping database.  
>>>> 
>>>> Why are you introducing this distinction between public and private?
>>> 
>>> Because the recursion can be done with a private database. Its a useful 
>>> feature.

The new text clarifies the use case. Thanks. 

>>> 
>>>> 
>>>>> 
>>>>>> The document uses a mix of “seid” and “S-EID”, choose one.
>>>>> 
>>>>> 
>>>>> On purpose. The seid a

Re: [lisp] Review draft-ietf-lisp-te

[Luigi Iannone]

Dino,

Let’s go step by step.

Let’s postpone the text relocation and focus first on the other concerns I have.


> On 2 May 2024, at 22:29, Dino Farinacci  wrote:
> 
> Luigi, see the diff file for most of your comments. I still cannot follow 
> your move suggestions. Just moving text around away from where they are, are 
> going to lose points I intended. You need to be crystal clear what text needs 
> to move where and be precise why you think so. I feel the text doesn't need 
> moving. So if you think it does you need to make compelling reasons without 
> destroying the flow and meaning I have intended.
> 
> I made all the changes you requested in this diff file. I have comments for 
> what I didn't change (I didn't comment on the move text since I did above).
> 
>> Dino, you correct text mixes specifications and use cases. By concentrating 
>> the specifications in one section (namely section 5) you will improve 
>> readability and clarity of the document.
> 
> No it doesn't. You are using the term use-cases in a high level sense. We are 
> discuss functionality and why the ELP is needed.

No Dino. You are mixing examples and procedures, hence my suggestion to move 
around some text. But we will deal with this later.  

> 
>> What really request is a mapping, which may or may not be an ELP.
>> What happens if it receives a negative map-reply?
> 
> It follows the procedures of RFC9301. And we don't need to state this 
> everywhere. We are assuming the reader knows how LISP works at a high level.

So your text is wrong because it states "requests the ELP for RTR ‘y’”. You 
request a mapping and act upon what you receive, you do not request an ELP for 
‘y’. 


> 
>> You mean that this second lookup can be done on a mapping system that is 
>> different from the one who delivered the initial ELP, right?
>> If yes, can you state so?
> 
> It means the ELP entry is an EID, so to get the RLOC for that EID, you do 
> another lookup. It gives another level of indirection within an ELP.

The sentence I referring to is:  This can be done when using a public or 
private mapping database.  

Why are you introducing this distinction between public and private? 

> 
>> The document uses a mix of “seid” and “S-EID”, choose one.
> 
> 
> On purpose. The seid and deid are used in the forwarding examples. The 
> (S-EID) is only in the multicast section.

But you do not explain de difference. Either uniform them or explain. As it is 
now is just confusing.

> 
>> How the S-bit, L-bit, and the P-bit are used is not covered at all and 
>> should be described in section 5.
> 
> It is explained in RFC8060. I don't want to repeat.

Agreed.

> 
> So this is the way I want your response. Because this commentary and edits 
> are getting too complex. I want you to respond to this email so we can 
> negotiate the repsonses I provided. And I want another email for the moved 
> text that is written with clarity and precision. Okay?
> 
> Dino
> 
<<< text/html;	x-unix-mode=0644;	name="draft-ietf-lisp-te-15.diff.html": Unrecognized >>>
> 
> 
> 
> 


Comments on the diff:

The example in figure 2, with your latest changes makes even less sense, since 
you are now using an ELP to make the packet go through exatly the same path as 
in figure 1. Looks useless.

The sentence about provisioning system is still obscure. The LISP control plane 
is defined in RFC 9301. You are suggesting to use something else to register 
mappings, which is defined nowhere. So unless you want to define such a 
provisioning system please delete the sentence.


Once we converge on these issues we will discuss about moving text around.

CIao

L.




> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

It was clearly showed in my first review.

I sent you the xml with the modified text.

Ciao

L.


> On 2 May 2024, at 18:25, Dino Farinacci  wrote:
> 
> Please provide text and tell me where you prefer the paragraph starting with 
> "This document proposes …" to go.
> 
> Dino
> 
>> On May 2, 2024, at 6:07 AM, Luigi Iannone  wrote:
>> 
>> Dino,
>> 
>> You missed the important part, the fact that the document updates 8060 and 
>> deprecates types 5.
>> The current text still say that the format is specified in 8060, which is 
>> not the case anymore.
>> Here is the suggested text again:
>> 
>> This document proposes a new LCAF encoding for geo-coordinates, which is 
>> compatible with the one used in other 
>> routing protocols,  namely OSPF   [I-D.acee-ospf-geo-location], IS-IS 
>> [I-D.shen-isis-geo-coordinates],
>> and BGP [I-D.chen-idr-geo-coordinates]. This document updates [RFC8060]. In 
>> particular, the use of geo-coordinates 
>> encoding defined in Section 4.3 of [RFC8060] and identified by LCAF type 5 
>> is deprecated.
>> 
>> 
>> Two additional points:
>> 
>> 1. The abstract must be updated. You are now proposing a new format. You 
>> also need to state “This document updates RFC 8060”. 
>> 
>> 2. Section 5: Type 17 is suggested, not requested.
>> 
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> On 30 Apr 2024, at 18:31, Dino Farinacci  wrote:
>>> 
>>> I didn't and believe it doesn't need to go at the beginning of the document.
>>> 
>>> Dino
>>> 
>>>> On Apr 30, 2024, at 12:23 PM, Luigi Iannone  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 30 Apr 2024, at 17:41, Dino Farinacci  wrote:
>>>>> 
>>>>> I'll make all your chnages but this one comment:
>>>>> 
>>>>>> On Apr 30, 2024, at 7:58 AM, Luigi Iannone  wrote:
>>>>>> 
>>>>>> routing protocols,  namely OSPF   [I-D.acee-ospf-geo-location], IS-IS 
>>>>>> [I-D.shen-isis-geo-coordinates],
>>>>> 
>>>>> It is not true. Only the GPS encoding is the same. The general encoding 
>>>>> that wraps the GPS encoding is LCAF. You do not want to mislead that OSPF 
>>>>> and ISIS use LCAF.
>>>> 
>>>> Agreed. You can add exactly this details.
>>>> 
>>>> Thanks
>>>> 
>>>> Luigi
>>>> 
>>>>> 
>>>>> Dino
>>>>> 
>>>> 
>>> 
>> 
> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Dino,

You missed the important part, the fact that the document updates 8060 and 
deprecates types 5.
The current text still say that the format is specified in 8060, which is not 
the case anymore.
Here is the suggested text again:

This document proposes a new LCAF encoding for geo-coordinates, which is 
compatible with the one used in other 
routing protocols,  namely OSPF   [I-D.acee-ospf-geo-location], IS-IS 
[I-D.shen-isis-geo-coordinates],
and BGP [I-D.chen-idr-geo-coordinates]. This document updates [RFC8060]. In 
particular, the use of geo-coordinates 
encoding defined in Section 4.3 of [RFC8060] and identified by LCAF type 5 is 
deprecated.


Two additional points:

1. The abstract must be updated. You are now proposing a new format. You also 
need to state “This document updates RFC 8060”. 

2. Section 5: Type 17 is suggested, not requested.


Ciao

L.


> On 30 Apr 2024, at 18:31, Dino Farinacci  wrote:
> 
> I didn't and believe it doesn't need to go at the beginning of the document.
> 
> Dino
> 
>> On Apr 30, 2024, at 12:23 PM, Luigi Iannone  wrote:
>> 
>> 
>> 
>>> On 30 Apr 2024, at 17:41, Dino Farinacci  wrote:
>>> 
>>> I'll make all your chnages but this one comment:
>>> 
>>>> On Apr 30, 2024, at 7:58 AM, Luigi Iannone  wrote:
>>>> 
>>>> routing protocols,  namely OSPF   [I-D.acee-ospf-geo-location], IS-IS 
>>>> [I-D.shen-isis-geo-coordinates],
>>> 
>>> It is not true. Only the GPS encoding is the same. The general encoding 
>>> that wraps the GPS encoding is LCAF. You do not want to mislead that OSPF 
>>> and ISIS use LCAF.
>> 
>> Agreed. You can add exactly this details.
>> 
>> Thanks
>> 
>> Luigi
>> 
>>> 
>>> Dino
>>> 
>> 
> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

> On 30 Apr 2024, at 17:41, Dino Farinacci  wrote:
> 
> I'll make all your chnages but this one comment:
> 
>> On Apr 30, 2024, at 7:58 AM, Luigi Iannone  wrote:
>> 
>> routing protocols,  namely OSPF   [I-D.acee-ospf-geo-location], IS-IS 
>> [I-D.shen-isis-geo-coordinates],
> 
> It is not true. Only the GPS encoding is the same. The general encoding that 
> wraps the GPS encoding is LCAF. You do not want to mislead that OSPF and ISIS 
> use LCAF.

Agreed. You can add exactly this details.

Thanks

Luigi

> 
> Dino
> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

gt; 
> Appendix A.  Acknowledgments
> 
>The author would like to thank the LISP WG for their review and
>acceptance of this draft.
> 
>A special thanks goes to Enke Chen, Acee Lindem, and Naiming Shen for
>collaboarting on a consistent geo-location encoding format with OSPF
>[I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates],
>and BGP [I-D.chen-idr-geo-coordinates] protocols.
> 
> Appendix B.  Document Change Log
> 
>[RFC Editor: Please delete this section on publication as RFC.]
> 
> B.1.  Changes to draft-ietf-lisp-geo-04
> 
>*  Posted April 2024.
> 
>*  Make changes to reflect comments from Luigi which indicate to be
>   more explicit about consitentcy of geo encodings with IGPs.
> 
>*  Update document timer and references.
> 
> B.2.  Changes to draft-ietf-lisp-geo-03
> 
>*  Posted November 2023.
> 
>*  Update document timer and references.
> 
> 
> 
> FarinacciExpires 24 October 2024   [Page 11]
> 
> Internet-DraftLISP Geo-Coordinate Use-Cases   April 2024
> 
> 
> B.3.  Changes to draft-ietf-lisp-geo-02
> 
>*  Posted June 2023.
> 
>*  Update document timer and references.
> 
> B.4.  Changes to draft-ietf-lisp-geo-01
> 
>*  Posted December 2022.
> 
>*  Changes made to reflect comments from Luigi.
> 
> B.5.  Changes to draft-ietf-lisp-geo-00
> 
>*  Posted November 2022.
> 
>*  Renamed draft-farinacci-lisp-geo-15 to make working group draft.
> 
> B.6.  Changes to draft-farinacci-lisp-geo-15
> 
>*  Posted November 2022.
> 
>*  Made change to reflect last call comments.  First sentence of
>   intro and added a Privacy Considerations section.
> 
> B.7.  Changes to draft-farinacci-lisp-geo-14
> 
>*  Posted September 2022.
> 
>*  Update document timer and references.
> 
> B.8.  Changes to draft-farinacci-lisp-geo-13
> 
>*  Posted March 2022.
> 
>*  Update document timer and references.
> 
> B.9.  Changes to draft-farinacci-lisp-geo-12
> 
>*  Posted September 2021.
> 
>*  Update document timer and references.
> 
> B.10.  Changes to draft-farinacci-lisp-geo-11
> 
>*  Posted March 2021.
> 
>*  Update document timer and references.
> 
> 
> 
> FarinacciExpires 24 October 2024   [Page 12]
> 
> Internet-DraftLISP Geo-Coordinate Use-Cases   April 2024
> 
> 
> B.11.  Changes to draft-farinacci-lisp-geo-10
> 
>*  Posted October 2020.
> 
>*  Update document timer and references.
> 
> B.12.  Changes to draft-farinacci-lisp-geo-09
> 
>*  Posted April 2020.
> 
>*  Update document timer and references.
> 
> B.13.  Changes to draft-farinacci-lisp-geo-08
> 
>*  Posted October 2019.
> 
>*  Update document timer and references.
> 
> B.14.  Changes to draft-farinacci-lisp-geo-07
> 
>*  Posted April 2019.
> 
>*  Update document timer and references.
> 
> B.15.  Changes to draft-farinacci-lisp-geo-06
> 
>*  Posted October 2018.
> 
>*  Update document timer and references.
> 
> B.16.  Changes to draft-farinacci-lisp-geo-05
> 
>*  Posted April 2018.
> 
>*  Update document timer and references.
> 
> B.17.  Changes to draft-farinacci-lisp-geo-04
> 
>*  Posted October 2017.
> 
>*  Update document timer and references.
> 
> B.18.  Changes to draft-farinacci-lisp-geo-03
> 
>*  Posted April 2017.
> 
>*  Update document timer.
> 
> 
> 
> 
> FarinacciExpires 24 October 2024   [Page 13]
> 
> Internet-DraftLISP Geo-Coordinate Use-Cases   April 2024
> 
> 
> B.19.  Changes to draft-farinacci-lisp-geo-02
> 
>*  Posted October 2016.
> 
>*  Change format of the Geo-Coordinates LCAF Type to be compatible
>   with equivalent proposals for OSPF, IS-IS, and BGP.
> 
>*  Add to the Security Considerations section to BCP160 compliance.
> 
> B.20.  Changes to draft-farinacci-lisp-geo-01
> 
>*  Posted October 2016.
> 
>*  Clarify that the Geo-Coordinates LCAF type should be encoded
>   inside an Instance-ID LCAF type when VPNs are used.
> 
>*  Indicate what the value of the Altitude field is when not included
>   in a message.  Since this draft shortens the field, a new value is
>   specified in this draft for not conveying an Altitude value in a
>   message.
> 
> B.21.  Changes to draft-farinacci-lisp-geo-00
> 
>*  Initial draft posted April 2016.
> 
> Author's Address
> 
>Dino Farinacci
>lispers.net
>San Jose, CA
>United States of America
>Email: farina...@gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> FarinacciExpires 24 October 2024   [Page 14]


> On 29 Apr 2024, at 22:37, Dino Farinacci  wrote:
> 
> Great - thanks Luigi. 
> 
> Dino
> 
>> On Apr 29, 2024, at 4:02 PM, Luigi Iannone  wrote:
>> 
>> Hi Dino,
>> 
>> I will send you the details about changes for your document.
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> On 29 Apr 2024, at 19:54, Dino Farinacci  wrote:
>>> 
>>> Its above my pay grade to decide on what to do. Ball is in your court.
>>> 
>>>> We need to ask IANA for a value different from 5 and currently unassigned, 
>>>> and at the same time deprecate the encoding in RFC8060.
>>> 
>>> If that is what you think, I'm fine with it.
>>> 
>>>> Yes, this means as well fixing implementations that shouldn’t have used 
>>>> type 5 in the first place.
>>> 
>>> Yes, but be realistic. You know what this means. Implementations will 
>>> accept both type values until there is enough evidence that no one uses the 
>>> old type anymore.
>>> 
>>> Dino
>>> 
>>> 
>> 

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

Re: [lisp] Review draft-ietf-lisp-te

[Luigi Iannone]

> On 29 Apr 2024, at 17:06, Dino Farinacci  wrote:
> 
> Okay, thanks. So this email has an updated version of your comments. Right?

Nope, I just put the mark on where to put the text. The comments are the same 
like in my previous mail.

Ciao

L.



> 
> Dino
> 
>> On Apr 29, 2024, at 5:24 AM, Luigi Iannone  wrote:
>> 
>> Hi Dino,
>> 
>> It was marked to append the text to section 5. 
>> 
>> I’ve added   to mark the exact spot, should be easier 
>> now ;-)
>> 
>> Ciao
>> 
>> L.
>> 
>>> On 27 Apr 2024, at 15:54, Dino Farinacci  wrote:
>>> 
>>> I browsed your comments. They are easier to interpret now. Thanks for that. 
>>> However, your  references are not helpful because they indicate you 
>>> want text to be moved but you don’t say where. So please clarify that 
>>> before I make any changes. 
>>> 
>>> Dino
>>> 
>>>> On Apr 26, 2024, at 9:16 AM, Luigi Iannone  wrote:
>>>> 
>>>> Comments inline.
>>>> 
>>>> Ciao
>>>> 
>>>> L.
>>>> 
>>>>> 
>>>>> 
>>>>> Internet Engineering Task Force D. Farinacci
>>>>> Internet-Draft lispers.net
>>>>> Intended status: Experimental M. Kowal
>>>>> Expires: 24 October 2024 cisco Systems
>>>>> P. Lahiri
>>>>> 22 April 2024
>>>>> 
>>>>> 
>>>>> LISP Traffic Engineering
>>>>> draft-ietf-lisp-te-15
>>>>> 
>>>>> Abstract
>>>>> 
>>>>> This document describes how LISP re-encapsulating tunnels can be used
>>>>> for Traffic Engineering purposes. The mechanisms described in this
>>>>> document require no LISP protocol changes but do introduce a new
>>>>> locator (RLOC) encoding. The Traffic Engineering features provided
>>>>> by these LISP mechanisms can span intra-domain, inter-domain, or
>>>>> combination of both.
>>>>> 
>>>>> Status of This Memo
>>>>> 
>>>>> This Internet-Draft is submitted in full conformance with the
>>>>> provisions of BCP 78 and BCP 79.
>>>>> 
>>>>> Internet-Drafts are working documents of the Internet Engineering
>>>>> Task Force (IETF). Note that other groups may also distribute
>>>>> working documents as Internet-Drafts. The list of current Internet-
>>>>> Drafts is at https://datatracker.ietf.org/drafts/current/.
>>>>> 
>>>>> Internet-Drafts are draft documents valid for a maximum of six months
>>>>> and may be updated, replaced, or obsoleted by other documents at any
>>>>> time. It is inappropriate to use Internet-Drafts as reference
>>>>> material or to cite them other than as "work in progress."
>>>>> 
>>>>> This Internet-Draft will expire on 24 October 2024.
>>>>> 
>>>>> Copyright Notice
>>>>> 
>>>>> Copyright (c) 2024 IETF Trust and the persons identified as the
>>>>> document authors. All rights reserved.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Farinacci, et al. Expires 24 October 2024 [Page 1]
>>>>> 
>>>>> Internet-Draft LISP Traffic Engineering April 2024
>>>>> 
>>>>> 
>>>>> This document is subject to BCP 78 and the IETF Trust's Legal
>>>>> Provisions Relating to IETF Documents (https://trustee.ietf.org/
>>>>> license-info) in effect on the date of publication of this document.
>>>>> Please review these documents carefully, as they describe your rights
>>>>> and restrictions with respect to this document. Code Components
>>>>> extracted from this document must include Revised BSD License text as
>>>>> described in Section 4.e of the Trust Legal Provisions and are
>>>>> provided without warranty as described in the Revised BSD License.
>>>>> 
>>>>> Table of Contents
>>>>> 
>>>>> 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
>>>>> 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
>>>>> 3. Definition of Terms . . . . . . . . . . . . . 

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi Dino,

I will send you the details about changes for your document.

Ciao

L.


> On 29 Apr 2024, at 19:54, Dino Farinacci  wrote:
> 
> Its above my pay grade to decide on what to do. Ball is in your court.
> 
>> We need to ask IANA for a value different from 5 and currently unassigned, 
>> and at the same time deprecate the encoding in RFC8060.
> 
> If that is what you think, I'm fine with it.
> 
>> Yes, this means as well fixing implementations that shouldn’t have used type 
>> 5 in the first place.
> 
> Yes, but be realistic. You know what this means. Implementations will accept 
> both type values until there is enough evidence that no one uses the old type 
> anymore.
> 
> Dino
> 
> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi Dino,

I went through the meeting meetings recordings  and minutes  of IETF 96/97/115 
when you did present this document.
No discussion about types value. Even on the mailing list there was nothing 
about the issue.

Until my first review  of the document in December 2022, when it was recently 
adopted as WG document.

My review: 
https://mailarchive.ietf.org/arch/msg/lisp/3YYoMIG_oDSs-4ZVZ9gkzy1eOoE/
States:
> > 
> > 
> >  0   1   2   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |   AFI = 16387 | Rsvd1 | Flags |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |   Type = 5| Rsvd2 |Length |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> You cannot use type 5. The type has been allocated in RFC 8060 and the 
> associated format already defined there (see also IANA section).
> 

How you can see I already pointed out the issue.
Your reply: 
https://mailarchive.ietf.org/arch/msg/lisp/peZDtwerz_r5t9Q7tkJv-W5kf1k/

> 
> I agree with all your comments and will do a revision. 
> 
> Regarding Type 5, that type was previously allocated *for this draft*. 
> Sometimes it is hard to remember since so much time has passed.
> 
> So we do not need a new type.
> 
> Dino
And my further reply: 
https://mailarchive.ietf.org/arch/msg/lisp/P21u34iuAUY8cncjFmW_NnLAIto/

> Hi Dino,
> 
> > On 9 Dec 2022, at 22:20, Dino Farinacci  
> > <mailto:<farina...@gmail.com>;> wrote:
> > 
> > I agree with all your comments and will do a revision. 
> > 
> > Regarding Type 5, that type was previously allocated *for this draft*. 
> > Sometimes it is hard to remember since so much time has passed.
> 
> Indeed it has been quite some time….
> 
> If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is 
> completely incompatible with the specs in this document.
> 
> What about asking for type 15 and name it “extended Geo-coordinates”?
> 
> Ciao
> 
> L.
> 

To which you further replied: 
https://mailarchive.ietf.org/arch/msg/lisp/L9WE04EZ0B5K8Weg1-1e2e_jzSk/

> > 
> > Hi Dino,
> > 
> >> On 9 Dec 2022, at 22:20, Dino Farinacci  
> >> <mailto:<farina...@gmail.com>;> wrote:
> >> 
> >> I agree with all your comments and will do a revision. 
> >> 
> >> Regarding Type 5, that type was previously allocated *for this draft*. 
> >> Sometimes it is hard to remember since so much time has passed.
> > 
> > Indeed it has been quite some time….
> > 
> > If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is 
> > completely incompatible with the specs in this document.
> 
> We need to update RFC 8060 so the format in the geo draft matches and points 
> to this use-case draft. That is what we have done with the other LCAF types. 
> So we just need to be consistent.
> 
> > What about asking for type 15 and name it “extended Geo-coordinates”?
> 
> There is no point to have 2 code points for Geo-Coordinates.
> 
> Want me to start on a 8060bis document?
> 
> Dino
> 

Followed by your mail: 
https://mailarchive.ietf.org/arch/msg/lisp/DuDuw3c2vi_Y_buNJBPsFuRHPlI/

> This update reflects Luigi's comments.
> 
> The only outstanding issue I think we have is if RFC8060 should be updated (I 
> think it should) to reflect the packet format changes.
> 
> Dino
> 


I have no trace of any private exchange with you about this document. If you 
have it please share it with us.

From my perspective the situation is the following:

I did raise the type value issue and suggested a solution one year and a half 
ago.

More recently I have tried to explain (in my email 
https://mailarchive.ietf.org/arch/msg/lisp/mLhu6ELFjBtoFJSzgDwndA5Xubw/) that 
even updating RFC8060, going through a 8060bis document (which we are chartered 
to do) will not solve the problem.
We cannot keep the value 5 in the geo document and deliberately change or 
delete the geo value in 8060bis. 

We need to ask IANA for a value different from 5 and currently unassigned, and 
at the same time deprecate the encoding in RFC8060.
Yes, this means as well fixing implementations that shouldn’t have used type 5 
in the first place.

Ciao

L.  




> On 27 Apr 2024, at 09:23, Luigi Iannone  wrote:
> 
> Hi Dino,
> 
>> On 27 Apr 2024, at 00:19, Dino Farinacci  wrote:
>> 
>> I think this is what transpired. 
>> 
>> (1) we wrote lisp-geo with exact packet syntax as RFC 8060. 
&

Re: [lisp] Review draft-ietf-lisp-te

[Luigi Iannone]

Hi Dino,

It was marked to append the text to section 5. 

I’ve added   to mark the exact spot, should be easier now 
;-)

Ciao

L.

> On 27 Apr 2024, at 15:54, Dino Farinacci  wrote:
> 
> I browsed your comments. They are easier to interpret now. Thanks for that. 
> However, your  references are not helpful because they indicate you 
> want text to be moved but you don’t say where. So please clarify that before 
> I make any changes. 
> 
> Dino
> 
>> On Apr 26, 2024, at 9:16 AM, Luigi Iannone  wrote:
>> 
>> 
>> Comments inline.
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> 
>>> 
>>> 
>>> Internet Engineering Task Force D. Farinacci
>>> Internet-Draft   lispers.net
>>> Intended status: Experimental   M. Kowal
>>> Expires: 24 October 2024   cisco Systems
>>>P. Lahiri
>>>22 April 2024
>>> 
>>> 
>>> LISP Traffic Engineering
>>>  draft-ietf-lisp-te-15
>>> 
>>> Abstract
>>> 
>>>This document describes how LISP re-encapsulating tunnels can be used
>>>for Traffic Engineering purposes.  The mechanisms described in this
>>>document require no LISP protocol changes but do introduce a new
>>>locator (RLOC) encoding.  The Traffic Engineering features provided
>>>by these LISP mechanisms can span intra-domain, inter-domain, or
>>>combination of both.
>>> 
>>> Status of This Memo
>>> 
>>>This Internet-Draft is submitted in full conformance with the
>>>provisions of BCP 78 and BCP 79.
>>> 
>>>Internet-Drafts are working documents of the Internet Engineering
>>>Task Force (IETF).  Note that other groups may also distribute
>>>working documents as Internet-Drafts.  The list of current Internet-
>>>Drafts is at https://datatracker.ietf.org/drafts/current/.
>>> 
>>>Internet-Drafts are draft documents valid for a maximum of six months
>>>and may be updated, replaced, or obsoleted by other documents at any
>>>time.  It is inappropriate to use Internet-Drafts as reference
>>>material or to cite them other than as "work in progress."
>>> 
>>>This Internet-Draft will expire on 24 October 2024.
>>> 
>>> Copyright Notice
>>> 
>>>Copyright (c) 2024 IETF Trust and the persons identified as the
>>>document authors.  All rights reserved.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci, et al.Expires 24 October 2024[Page 1]
>>> 
>>> Internet-Draft  LISP Traffic Engineering  April 2024
>>> 
>>> 
>>>This document is subject to BCP 78 and the IETF Trust's Legal
>>>Provisions Relating to IETF Documents (https://trustee.ietf.org/
>>>license-info) in effect on the date of publication of this document.
>>>Please review these documents carefully, as they describe your rights
>>>and restrictions with respect to this document.  Code Components
>>>extracted from this document must include Revised BSD License text as
>>>described in Section 4.e of the Trust Legal Provisions and are
>>>provided without warranty as described in the Revised BSD License.
>>> 
>>> Table of Contents
>>> 
>>>1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
>>>2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>>>3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
>>>4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
>>>5.  Explicit Locator Paths  . . . . . . . . . . . . . . . . . . .   5
>>>  5.1.  ELP Re-optimization . . . . . . . . . . . . . . . . . . .   7
>>>  5.2.  Using Recursion . . . . . . . . . . . . . . . . . . . . .   8
>>>  5.3.  ELP Selection based on Class of Service . . . . . . . . .   8
>>>  5.4.  Packet Loop Avoidance . . . . . . . . . . . . . . . . . .   9
>>>6.  Service Chaining  . . . . . . . . . . . . . . . . . . . . . .  10
>>>7.  RLOC Probing by RTRs  . . .

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi Dino,

> On 27 Apr 2024, at 00:19, Dino Farinacci  wrote:
> 
> I think this is what transpired. 
> 
> (1) we wrote lisp-geo with exact packet syntax as RFC 8060. 
> (2) We received comments from Enke, Naiming, Chris Hopps, and Acee. 
> (3) We changed the format to be consistent with OSPF, ISIS, and BGP (the 
> lisp-geo Document Change section documents this and when). 
> (4) I asked if we could change RFC 8060 and pretty sure Luigi said yes.

I do not recall any of this. I remember agreeing on changing the format. I 
admit I did not pay attention to the code point (most probably assuming that it 
will be different). 

But I will check my email archive to see if there is anything related or that 
may suggest otherwise I will share it on the mailing list.

Ciao

L.


> 
> That’s my memory. 
> 
> Dino
> 
>> On Apr 26, 2024, at 6:07 PM, Joel Halpern  wrote:
>> 
>> It's up to Luigi and Padma, but my read is that if it was private it was 
>> not a WG decision.
>> 
>> Yours,
>> 
>> Joel
>> 
>> On 4/26/2024 6:05 PM, Dino Farinacci wrote:
 Can you find an on-list email where such a conclusion was reached.  That 
 would certainly explain your choice.
>>> I searched (before I sent the last email) and could not find anything. 
>>> Likely it was private.
>>> 
>>> Dino

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

[lisp] Review draft-ietf-lisp-te

[Luigi Iannone]

Comments inline.

Ciao

L.


> 
> 
> 
> 
> 
> Internet Engineering Task Force D. Farinacci
> Internet-Draft   lispers.net
> Intended status: Experimental   M. Kowal
> Expires: 24 October 2024   cisco Systems
>P. Lahiri
>22 April 2024
> 
> 
> LISP Traffic Engineering
>  draft-ietf-lisp-te-15
> 
> Abstract
> 
>This document describes how LISP re-encapsulating tunnels can be used
>for Traffic Engineering purposes.  The mechanisms described in this
>document require no LISP protocol changes but do introduce a new
>locator (RLOC) encoding.  The Traffic Engineering features provided
>by these LISP mechanisms can span intra-domain, inter-domain, or
>combination of both.
> 
> Status of This Memo
> 
>This Internet-Draft is submitted in full conformance with the
>provisions of BCP 78 and BCP 79.
> 
>Internet-Drafts are working documents of the Internet Engineering
>Task Force (IETF).  Note that other groups may also distribute
>working documents as Internet-Drafts.  The list of current Internet-
>Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
>Internet-Drafts are draft documents valid for a maximum of six months
>and may be updated, replaced, or obsoleted by other documents at any
>time.  It is inappropriate to use Internet-Drafts as reference
>material or to cite them other than as "work in progress."
> 
>This Internet-Draft will expire on 24 October 2024.
> 
> Copyright Notice
> 
>Copyright (c) 2024 IETF Trust and the persons identified as the
>document authors.  All rights reserved.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Farinacci, et al.Expires 24 October 2024[Page 1]
> 
> Internet-Draft  LISP Traffic Engineering  April 2024
> 
> 
>This document is subject to BCP 78 and the IETF Trust's Legal
>Provisions Relating to IETF Documents (https://trustee.ietf.org/
>license-info) in effect on the date of publication of this document.
>Please review these documents carefully, as they describe your rights
>and restrictions with respect to this document.  Code Components
>extracted from this document must include Revised BSD License text as
>described in Section 4.e of the Trust Legal Provisions and are
>provided without warranty as described in the Revised BSD License.
> 
> Table of Contents
> 
>1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
>2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
>4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
>5.  Explicit Locator Paths  . . . . . . . . . . . . . . . . . . .   5
>  5.1.  ELP Re-optimization . . . . . . . . . . . . . . . . . . .   7
>  5.2.  Using Recursion . . . . . . . . . . . . . . . . . . . . .   8
>  5.3.  ELP Selection based on Class of Service . . . . . . . . .   8
>  5.4.  Packet Loop Avoidance . . . . . . . . . . . . . . . . . .   9
>6.  Service Chaining  . . . . . . . . . . . . . . . . . . . . . .  10
>7.  RLOC Probing by RTRs  . . . . . . . . . . . . . . . . . . . .  10
>8.  ELP Probing . . . . . . . . . . . . . . . . . . . . . . . . .  10
>9.  Interworking Considerations . . . . . . . . . . . . . . . . .  11
>10. Multicast Considerations  . . . . . . . . . . . . . . . . . .  12
>11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
>12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
>13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
>  13.1.  Normative References . . . . . . . . . . . . . . . . . .  14
>  13.2.  Informative References . . . . . . . . . . . . . . . . .  15
>Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  16
>Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  16
>  B.1.  Changes to draft-ietf-lisp-te-15  . . . . . . . . . . . .  16
>  B.2.  Changes to draft-ietf-lisp-te-14  . . . . . . . . . . . .  16
>  B.3.  Changes to draft-ietf-lisp-te-13  . . . . . . . . . . . .  16
>  B.4.  Changes to draft-ietf-lisp-te-12  . . . . . . . . . . . .  16
>  B.5.  Changes to draft-ietf-lisp-te-11  . . . . . . . . . . . .  16
>  B.6.  Changes to draft-ietf-lisp-te-10  . . . . . . . . . . . .  17
>  B.7.  Changes to draft-ietf-lisp-te-09  . . . . . . . . . . . .  17
>  B.8.  Changes to draft-ietf-lisp-te-08  . . . . . . . . . . . .  17
>  B.9.  Changes to draft-ietf-lisp-te-07  . . . . . . . . . . . .  17
>  B.10. Changes to draft-ietf-lisp-te-06  . . . . . . . .

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi,

I think that the answer to the “why” question is easy. The new encoding is the 
same as for BGP/ISIS/OSPF, so it makes sense to use it.

The problem lays in the “type” value that this new encoding is using.

The document should ask IANA to allocate a new code point. Values 4/8/14-254 
are unassigned as for: 
https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-lcaf-type
The document can suggest a value, but not impose one (See section 9.3 RFC8126). 
An early allocation should also be possible according to RFC7120.
Hence, the argument that by changing the type value implementations are 
obsoleted does not hold. 

The WG can decide whether to deprecate the encoding proposed in RFC8060 or let 
it run in parallel.
If we deprecate the encoding in RFC8060 then this document has to update 
RFC8060.
(My personal opinion is that there is no usefulness in having two different 
encodings)

The fact that both geo encodings use type 5 is the real issue to me.
Deprecating the encoding in RFC8060 does not help since there is no way to make 
the difference and know, by looking at the type, which encoding is used.
Section 9.4 of RFC8126 discourages reclaiming values for other usage except 
when the namespace is (almost) exhausted, which is not the case here.

As for the implementations… more than the number of implementations what really 
matters is the deployments.

Can anyone state that there are no deployments using RFC8060 encoding? Or if 
they exist if it is feasible to quickly and easily switch them to the new 
encoding.

In the lack of these conditions the only reasonable action IMO is to use a 
different type value.

Ciao

L.
  





> On 23 Apr 2024, at 18:24, Joel Halpern  wrote:
> 
> From where I sit, doing nothing should be a non-starter.  We have a published 
> RFC.  We are allowed to change our mind.
> 
> But...
> 
> 1) We need to be explicit about making such a change.  Which involves 
> updating the existing RFC.
> 
> 2) Any such change needs to explain why it is being changed. Just because a 
> later implementation did it differently, without a standard, does not justify 
> changing the standard.  If there is an actual benefit to the change we should 
> step up, admit we are changing it, and explain why.
> 
> Yours,
> 
> Joel
> 
> On 4/23/2024 11:48 AM, Dino Farinacci wrote:
>>> As I said, the simplest solution is to use a different type value. This 
>>> allows to still use the old encoding and does not obsoletes implementations 
>>> that use it.
>> You will obsolete implementations if we do that. Which really means you make 
>> the spec irrelevant. So I say stay with the same code point.
>> 
>>> Option B. This document officially updates 8060, but this means that 
>>> existing implementation of the 8060 encoding are not valid anymore.
>> Right. But so much time has passed between from when the lisp-geo spec was 
>> published I believe most implementations have done lisp-geo encoding vs RFC 
>> 8060. My lispers.net implementation does the lisp-geo encoding with the type 
>> defined in the draft which is the same as RFC 8060.
>> 
>>> How many implementation of this draft are you aware of?
>> I think cisco and lispers.net. But cisco has to confirm.
>> 
>> I think we should do Option C which is do nothing to RFC 8060 and put text 
>> in the lisp-geo spec which indicates its encoding takes precedent over RFC 
>> 8060 using the same code point and document all implementations have evolved 
>> to the lisp-geo spec.
>> 
>> Dino
>> 
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi Dino,



> On 23 Apr 2024, at 00:57, Dino Farinacci  wrote:
> 
>> P.s.
>> 
>> Just noticed that this document proposes an encoding which is not the same 
>> as the one in RFC 8060 but use the same type number.
> 
> That is right, we chose a format consistent with the IGPs so RFC8060 has to 
> updated. I made this clear when the change was made.
> 
> Since so much time passes since we are not being productive, the same 
> arguments resurface years later. And its getting harder and harder for people 
> to remember and keep context.
> 
> So should I submit a change to RFC 8060 and call it RFC 8060bis?

You can, but this will slow down the publication of this draft because of the 
dependency.

As I said, the simplest solution is to use a different type value. This allows 
to still use the old encoding and does not obsoletes implementations that use 
it.

Option B. This document officially updates 8060, but this means that existing 
implementation of the 8060 encoding are not valid anymore.



> 
>> This is not possible. The best solution would be to use a different type 
>> number.
> 
> The implementations use the latest in the draft.
> 

How many implementation of this draft are you aware of?

Ciao

L.



>> On 22 Apr 2024, at 13:23, Luigi Iannone  wrote:
>>> 
>>> Dino,
>>> 
>>> You did put a reference to other protocols in the acknowledgement section. 
>>> This is not enough.
>>> 
>>> You should put a sentence like:
>>> 
>>> The encoding format is consistent with the encoding used in other routing 
>>> protocols, namely: OSPF [I-D.acee-ospf-geo-location], IS-IS 
>>> [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates] 
>>> protocols.
> 
> I will add. Thanks for the text.
> 
>>> This sentence should be placed at the end of section 5, where you describe 
>>> the encoding.
> 
> Okay. See diff enclosed.
> 
> Dino
> 
> 
> 
> 
> 
> 
> 
>>> 
>>> Ciao
>>> 
>>> L.
>>> 
>>> 
>>> 
>>>> On 18 Apr 2024, at 17:19, Dino Farinacci  wrote:
>>>> 
>>>> You have to judge that. We do have references that point to ISIS and OSPF. 
>>>> 
>>>> Dino
>>>> 
>>>>> On Apr 18, 2024, at 8:14 AM, Luigi Iannone  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 18 Apr 2024, at 16:19, Dino Farinacci  wrote:
>>>>>> 
>>>>>> LISP geo-location decided to use the encoding format consistent and 
>>>>>> coordinated with the routing protocols. 
>>>>>> 
>>>>> 
>>>>> Is this clearly state in the document?
>>>>> 
>>>>> L.
>>>>> 
>>>>>> Dino
>>>>>> 
>>>>>>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Hello Dino and Alberto 
>>>>>>> 
>>>>>>> The  Yang Doctor review had comments on Yang -20 draft regarding the 
>>>>>>> geoloc. 
>>>>>>> For reference comment from Joe Clark 
>>>>>>> As to the two questions asked here, I can see some benefit of breaking 
>>>>>>> out the IANA parts of address-types into a module that they maintain. 
>>>>>>> But in its current form, I don't know that it makes sense to have them 
>>>>>>> maintain it. As for geoloc, I do see some overlap, but I am not a LISP 
>>>>>>> expert at all, so I cannot comment as to whether bringing that whole 
>>>>>>> module in makes sense or would even work with LISP implementations. 
>>>>>>> That is, it seems LISP lat and long are expressed in degrees° 
>>>>>>> minutes'seconds" whereas geoloc does this as a decimal64 from a 
>>>>>>> reference frame. I do feel that whatever direction is taken, text 
>>>>>>> explaining why geoloc is not used is useful.
>>>>>>> 
>>>>>>> Per Med's comment on groupings - 
>>>>>>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/
>>>>>>> 
>>>>>>> Consolidating these comments in a single thread here for resolution and 
>>>>>>> discussion on the list before the refresh,
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Padma and Luigi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 
> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

P.s.

Just noticed that this document proposes an encoding which is not the same as 
the one in RFC 8060 but use the same type number.

This is not possible. The best solution would be to use a different type number.

Ciao

L.



> On 22 Apr 2024, at 13:23, Luigi Iannone  wrote:
> 
> Dino,
> 
> You did put a reference to other protocols in the acknowledgement section. 
> This is not enough.
> 
> You should put a sentence like:
> 
> The encoding format is consistent with the encoding used in other routing 
> protocols, namely: OSPF [I-D.acee-ospf-geo-location 
> <https://datatracker.ietf.org/doc/html/draft-acee-ospf-geo-location-05>], 
> IS-IS [I-D.shen-isis-geo-coordinates 
> <https://datatracker.ietf.org/doc/html/draft-shen-isis-geo-coordinates-04>], 
> and BGP [I-D.chen-idr-geo-coordinates 
> <https://datatracker.ietf.org/doc/html/draft-chen-idr-geo-coordinates-02>] 
> protocols.
> 
> This sentence should be placed at the end of section 5, where you describe 
> the encoding.
> 
> Ciao
> 
> L.
> 
> 
> 
>> On 18 Apr 2024, at 17:19, Dino Farinacci  wrote:
>> 
>> You have to judge that. We do have references that point to ISIS and OSPF. 
>> 
>> Dino
>> 
>>> On Apr 18, 2024, at 8:14 AM, Luigi Iannone  wrote:
>>> 
>>> 
>>> 
>>>> On 18 Apr 2024, at 16:19, Dino Farinacci  wrote:
>>>> 
>>>> LISP geo-location decided to use the encoding format consistent and 
>>>> coordinated with the routing protocols. 
>>>> 
>>> 
>>> Is this clearly state in the document?
>>> 
>>> L.
>>> 
>>>> Dino
>>>> 
>>>>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault  
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> Hello Dino and Alberto 
>>>>> 
>>>>> The  Yang Doctor review had comments on Yang -20 draft regarding the 
>>>>> geoloc. 
>>>>> For reference comment from Joe Clark 
>>>>> As to the two questions asked here, I can see some benefit of breaking 
>>>>> out the IANA parts of address-types into a module that they maintain.  
>>>>> But in its current form, I don't know that it makes sense to have them 
>>>>> maintain it.  As for geoloc, I do see some overlap, but I am not a LISP 
>>>>> expert at all, so I cannot comment as to whether bringing that whole 
>>>>> module in makes sense or would even work with LISP implementations.  That 
>>>>> is, it seems LISP lat and long are expressed in degrees° minutes'seconds" 
>>>>> whereas geoloc does this as a decimal64 from a reference frame.  I do 
>>>>> feel that whatever direction is taken, text explaining why geoloc is not 
>>>>> used is useful.
>>>>> 
>>>>> Per Med's comment on groupings - 
>>>>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/
>>>>> 
>>>>> Consolidating these comments in a single thread here for resolution and 
>>>>> discussion on the list before the refresh,
>>>>> 
>>>>> Thanks
>>>>> Padma and Luigi
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Dino,

You did put a reference to other protocols in the acknowledgement section. This 
is not enough.

You should put a sentence like:

The encoding format is consistent with the encoding used in other routing 
protocols, namely: OSPF [I-D.acee-ospf-geo-location 
<https://datatracker.ietf.org/doc/html/draft-acee-ospf-geo-location-05>], IS-IS 
[I-D.shen-isis-geo-coordinates 
<https://datatracker.ietf.org/doc/html/draft-shen-isis-geo-coordinates-04>], 
and BGP [I-D.chen-idr-geo-coordinates 
<https://datatracker.ietf.org/doc/html/draft-chen-idr-geo-coordinates-02>] 
protocols.

This sentence should be placed at the end of section 5, where you describe the 
encoding.

Ciao

L.



> On 18 Apr 2024, at 17:19, Dino Farinacci  wrote:
> 
> You have to judge that. We do have references that point to ISIS and OSPF. 
> 
> Dino
> 
>> On Apr 18, 2024, at 8:14 AM, Luigi Iannone  wrote:
>> 
>> 
>> 
>>> On 18 Apr 2024, at 16:19, Dino Farinacci  wrote:
>>> 
>>> LISP geo-location decided to use the encoding format consistent and 
>>> coordinated with the routing protocols. 
>>> 
>> 
>> Is this clearly state in the document?
>> 
>> L.
>> 
>>> Dino
>>> 
>>>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault  
>>>> wrote:
>>>> 
>>>> 
>>>> Hello Dino and Alberto 
>>>> 
>>>> The  Yang Doctor review had comments on Yang -20 draft regarding the 
>>>> geoloc. 
>>>> For reference comment from Joe Clark 
>>>> As to the two questions asked here, I can see some benefit of breaking out 
>>>> the IANA parts of address-types into a module that they maintain.  But in 
>>>> its current form, I don't know that it makes sense to have them maintain 
>>>> it.  As for geoloc, I do see some overlap, but I am not a LISP expert at 
>>>> all, so I cannot comment as to whether bringing that whole module in makes 
>>>> sense or would even work with LISP implementations.  That is, it seems 
>>>> LISP lat and long are expressed in degrees° minutes'seconds" whereas 
>>>> geoloc does this as a decimal64 from a reference frame.  I do feel that 
>>>> whatever direction is taken, text explaining why geoloc is not used is 
>>>> useful.
>>>> 
>>>> Per Med's comment on groupings - 
>>>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/
>>>> 
>>>> Consolidating these comments in a single thread here for resolution and 
>>>> discussion on the list before the refresh,
>>>> 
>>>> Thanks
>>>> Padma and Luigi
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 

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

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Ack.

I will have a look on Monday.

Ciao

L.

> On 18 Apr 2024, at 17:19, Dino Farinacci  wrote:
> 
> 
> You have to judge that. We do have references that point to ISIS and OSPF. 
> 
> Dino
> 
>>> On Apr 18, 2024, at 8:14 AM, Luigi Iannone  wrote:
>>> 
>> 
>> 
>>> On 18 Apr 2024, at 16:19, Dino Farinacci  wrote:
>>> 
>>> LISP geo-location decided to use the encoding format consistent and 
>>> coordinated with the routing protocols. 
>>> 
>> 
>> Is this clearly state in the document?
>> 
>> L.
>> 
>>> Dino
>>> 
>>>>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault  
>>>>> wrote:
>>>>> 
>>>> 
>>>> Hello Dino and Alberto 
>>>> 
>>>> The  Yang Doctor review had comments on Yang -20 draft regarding the 
>>>> geoloc. 
>>>> For reference comment from Joe Clark 
>>>> As to the two questions asked here, I can see some benefit of breaking out 
>>>> the IANA parts of address-types into a module that they maintain.  But in 
>>>> its current form, I don't know that it makes sense to have them maintain 
>>>> it.  As for geoloc, I do see some overlap, but I am not a LISP expert at 
>>>> all, so I cannot comment as to whether bringing that whole module in makes 
>>>> sense or would even work with LISP implementations.  That is, it seems 
>>>> LISP lat and long are expressed in degrees° minutes'seconds" whereas 
>>>> geoloc does this as a decimal64 from a reference frame.  I do feel that 
>>>> whatever direction is taken, text explaining why geoloc is not used is 
>>>> useful.
>>>> 
>>>> Per Med's comment on groupings - 
>>>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/
>>>> 
>>>> Consolidating these comments in a single thread here for resolution and 
>>>> discussion on the list before the refresh,
>>>> 
>>>> Thanks
>>>> Padma and Luigi
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

> On 18 Apr 2024, at 16:19, Dino Farinacci  wrote:
> 
> LISP geo-location decided to use the encoding format consistent and 
> coordinated with the routing protocols. 
> 

Is this clearly state in the document?

L.

> Dino
> 
>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault  
>> wrote:
>> 
>> 
>> Hello Dino and Alberto 
>> 
>> The  Yang Doctor review had comments on Yang -20 draft regarding the geoloc. 
>> For reference comment from Joe Clark 
>> As to the two questions asked here, I can see some benefit of breaking out 
>> the IANA parts of address-types into a module that they maintain.  But in 
>> its current form, I don't know that it makes sense to have them maintain it. 
>>  As for geoloc, I do see some overlap, but I am not a LISP expert at all, so 
>> I cannot comment as to whether bringing that whole module in makes sense or 
>> would even work with LISP implementations.  That is, it seems LISP lat and 
>> long are expressed in degrees° minutes'seconds" whereas geoloc does this as 
>> a decimal64 from a reference frame.  I do feel that whatever direction is 
>> taken, text explaining why geoloc is not used is useful.
>> 
>> Per Med's comment on groupings - 
>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/
>> 
>> Consolidating these comments in a single thread here for resolution and 
>> discussion on the list before the refresh,
>> 
>> Thanks
>> Padma and Luigi
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

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

Re: [lisp] RFCs 9300, 9301, 9301

[Luigi Iannone]

Hi Dave,

RFC that are standard track have different maturity level. 
The requirements and procedure to become Internet Standard are described in RFC 
6410 (https://datatracker.ietf.org/doc/rfc6410/)

Ciao

L.

> On 9 Apr 2024, at 02:31, Dave Fusik (dfusik) 
>  wrote:
> 
> To whom it may concern,
> Sorry to bother you. I see that the above RFCs have a status of "Proposed 
> Standard" and I'm wondering if you can provide any insight on when these will 
> progress to "Internet Standard". Thanks for any information you can provide.
> 
> Best regards,
> Dave Fusik
> 
> Solutions Engineer | CISCO – U.S. Federal Defense Sales
> CCDE #2013::70 | CCIE #4768: Enterprise Infrastructure and Security
> Office: 919-392-3701 | Cell: 919-637-1058 | dfu...@cisco.com 
> ___
> 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] LISP WG Meeting Cancellation

[Luigi Iannone]

Hi All,


Due to the lack of a sufficient number of presenters, and after discussion 
among the chairs, we decided  to cancel the LISP WG Session for IETF 119.
We will resume face to face meeting in Vancouver in IETF 120.
In the meantime we have a couple of milestone to work on.

Thanks

Ciao

Luigi & Padma

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

[lisp] Call for Agenda items (lisp - Requested session has been scheduled for IETF 119)

[Luigi Iannone]

Hi All,

The LISP session has been scheduled for the next IETF.

It is time now to build the agenda.

Please send to the chairs your slot request before 5th March, so that we can 
publish the agenda by 6th March.

Thanks

Ciao

L.


> Begin forwarded message:
> 
> From: "\"IETF Secretariat\"" 
> Subject: lisp - Requested session has been scheduled for IETF 119
> Date: February 23, 2024 at 23:53:57 GMT+1
> To: , 
> Cc: james.n.guich...@futurewei.com, lisp@ietf.org
> 
> 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:30 requested)
>Tuesday, 19 March 2024, Session III 1530-1700 Australia/Brisbane
>Room Name: M1 [Breakout 3] (size: 125)
>-
> 
> 
> iCalendar: https://datatracker.ietf.org/meeting/119/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: Monday morning, Friday late afternoon
> 
> Participants who must be present:
>  Alberto Rodriguez-Natal
> 
> Resources Requested:
> 
> Special Requests:
>  Preferred time slot: late afternoon
> -
> 
> 

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

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

[Luigi Iannone]

Hi All,

This call is now closed.
 
In the last two weeks several emails have shown support in moving the document 
to standard track.

As such it seems that the WG has consensus on this change.

The authors are invited to submit a new revision of the document  and change 
intended status.
The new revision has to include a section about deployment experience. 

Ciao

L.



> On Jan 11, 2024, at 13:52, Luigi Iannone  wrote:
> 
> 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 <mailto:lisp@ietf.org>
>> https://www.ietf.org/mailman/listinfo/lisp
> 

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

[lisp] Fwd: New charter approved

[Luigi Iannone]

Good news, the new charter is now approved ;-)

Ciao

L.

> Begin forwarded message:
> 
> From: James Guichard 
> Subject: New charter approved
> Date: January 25, 2024 at 18:00:43 GMT+1
> To: "lisp-cha...@ietf.org" 
> Resent-From: 
> Resent-To: na...@cisco.com, padma.i...@gmail.com, g...@gigix.net
> 
> Folks:
>  
> Just to let you know that the new LISP charter has now been approved.
>  
> Jim

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

Re: [lisp] Roman Danyliw's Block on charter-ietf-lisp-04-06: (with BLOCK and COMMENT)

[Luigi Iannone]

Hi Roman,

Congrats for your appointment as new IETF Chair and also thanks for taking this 
responsibility.

I know that your days are now busier but I want to ping you whether you get a 
chance to review the suggestions Padma made to solve your block on the LISP 
Charter.

Thanks

Ciao 

L.


> On Jan 4, 2024, at 17:44, Padma Pillay-Esnault  wrote:
> 
> Hi Roman 
> 
> Please see PPE for my comments inline
> 
> On Wed, Jan 3, 2024 at 1:14 PM Roman Danyliw via Datatracker 
> mailto:nore...@ietf.org>> wrote:
>> Roman Danyliw has entered the following ballot position for
>> charter-ietf-lisp-04-06: Block
>> 
>> 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.)
>> 
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>> 
>> 
>> 
>> --
>> BLOCK:
>> --
>> 
>> Per the following set of work "Privacy and Security: The WG will work on EID
>> anonymity, VPN segmentation leveraging on the Instance ID, and traffic
>> anonymization. The reuse of existing mechanisms will be prioritized.":
>> 
>> -- What is the threat model assumed for "traffic anonymization" and "EID
>> anonymity"?  Could the desired security properties be clarified?
>> 
>> PPE - LISP has an (EID, Routing Location) pair, it is possible to learn of a 
>> specific long lived EID and then poll the mapping system to know its new 
>> bindings over time. It would be therefore possible to record and track long 
>> lived EIDs and identify the traffic specifically for that endpoint. Some 
>> desired security properties would be to have short lived EIDs as well as 
>> secured and restricted access to binding of an EID and locator for privacy. 
>  
>> --
>> COMMENT:
>> --
>> 
>> Per the following set of work "Privacy and Security: The WG will work on EID
>> anonymity, VPN segmentation leveraging on the Instance ID, and traffic
>> anonymization. The reuse of existing mechanisms will be prioritized.":
>> 
>> -- What will the output of this work look like?  Which milestone is it
>> associated with?
>> 
>> PPE - There are currently 2 WG drafts and the milestone is 
>> March 2025 Submit LISP Privacy and Security document(s) to the IESG for 
>> consideration (Privacy and Security) [EXPERIMENTAL]
>> 
> Thanks
> Padma 

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

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

[Luigi Iannone]

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] Lars Eggert's No Objection on charter-ietf-lisp-04-04: (with COMMENT)

[Luigi Iannone]

Hi Lars,

Thanks for  sharing your comments. Please see inline.

> On Nov 30, 2023, at 13:58, Lars Eggert via Datatracker  
> wrote:
> 
> Lars Eggert has entered the following ballot position for
> charter-ietf-lisp-04-04: 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.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lisp/
> 
> 
> 
> --
> COMMENT:
> --
> 
> # GEN AD review of charter-ietf-lisp-04-04
> 
> CC @larseggert
> 
> ## Comments
> 
> ### "LISP", paragraph 1
> ```
>  - LISP for Traffic Engineering: Specifics on how to do traffic engineering on
>  LISP deployments could be useful. For instance, encode in a mapping not only
>  the routing locators associated to EIDs, but also an ordered set of
>  re-encapsulating tunnel routers (RTRs) used to specify a path.
> ```
> "Could be useful" is a pretty weak motivator. Does anyone want
> to *deploy* this? If not, does it deserve to be a work item?

This is indeed a weak formulation. The work is already being implemented and 
used. Let’ change it in “…. Is a useful feature”.


> 
> ### "LISP", paragraph 0
> ```
>  - NAT-Traversal: Support for a NAT-traversal solution in deployments where 
> LISP
>  tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).

Tha should be better phrased as “endpoints are behind a NAT…"

> ```
> Stick it into UDP and use existing NAT traversal solutions.
> Re-engineering all that does not seem worthwhile.

Unfortunately there are peculiarities in LISP that do not make existing 
solution directly applicable (mostly for the control plane).
However,  The document is not about new NAT traversal method, rather what 
changes in the LISP control plane messages are necessary to make LISP work 
behind a NAT.
Should we just say “support for NAT”? Since we are not inventing a new 
NAT-traversal technology.


> 
> ### "LISP", paragraph 2
> ```
>  - 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 internet-working, for instance by defining
>  mechanisms to discover such external connectivity.
> ```
> "Could benefit" is a pretty weak motivator. Does anyone want
> to *deploy* this? If not, does it deserve to be a work item?

It is the same case like LISP-TE. There is a document and an implementation. 
What about “advanced internet-working solution bring clear benefits to LISP 
deployments…”

What do you think?

> 
> ### "LISP", paragraph 1
> ```
>  - Mobility: Some LISP deployment scenarios include endpoints that move across
>  different LISP xTRs and/or LISP xTRs that are themselves mobile. Support 
> needs
>  to be provided to achieve seamless connectivity.
> ```
> "Some deployment scenarios include it" is a pretty weak motivator.
> Does anyone want to *deploy* this? If not, does it deserve to be a work item?
> 

The some was referred to the fact that LISP deployment may or may not include 
mobile nodes, when they do endpoints as well as xTRs may be mobile.

What about: 
"- Mobility: LISP deployments include mobility where endpoints  can move across
 different LISP xTRs and/or LISP xTRs  can themselves be mobile." 

Does it sound better?


Ciao

L.


> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
> 
> 
> 

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

Re: [lisp] John Scudder's Block on charter-ietf-lisp-04-04: (with BLOCK and COMMENT)

[Luigi Iannone]

Fine from my side as well.

Ciao

L.

> On Nov 30, 2023, at 14:50, James Guichard  
> wrote:
> 
> Hi, John et al,
>  
> I have made the necessary changes to the charter as suggested by Luigi and 
> confirmed by you John. However, for the last issue, do we agree to simply 
> remove the text "LISP technology has a wide span of potential applications 
> beyond simple routing." ? I am happy to simply remove it as it does not 
> really add value as far as I can tell.
>  
> Jim
>  
> From: iesg  On Behalf Of John Scudder
> Sent: Thursday, November 30, 2023 8:26 AM
> To: Luigi Iannone 
> Cc: The IESG ; lisp-cha...@ietf.org; lisp@ietf.org
> Subject: Re: John Scudder's Block on charter-ietf-lisp-04-04: (with BLOCK and 
> COMMENT)
>  
> Hi Luigi,
>  
> That sounds good to me, thanks. I’ve removed my BLOCK in anticipation of the 
> changes. 
>  
> And yes, in my COMMENT, by “final bullet” I meant 
>  
> LISP Applicability: LISP has proved to be a very flexible protocol that can 
> be used in various use cases not considered during its design phase. [RFC7215 
> <https://datatracker.ietf.org/doc/rfc7215/>], while remaining a good source 
> of information, covers one single use case, which is no longer the main LISP 
> application scenario. The LISP WG will document LISP deployments for the most 
> recent and relevant use cases, so as to update and complement [RFC7215 
> <https://datatracker.ietf.org/doc/rfc7215/>] as needed.
>  
> —John
> 
> 
> On Nov 30, 2023, at 5:48 AM, Luigi Iannone  <mailto:g...@gigix.net>> wrote:
> 
> 
> Hi John,
> 
> Please see my comment inline.
> 
> 
> On Nov 29, 2023, at 19:41, John Scudder via Datatracker  <mailto:nore...@ietf.org>> wrote:
>  
> John Scudder has entered the following ballot position for
> charter-ietf-lisp-04-04: Block
>  
> 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.)
>  
>  
>  
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-lisp/__;!!NEt6yMaO-gk!ER_NGaNCQy2GG0ymlnRARDgzS7hiTiz30jWDdF-VFPv8JwVG6vxbrDVnQKVIT29EL2KLSKrF$
>  
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/charter-ietf-lisp/__;!!NEt6yMaO-gk!ER_NGaNCQy2GG0ymlnRARDgzS7hiTiz30jWDdF-VFPv8JwVG6vxbrDVnQKVIT29EL2KLSKrF$>
>  
>  
>  
> --
> BLOCK:
> --
>  
> I'm a little concerned about the unbounded scope the proposed charter gives 
> the
> working group. I am balloting BLOCK until we have a chance to discuss this:
>  
> "The LISP WG is chartered to continue work on the LISP protocol, including
> extensions for which the working group has consensus on deeming them 
> necessary".
>  
> 
> The “extensions” part was the limitation, with the idea of not starting do 
> everything and anything.
> 
> 
> 
> 
> It's very hard for me to imagine anything at all that would be out of scope
> according to that criterion, and that tells me the proposed charter should be
> made more specific. A first question to think about might be "necessary
> according to what metric or criterion?"
>  
> 
> Fair enough. What if we add “… deeming them necessary for the use cases 
> identified by the working as main LISP applications. Such use cases have to 
> be documented in an applicability document providing rationale for the work 
> done.
> 
> This would related with the last milestone about applicability document.
> 
> We can also add “minor” before “extension” to better clarify that we are 
> talking about limited extensions.
> 
> Do you think this goes in the right direction?
> Do you have a better idea?
> 
> 
>  
> --
> COMMENT:
> --
>  
> "LISP technology has a wide span of potential applications beyond simple
> routing."
>  
> As Martin pointed out, this statement on its own doesn't seem to add anything.
> To the extent there is something concrete here, doesn't the final bullet
> capture it?
> 
> Not sure which final bullet you refer to. The applicability document?
> 
> Ciao
> 
> L.

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

Re: [lisp] John Scudder's Block on charter-ietf-lisp-04-04: (with BLOCK and COMMENT)

[Luigi Iannone]

Hi John,

Please see my comment inline.

> On Nov 29, 2023, at 19:41, John Scudder via Datatracker  
> wrote:
> 
> John Scudder has entered the following ballot position for
> charter-ietf-lisp-04-04: Block
> 
> 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.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lisp/
> 
> 
> 
> --
> BLOCK:
> --
> 
> I'm a little concerned about the unbounded scope the proposed charter gives 
> the
> working group. I am balloting BLOCK until we have a chance to discuss this:
> 
> "The LISP WG is chartered to continue work on the LISP protocol, including
> extensions for which the working group has consensus on deeming them 
> necessary".
> 

The “extensions” part was the limitation, with the idea of not starting do 
everything and anything.



> It's very hard for me to imagine anything at all that would be out of scope
> according to that criterion, and that tells me the proposed charter should be
> made more specific. A first question to think about might be "necessary
> according to what metric or criterion?"
> 

Fair enough. What if we add “… deeming them necessary for the use cases 
identified by the working as main LISP applications. Such use cases have to be 
documented in an applicability document providing rationale for the work done. 

This would related with the last milestone about applicability document. 

We can also add “minor” before “extension” to better clarify that we are 
talking about limited extensions.

Do you think this goes in the right direction? 
Do you have a better idea?

> 
> --
> COMMENT:
> --
> 
> "LISP technology has a wide span of potential applications beyond simple
> routing."
> 
> As Martin pointed out, this statement on its own doesn't seem to add anything.
> To the extent there is something concrete here, doesn't the final bullet
> capture it?

Not sure which final bullet you refer to. The applicability document?

Ciao

L.


> 
> 
> 

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

Re: [lisp] Yangdoctors early review of draft-ietf-lisp-yang-20

[Luigi Iannone]

Joe,

Thank you very much for your review.

The authors will take care of addressing your comments.

Ciao

L.


> On Nov 27, 2023, at 19:04, Joe Clarke via Datatracker  
> wrote:
> 
> Reviewer: Joe Clarke
> Review result: On the Right Track
> 
> I am the latest member of YANG Doctors to review this document and the modules
> therein.  I looked over chopps' previous review, and it appears most of his
> comments have been addressed.  In my own reading, I found inconsistent use of
> capitalization and punctuation in descriptions (e.g., some ended in periods,
> some did not; most started with a capital letter, some did not); as well as
> inconsistent quoting.  All modules would benefit from a `pyang -f yang`
> normalization and an editorial pass.
> 
> In the ietf-lisp module itself, there are a couple of patterns in there where 
> I
> wonder if the regex is what you want exactly.  For example, is it okay if an
> eid-id starts with a ':' or a '-'?  For the locator-id, this is a string of
> 1-64 characters, but the regex hints it could be zero or more of the character
> class (a similar example exists with hop-id in address-types).
> 
> All modules' initial revisions reference the original LISP RFC but do so with 
> a
> URL only vs. a more correct, RFC 6830: ... syntax.  And speaking of revision,
> most of the modules have a revision of 2021-02-22 with the exception of itr 
> and
> mapresolver.  This isn't a big deal now, as I assume you'll set all of these
> when the draft is finalized.  You should also update all of the copyright 
> years
> and copyright text.
> 
> As to the two questions asked here, I can see some benefit of breaking out the
> IANA parts of address-types into a module that they maintain.  But in its
> current form, I don't know that it makes sense to have them maintain it.  As
> for geoloc, I do see some overlap, but I am not a LISP expert at all, so I
> cannot comment as to whether bringing that whole module in makes sense or 
> would
> even work with LISP implementations.  That is, it seems LISP lat and long are
> expressed in degrees° minutes'seconds" whereas geoloc does this as a decimal64
> from a reference frame.  I do feel that whatever direction is taken, text
> explaining why geoloc is not used is useful.
> 
> 

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

Re: [lisp] Martin Duke's No Objection on charter-ietf-lisp-04-01: (with COMMENT)

[Luigi Iannone]

Hi Martin,

Thanks for the catch the sentence is indeed unclear.

What about: 

LISP technology has a wide span of potential applications beyond the simple 
routing aspects.

Better?

L.
> On Nov 27, 2023, at 19:30, Martin Duke via Datatracker  
> wrote:
> 
> Martin Duke has entered the following ballot position for
> charter-ietf-lisp-04-01: 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.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lisp/
> 
> 
> 
> --
> COMMENT:
> --
> 
> What does this sentence mean?
> 
> "The scope of the LISP technology is potentially applicable to have a large 
> span"
> 
> Does it mean
> "LISP technology has a wide span of potential applications?"
> 
> and if so, is that a useful statement in a charter without more specifics?
> 
> 
> 

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

[lisp] Presenters' slides

[Luigi Iannone]

Hi All,

For those presenting during the meeting next week, please send the slides to 
the chairs so that we can put them on the material page.

Please make sure to send them by Sunday 5th November at latest.

Ciao

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

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

[Luigi Iannone]

All,

The call for adoption for this document is now expired.

During the two weeks only two emails in support of ti have been received (one 
of a co-authors).

As such, the chairs cannot declare consensus on the adoption.  

The WG does not seem to be interested in adopting and working on this document, 
which, however, does not mean that the document has any technical issue per-se.

Ciao

L.

> On Oct 12, 2023, at 14:32, Luigi Iannone  wrote:
> 
> 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] Confirm WG adoption for document draft-jain-lisp-site-external-connectivity

[Luigi Iannone]

All,

This call is now over.

We received one mail in support and no objections, as such the consensus shown 
during the face to face meeting is confirmed and the document adopted.

The authors are invited to submit a new revision with the name 
draft-ietf-lisp-site-external-connectivity at their earliest convenience.

Ciao

L. 

> On Oct 12, 2023, at 14:32, Luigi Iannone  wrote:
> 
> All,
> 
> During the last LISP WG meeting  the authors of the draft:
> 
> LISP Site External Connectivity
> https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/
> 
> Asked for adoption as WG document.
> Call for adoption during the meeting showed clear consensus (see: 
> https://datatracker.ietf.org/doc/minutes-117-lisp/)
> This email is the usual procedure to confirm the consensus on the mailing 
> list.
> 
> If anybody has concerns about adopting this document please state so on the 
> mailing list before October 26, 2023
> Please also argument the technical reason why you have concerns.
> 
> Ciao
> 
> Luigi, Padma, Alberto

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

Re: [lisp] My comments to latest updates to LISP charter

[Luigi Iannone]

What about putting Geo on March and TE on July? With good chances that we 
finish everything before July.

L.

> On Oct 25, 2023, at 18:19, Dino Farinacci  wrote:
> 
>> Concerning Geo, I understand that from your perspective the work is done, 
>> however, if we put it on March 2024 then we have 4 docs to work on.
>> I prefer to spread a bit so to smooth the workload (for shepherd+AD).
> 
> Start on lisp-geo now and we can finish it before March 2024. It has already 
> been started since we had AD review. And we had some IESG review already as 
> well (Chris Hopps).
> 
> Dino
> 
> 

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

Re: [lisp] LISP WG Agenda

[Luigi Iannone]

Ack,

done

L.

> On Oct 25, 2023, at 18:18, Dino Farinacci  wrote:
> 
> Prasad requested to present (I will present since Prasad won't be in Prague) 
> draft-vdas-lisp-group-mapping-01. If there is not enough time, then can you 
> replace the gaapchat slot with draft-vdas-lisp-group-mapping-01. 
> 
> The IPv6 gaapchat demo will be presented in the PIM WG for those who want to 
> see it.
> 
> Thanks,
> Dino
> 
>> On Oct 25, 2023, at 1:42 AM, Luigi Iannone  wrote:
>> 
>> All,
>> 
>> Hereafter the preliminary agenda for the LISP WG meeting (also available 
>> at:https://datatracker.ietf.org/meeting/118/materials/agenda-118-lisp-01)
>> 
>> Please let us know if there is anything missing or wrong.
>> 
>> Thanks
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>> Administration
>>• Padma/Luigi/Alberto
>>• Agenda Bashing
>>• Status reports for WG drafts
>>• Rechartering Status
>>• 20 Minutes (Cumulative Time: 20 Minutes)
>> WG Items
>>• LISP Reliable Transport
>>• 
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-map-server-reliable-transport/
>>• 10 Minutes (Cumulative Time: 30 Minutes)
>>• Balaji Pitta Venkatachalapathy
>> 
>> 
>>• LISP L2/L3 EID Mobility Using a Unified Control Plane
>>• https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/
>>• 10 Minutes (Cumulative Time: 40 Minutes)
>>• Marc Portoles Comeras
>> 
>> 
>> Non WG Items
>>• DEMO: P4-LISP: A P4-Based High-Performance Router for the 
>> Locator/Identifier Separation Protocol
>>• https://atlas.cs.uni-tuebingen.de/~menth/papers/Menth23c.pdf
>>• 10 Minutes (Cumulative Time: 50 Minutes)
>>• Michael Menth
>> 
>> 
>>• DEMO: gaapchat IPv6 multicast app over LISP over Starlink
>>• https://datatracker.ietf.org/doc/draft-farinacci-pim-gaap/
>>• 10 Minutes (Cumulative Time: 60 Minutes)
>>• Dino Farinacci
>> 
>> 
>>• Discussion 
>>• 0 Minutes (Cumulative Time: 60 Minutes)
>> 
>> ___
>> 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] My comments to latest updates to LISP charter

[Luigi Iannone]

Hi Dino,

I agree with you that NAT by July 2024 is optimistic and we can postpone it to 
November.

Concerning Geo, I understand that from your perspective the work is done, 
however, if we put it on March 2024 then we have 4 docs to work on.
I prefer to spread a bit so to smooth the workload (for shepherd+AD).

Have a a suggestion how to do it? 

Ciao

L.
 

> On Oct 24, 2023, at 23:54, Dino Farinacci  wrote:
> 
> 
> 
> Geo and NAT are completely at opposite ends of the spectrum when it comes to 
> readiness. Geo is ready, has been ready and reflected comments from 
> previous-AD Alvaro. It has just been sitting around. It should be at least in 
> March 2024, if not now in Nov 2023. NAT will at least have to go out until 
> Nov 2024, noting that many of the authors are no longer engaged with LISP.
> 
> 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] LISP WG Agenda

[Luigi Iannone]

All,

Hereafter the preliminary agenda for the LISP WG meeting (also available 
at:https://datatracker.ietf.org/meeting/118/materials/agenda-118-lisp-01)

Please let us know if there is anything missing or wrong.

Thanks

Ciao

L.


Administration
Padma/Luigi/Alberto
Agenda Bashing
Status reports for WG drafts
Rechartering Status
20 Minutes (Cumulative Time: 20 Minutes)
WG Items
LISP Reliable Transport

https://datatracker.ietf.org/doc/draft-ietf-lisp-map-server-reliable-transport/
10 Minutes (Cumulative Time: 30 Minutes)
Balaji Pitta Venkatachalapathy


LISP L2/L3 EID Mobility Using a Unified Control Plane

https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/
10 Minutes (Cumulative Time: 40 Minutes)
Marc Portoles Comeras


Non WG Items
DEMO: P4-LISP: A P4-Based High-Performance Router for the Locator/Identifier 
Separation Protocol

https://atlas.cs.uni-tuebingen.de/~menth/papers/Menth23c.pdf
10 Minutes (Cumulative Time: 50 Minutes)
Michael Menth


DEMO: gaapchat IPv6 multicast app over LISP over Starlink

https://datatracker.ietf.org/doc/draft-farinacci-pim-gaap/
10 Minutes (Cumulative Time: 60 Minutes)
Dino Farinacci


Discussion 

0 Minutes (Cumulative Time: 60 Minutes)___
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]

[Luigi Iannone]

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 before the 
schedule this is a plus not a problem.

Since Nov 2023 is in 2 weeks I agree with Padma that there is no need to rush.

The name encoding document was indeed missing, since it is a simple document we 
can publish it by March 2024.

The update list looks like:

1. November 2023: Submit a LISP Yang model document to the IESG for 
consideration
2. March 2024: Submit LISP Traffic Engineering document to the IESG for 
consideration
3. March 2024: Submit LISP Reliable Transport document to the IESG for 
consideration
4. March 2024: Submit LISP Name Encoding document to the IESG for consideration
5. June 2024 : Submit LISP geo-coordinates to the IESG for consideration
6. June 2024: Submit a LISP NAT Traversal document to the IESG for consideration
7. November 2024: Submit 8111bis to the IESG for consideration
8. November 2024: Submit merged LCAFbis document to the IESG for consideration
9. March 2025: Submit LISP Privacy and Security documents to the IESG for 
consideration
10. March 2025: Submit 6832bis Proxy XTRs document to the IESG for consideration
11. June 2025: Submit LISP Mobile documents to the IESG for consideration
12. November 2025: Submit Multicast documents to the IESG for consideration
13. March 2026: Submit LISP Applicability document to the IESG for consideration
14. November 2026: Wrap-Up or recharter 
 

Better?

L.


> On Oct 17, 2023, at 01:46, Padma Pillay-Esnault  wrote:
> 
> Hi Dino 
> 
> The groupings look good!
> 
> Some dates look too aggressive Nov 2023:  draft-ietf-lisp-geo, 
> draft-ietf-lisp-name-encoding, RFC 8060 and 9306 (Standards Track). We are 
> already there ...
> As the dates proposed are target dates, i suggest we keep the date of June 
> 2024 but if we can go faster it is all good. thoughts?
> 
> Similar comment for mobility. 
> 
> Thanks
> Padma
> 
> On Mon, Oct 16, 2023 at 4:35 PM Dino Farinacci  > wrote:
>> > What do you think of putting some major milestones for mobility and 
>> > security sections rather than per document?
>> 
>> I think security is further out compared to mobility. Just because other 
>> groups will have to peer-review the security documents. But good suggestion 
>> and will incldue below the set that go together (IMO).
>> 
>> So here is what I suggest:
>> 
>> For June 2024: Mobility documents as a set to IESG, which include:
>> 
>>   draft-ietf-lisp-eid-mobility, draft-ietf-lisp-mn, 
>> draft-ietf-lisp-predictive-rlocs, draft-ietf-lisp-vpn
>> 
>> And for June 2025: Security documents as a set to IESG, which include:
>> 
>>   draft-ietf-lisp-crypto (RFC8061 to Standards Track), 
>> draft-ietf-lisp-ecdsa-auth, draft-ietf-lisp-eid-anonymity
>> 
>> And then, not related to what you asked for, to put all LCAF related stuff 
>> in one set:
>> 
>> For Nov 2023:
>> 
>>   draft-ietf-lisp-geo, draft-ietf-lisp-name-encoding, RFC 8060 and 9306 
>> (Standards Track)
>> 
>> What do you think?
>> 
>> Dino
>> 
>> 
>> 
>> 
>> 
>> 
>> 

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

[Luigi Iannone]

Good points Padma,


What about the following ordering?

1. November 2023: Submit a LISP Yang model document to the IESG for 
consideration
2. March 2024: Submit LISP Traffic Engineering document to the IESG for 
consideration
3. March 2024: Submit LISP Reliable Transport document to the IESG for 
consideration
4. June 2024 : Submit LISP geo-coordinates for consideration
5. June 2024: Submit a LISP NAT Traversal document to the IESG for consideration
6. November 2024: Submit 8111bis to the IESG for consideration
7. November 2024: Submit merged LCAFbis document to the IESG for consideration
8. March 2025: Submit LISP Privacy and Security documents to the IESG for 
consideration
9. March 2025: Submit 6832bis Proxy XTRs document to the IESG for consideration
10. June 2025: Submit LISP Mobile Node to the IESG for consideration
11. November 2025: Submit Multicast documents to the IESG for consideration
12. March 2026: Submit LISP Applicability document to the IESG for consideration
13. November 2026: Wrap-Up or recharter 

L.

> On Oct 13, 2023, at 19:49, Padma Pillay-Esnault  wrote:
> 
> Additional comments/suggestions
> 
> Milestones 
> To be consistent, we should have at least a milestone for each of the larger 
> sections. There is a couple missing:
> - TE section - suggest March 2025
> - Privacy and Security section - suggest Nov 2025 or March 2026
> 
> Format
> To be consistent with other sections, we should have "Yang Model:" format.
> 
> Ordering 
> I would not propose to order as sections matching the milestones as sections 
> may have different documents at different maturity levels.  However this one 
> caught my attention: should we move up "NAT transversal" section  to after 
> "Yang Model:" as it is in March 2024.
> 
> Thanks
> Padma
> 
> 
> On Fri, Oct 13, 2023 at 10:21 AM Padma Pillay-Esnault  <mailto:padma.i...@gmail.com>> wrote:
>> Hi Luigi 
>> 
>> Looks good to me 
>> nit/suggestion below see PPE 
>> 
>> Padma
>> 
>> On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone > <mailto:g...@gigix.net>> wrote:
>>> Hi,
>>> 
>>> I’ve tried to merge the list of work items in the charter in a single list 
>>> and created a PR.
>>> 
>>> 
>>> Items have been merged and re-ordered in the following way:
>>> 
>>> First the general standard track work item (multicast work merged here)
>>> 
>>> Then other work with drafts more advanced appearing earlier.
>>> 
>>> Milestone list will be updated once WG converged on this part.
>>> 
>>> 
>>> The list looks like:
>>> 
>>> Main work items are identified as follows:
>>> 
>>> Standard Track Documents: The core specifications of LISP have been 
>>> published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue 
>>> the work of moving select specifications to “Standard Track” (e.g., 
>>> [RFC8060], [RFC8111] and the set of multicast documents like [RFC6831] and 
>>> [RFC8378]).
>> PPE - Reading this the "standard track document" bullet kinda implies that 
>> the docs below are not standard track. 
>> Suggestion - "Moving to Standard tracks:"
>> 
>>  
>>> YANG models for managing the LISP protocol and deployments that include 
>>> data models, OAM, as well as allowing for programmable management 
>>> interfaces. These management methods should be considered for both the 
>>> data-plane, control plane, and mapping system components. 
>>> Map Server Reliable Transport: LISP control plane messages are transported 
>>> over UDP, however, in some cases, the use of a reliable transport protocol 
>>> is a better fit, since it actually helps reduce periodic signaling.
>>> LISP for traffic engineering: Specifics on how to do traffic engineering on 
>>> LISP deployments could be useful. For instance, encode in a mapping not 
>>> only the routing locators associated to EIDs, but also an ordered set of 
>>> re-encapsulating tunnel routers used to specify a path.
>>> 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.
>>> NAT-Traversal: Support for NAT-traversal solution in deployments where LISP 
>>> tunnel routers are separated from correspondent tunnel routers by a NAT 
>>> (e.g., LISP mobile node).
>>> Mobility: Some LISP deployment scenar

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

[Luigi Iannone]

Hi Padma,


> On Oct 13, 2023, at 19:21, Padma Pillay-Esnault  wrote:
> 
>> 
>> Main work items are identified as follows:
>> 
>> Standard Track Documents: The core specifications of LISP have been 
>> published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue 
>> the work of moving select specifications to “Standard Track” (e.g., 
>> [RFC8060], [RFC8111] and the set of multicast documents like [RFC6831] and 
>> [RFC8378]).
> PPE - Reading this the "standard track document" bullet kinda implies that 
> the docs below are not standard track. 
> Suggestion - "Moving to Standard tracks:”


Fine for me.

Ciao

L.


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

Re: [lisp] draft-ietf-lisp-yang

[Luigi Iannone]

Thanks Tom :-)

L.

> On Oct 13, 2023, at 13:56, tom petch  wrote:
> 
> Some mostly non-technical thoughts on this I-D which caught my eye
> 
> Abstract I find a bit sparse - what does the YANG module enable a user to do?
> Configure, manage, monitor, ...
> 
> I like the choice of module names and prefixes - so often these are a melange.
> 
> In the YANG module
> 
> WG Web is ood
> as are the references to lisp-lcaf-10 but I think that those should be 
> RFC or some such and not a URI
> 
> references to BSD license is ood
> 
> There is a mixture of XXX and  which I think refer to the same I-D - 
> consistency is good
> 
> I note you switched from Enumeration to Identity.  As I think you know, the 
> former have stronger change control, the latter none so a vendor can add new 
> roles.  I am not sure if this is a good idea.
> 
> You have the same string pattern five times; worth a derived type, unless you 
> think that they are going to diverge
> 
> /locartors/locators/
> 
> references in the YANG module must appear in the I-D references; I do not see
> RFC2404
> RFC4868
> lisp-lcaf which I think should be RFC or some such
> IANA address family numbers
> 
> The IP addresses use the form that includes a zone of indeterminate length; 
> is this intended?
> 
> reference clause for the revision should be to this document
> 
> IANA Considerations is double line spaced
> 
> HTH
> Tom Petch

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

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

[Luigi Iannone]

Hi,

I’ve tried to merge the list of work items in the charter in a single list and 
created a PR.


Items have been merged and re-ordered in the following way:

First the general standard track work item (multicast work merged here)

Then other work with drafts more advanced appearing earlier.

Milestone list will be updated once WG converged on this part.


The list looks like:

Main work items are identified as follows:

Standard Track Documents: The core specifications of LISP have been published 
as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of 
moving select specifications to “Standard Track” (e.g., [RFC8060], [RFC8111] 
and the set of multicast documents like [RFC6831] and [RFC8378]).

YANG models for managing the LISP protocol and deployments that include data 
models, OAM, as well as allowing for programmable management interfaces. These 
management methods should be considered for both the data-plane, control plane, 
and mapping system components.

Map Server Reliable Transport: LISP control plane messages are transported over 
UDP, however, in some cases, the use of a reliable transport protocol is a 
better fit, since it actually helps reduce periodic signaling.

LISP for traffic engineering: Specifics on how to do traffic engineering on 
LISP deployments could be useful. For instance, encode in a mapping not only 
the routing locators associated to EIDs, but also an ordered set of 
re-encapsulating tunnel routers used to specify a path.

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.

NAT-Traversal: Support for NAT-traversal solution in deployments where LISP 
tunnel routers are separated from correspondent tunnel routers by a NAT (e.g., 
LISP mobile node).

Mobility: Some LISP deployment scenarios include mobile nodes (in mobile 
environments) or Virtual Machines (VMs in data centers), hence, support needs 
to be provided in order to achieve seamless connectivity.

Privacy and Security: The WG will work on topics of EID anonymity, VPN 
segmentation leveraging on the Instance ID, and traffic anonymization. The 
reuse of existing mechanisms will be prioritized.

LISP Applicability: In time, LISP has proved to be a very flexible protocol 
that can be used in various use-cases not even considered during its design 
phase. [RFC7215], while remaining a good source of information, covers one 
single use case, which is not anymore the main LISP application scenario. The 
LISP WG will document LISP deployments for most recent and relevant use-cases 
so as to update [RFC7215].



Does it look as an acceptable trade-off among the various comments received?

Ciao

L.

> On Oct 11, 2023, at 14:33, Alberto Rodriguez-Natal (natal)  
> wrote:
> 
> Hi all,
>  
> A few thoughts on the charter after going through the latest revision and the 
> discussion on this thread.
>  
> * We have a milestone for LCAFbis, but LCAF is not mentioned in the work 
> items. Is LCAF supposed to be covered by the “Standards Track Documents” work 
> item? Same for DDT. If so, I would mention them as examples of possible 
> “Standards Track Documents”. Also, I agree with Padma that we should extend 
> the work item to include “language to cover incremental features, behaviors 
> and specifications”.
>  
> * I think the external connectivity work item could be generalized to cover 
> both the external-connectivity draft as well as any other work adjacent to 
> 6832, for instance something like:
>  
> “LISP Internetworking: [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.”
>  
> * Similar comment for TE. I think we could be more general, something like:
>  
> “Traffic Engineering and LISP: Specifics on how to do traffic engineering on 
> LISP deployments could be useful, for instance some use cases…”
>  
> * On the milestones section, I think LCAFbis could be done much sooner. Also, 
> I agree with Dino we should have name-encoding sooner as well (this is partly 
> my fault, I’m halfway on my shepherds writeup, will try to close on that).
>  
> * Based on the discussion on San Francisco, it is not entirely clear to me 
> the consensus of the WG regarding “Submitting a LISP Applicability document 
> to the IESG”. Would it be possible to leave this milestone somehow more open?
>  
>  
> I’m also planning to send a PR on GitHub with some editorial comments.
>  
> Thanks,
> 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 hav

Re: [lisp] Proposed WG Charter on GitHub

[Luigi Iannone]

Hi Alberto,

> On Oct 11, 2023, at 14:33, Alberto Rodriguez-Natal (natal)  
> wrote:
> 
> Hi all,
>  
> A few thoughts on the charter after going through the latest revision and the 
> discussion on this thread.
>  
> * We have a milestone for LCAFbis, but LCAF is not mentioned in the work 
> items. Is LCAF supposed to be covered by the “Standards Track Documents” work 
> item? Same for DDT. If so, I would mention them as examples of possible 
> “Standards Track Documents”. Also, I agree with Padma that we should extend 
> the work item to include “language to cover incremental features, behaviors 
> and specifications”.
>  

The idea was not to list all candidates, but you are right that if we have them 
in the milestones….


> * I think the external connectivity work item could be generalized to cover 
> both the external-connectivity draft as well as any other work adjacent to 
> 6832, for instance something like:
>  
> “LISP Internetworking: [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.”

Ack


>  
> * Similar comment for TE. I think we could be more general, something like:
>  
> “Traffic Engineering and LISP: Specifics on how to do traffic engineering on 
> LISP deployments could be useful, for instance some use cases…”

Ack


>  
> * On the milestones section, I think LCAFbis could be done much sooner. Also, 
> I agree with Dino we should have name-encoding sooner as well (this is partly 
> my fault, I’m halfway on my shepherds writeup, will try to close on that).

If we finish something sooner than expected there is no harm. 


>  
> * Based on the discussion on San Francisco, it is not entirely clear to me 
> the consensus of the WG regarding “Submitting a LISP Applicability document 
> to the IESG”. Would it be possible to leave this milestone somehow more open?

What do you mean exactly by “more open”?


Ciao

L.


>  
>  
> I’m also planning to send a PR on GitHub with some editorial comments.
>  
> Thanks,
> 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] Call for LISP WG agenda items

[Luigi Iannone]

Noted. Thanks Dino

Ciao

L.

> On Oct 10, 2023, at 21:03, Dino Farinacci  wrote:
> 
>> If you want to present during our meeting please send an email to the chairs 
>> at latest by Monday October 23.
> 
> I am planning a demo for the PIM WG. I could present that demo in the LISP 
> WG. The title is:
> 
> "gaapchat IPv6 multicast app over LISP over Starlink"
> 
> I would only need 15 minutes.
> 
> Dino
> 
> 
> 

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

[lisp] Confirm WG adoption for document draft-jain-lisp-site-external-connectivity

[Luigi Iannone]

All,

During the last LISP WG meeting  the authors of the draft:

LISP Site External Connectivity
https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/

Asked for adoption as WG document.
Call for adoption during the meeting showed clear consensus (see: 
https://datatracker.ietf.org/doc/minutes-117-lisp/)
This email is the usual procedure to confirm the consensus on the mailing list.

If anybody has concerns about adopting this document please state so on the 
mailing list before October 26, 2023
Please also argument the technical reason why you have concerns.

Ciao

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

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

[Luigi Iannone]

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

[Luigi Iannone]

Hi,

I think so. The best option is to list them in the same order as the milestones.

I will try to propose a new order today/tomorrow

CIao





> On Oct 11, 2023, at 13:26, Alberto Rodriguez-Natal (natal)  
> wrote:
> 
> Padma,
>  
> Just to confirm, is the end goal to have a single list of items then? (that 
> is, not divided into two groups)
>  
> Thanks,
> Alberto
>  
> From: Padma Pillay-Esnault  >
> Date: Friday, October 6, 2023 at 4:14 AM
> To: Alvaro Retana mailto:aretana.i...@gmail.com>>
> Cc: LISP mailing list list mailto:lisp@ietf.org>>, 
> lisp-cha...@ietf.org   >
> Subject: Re: [lisp] Proposed WG Charter on GitHub
> 
> On Tue, Oct 3, 2023 at 5:14 PM Alvaro Retana  > wrote:
>  
> (1) What’s the difference between the work items in “Part 1” and the ones in 
> “Part 2”?
>  
> PPE - originally we had in part 1 work that were promised and part 2 grouping 
> work in progress. Will fix the document and remove the "part" for clarity.

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

Re: [lisp] I-D Action: draft-ietf-lisp-yang-20.txt

[Luigi Iannone]

Thanks Alberto,

Do you prefer to try fixing Med’s comments before contacting the YANG doctors? 
Or can I go ahead and reach out for them?

Ciao

L.

> On Oct 10, 2023, at 21:28, Alberto Rodriguez-Natal (natal) 
>  wrote:
> 
> This is just a refresh to keep the document alive. The comments from Med are 
> yet to be addressed (hope to get to that soon). Some comments might require 
> input from a YANG doctor as discussed in San Francisco.
>  
> Thanks,
> Alberto
>  
> From: lisp  on behalf of internet-dra...@ietf.org 
> 
> Date: Tuesday, October 10, 2023 at 9:26 PM
> To: i-d-annou...@ietf.org 
> Cc: lisp@ietf.org 
> Subject: [lisp] I-D Action: draft-ietf-lisp-yang-20.txt
> 
> Internet-Draft draft-ietf-lisp-yang-20.txt is now available. It is a work item
> of the Locator/ID Separation Protocol (LISP) WG of the IETF.
> 
>Title:   LISP YANG Model
>Authors: Vina Ermagan
> Alberto Rodriguez-Natal
> Florin Coras
> Carl Moberg
> Reshad Rahman
> Albert Cabellos-Aparicio
> Fabio Maino
>Name:draft-ietf-lisp-yang-20.txt
>Pages:   82
>Dates:   2023-10-10
> 
> Abstract:
> 
>This document describes a YANG data model to use with the Locator/ID
>Separation Protocol (LISP).
> 
>The YANG modules in this document conform to the Network Management
>Datastore Architecture (NMDA).
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-yang-20
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-yang-20
> 
> Internet-Drafts are also available by rsync at:
> rsync.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 mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Luigi Iannone]

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)  >
> 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 mailto:lisp@ietf.org>>
> 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] Proposed WG Charter on GitHub

[Luigi Iannone]

Hi Dino,

My comments inline.

> On Oct 9, 2023, at 22:41, Dino Farinacci  wrote:
> 
>> Hi Dino,
>> 
>> A few comments inline
>> 
>>> On Oct 7, 2023, at 00:54, Dino Farinacci  wrote:
>>> 
>>> Here are my comments. The charter text comes first and is indented and my 
>>> comments follow:
>>> 
 LISP Working Group Charter ProposalProposed Charter: Introduction
 LISP supports a routing architecture which decouples the routing locators 
 and identifiers, thus allowing for efficient
>>> 
>>> "... supports an overlay routing …"
>> 
>> Is it really necessary?
> 
> Well I think so since we changed the solution space of LISP from "saving the 
> routing tables" to a more general overlay solution.

Added in the PL just submitted.

> 
>> 
 aggregation of the routing locator space and providing persistent 
 identifiers in the identifier space. LISP requires no changes to 
 end-systems or to routers that do not directly participate in the LISP 
 deployment. LISP aims for an incrementally deployable protocol, so new 
 features and services can be added easily and quickly to the network using 
 overlays. The scope of the LISP technology is potentially applicable to 
 have a large span.The LISP WG is chartered to continue work on the LISP 
 protocol and produce standard-track documents.
>>> 
>>> I would add some of the more explicit features that overlay routing can do 
>>> and how LISP actually has done so and specified at a very detailed level. 
>>> Some examples are mobility, VPNs, multicast, mix protocol family, all with 
>>> the latest in security mechanisms.
>> 
>> We are not promoting LISP here, we are listing the work items. Let’s keep it 
>> simple and to the point.
> 
> That is okay, but you did give some basic features as you describe "how it 
> works".

We do not need to be exhaustive here ;-)

> 
>> 
>>> 
 Proposed Charter: Work Items Part 1
  • NAT-Traversal: Support for NAT-traversal solution in deployments where 
 LISP tunnel routers are separated from correspondent tunnel routers by a 
 NAT (e.g., LISP mobile node).
  • YANG models for managing the LISP protocol and deployments that include 
 data models, OAM, as well as allowing for programmable management 
 interfaces. These management methods should be considered for both the 
 data-plane, control plane, and mapping system components.
  • Multicast Support: LISP support for multicast environments has a 
 growing number of use cases. Support for multicast is needed in order to 
 achieve scalability. The current documents [Ref to experimental multicast 
 RFCs] should be merged and published as Standard Track.
>>> 
>>> I think the smaller work items that we can knock out should be in Part 1 
>>> like geo-coordinates and name-encoding.
>> 
>> Geo coordinates is part of the mobility bullet point.
> 
> Right, that is misplaced IMO. GPS can be used for mobility but none of the 
> mobility drafts that state mechanisms refer to it. Like VPNs and TE, GPS is 
> its own category.

I agree with the point made by Padma in her reply; putting geo coordinates in 
the mobility group does not limit its application to mobility.

Ciao

L.


> 
>> 
>>> And there is no mention of VPN and TE support. It needs to go in somewhere.
>> 
>> VPN is later on. TE is indeed missing, we need to include it somewhere.
> 
> Ack.
> 
>> 
>>> 
 Proposed Charter: Work Items Part 2
  • Standard Track Documents: The core specifications of LISP have been 
 published as “Standard Track” [references]. The WG will continue the work 
 of moving select specifications to “Standard Track”.
  • Mobility: Some LISP deployment scenarios include mobile nodes (in 
 mobile environments) or Virtual Machines (VMs in data centers), hence, 
 support needs to be provided in order to achieve seamless connectivity.
  • Privacy and Security: The WG will work on topics of EID anonymity, VPN 
 segmentation leveraging on the Instance ID, and traffic anonymization. The 
 reuse of existing mechanisms will be prioritized.
>>> 
>>> I would not call VPN segmentation as security. I view it more as 
>>> topological member grouping.
>> 
>> Which is also used for security purposes.
>>> 
> 
> Right but goes beyond it.

And like for the geo coordinates and TE you can use it beyond that scope.


> 
  • LISP Applicability: In time, LISP has proved to be a very flexible 
 protocol that can be used in various use-cases not even considered during 
 its design phase. RFC 7215, while remaining a good source of information, 
 covers one single use case, which is not anymore the main LISP application 
 scenario. The LISP WG will document LISP deployments for most recent and 
 relevant use-cases so as to update RFC 7215.
 Proposed Charter: Tentative Milestones
  • November 2023: Submit a LISP YANG document to the IESG for consideration
  • March 2024: Submit a LISP NAT Travers

[lisp] Call for LISP WG agenda items

[Luigi Iannone]

Hi All,

According to the preliminary agenda of IETF 118 
(https://datatracker.ietf.org/meeting/118/agenda) the LISP WG will meet in the 
last session of Monday November 6.

While the IETF agenda may still change, is not unreasonable to start build the 
LISP WG agenda.

If you want to present during our meeting please send an email to the chairs at 
latest by Monday October 23.

Thanks

Luigi, Padma, Alberto


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

Re: [lisp] Proposed WG Charter on GitHub

[Luigi Iannone]

Hi Dino,

A few comments inline

> On Oct 7, 2023, at 00:54, Dino Farinacci  wrote:
> 
> Here are my comments. The charter text comes first and is indented and my 
> comments follow:
> 
>> LISP Working Group Charter ProposalProposed Charter: Introduction
>> LISP supports a routing architecture which decouples the routing locators 
>> and identifiers, thus allowing for efficient
> 
> "... supports an overlay routing …"

Is it really necessary?

> 
>> aggregation of the routing locator space and providing persistent 
>> identifiers in the identifier space. LISP requires no changes to end-systems 
>> or to routers that do not directly participate in the LISP deployment. LISP 
>> aims for an incrementally deployable protocol, so new features and services 
>> can be added easily and quickly to the network using overlays. The scope of 
>> the LISP technology is potentially applicable to have a large span.The LISP 
>> WG is chartered to continue work on the LISP protocol and produce 
>> standard-track documents.
> 
> I would add some of the more explicit features that overlay routing can do 
> and how LISP actually has done so and specified at a very detailed level. 
> Some examples are mobility, VPNs, multicast, mix protocol family, all with 
> the latest in security mechanisms.

We are not promoting LISP here, we are listing the work items. Let’s keep it 
simple and to the point.

> 
>> Proposed Charter: Work Items Part 1
>>• NAT-Traversal: Support for NAT-traversal solution in deployments where 
>> LISP tunnel routers are separated from correspondent tunnel routers by a NAT 
>> (e.g., LISP mobile node).
>>• YANG models for managing the LISP protocol and deployments that include 
>> data models, OAM, as well as allowing for programmable management 
>> interfaces. These management methods should be considered for both the 
>> data-plane, control plane, and mapping system components.
>>• Multicast Support: LISP support for multicast environments has a 
>> growing number of use cases. Support for multicast is needed in order to 
>> achieve scalability. The current documents [Ref to experimental multicast 
>> RFCs] should be merged and published as Standard Track.
> 
> I think the smaller work items that we can knock out should be in Part 1 like 
> geo-coordinates and name-encoding.

Geo coordinates is part of the mobility bullet point.

> And there is no mention of VPN and TE support. It needs to go in somewhere.

VPN is later on. TE is indeed missing, we need to include it somewhere. 

> 
>> Proposed Charter: Work Items Part 2
>>• Standard Track Documents: The core specifications of LISP have been 
>> published as “Standard Track” [references]. The WG will continue the work of 
>> moving select specifications to “Standard Track”.
>>• Mobility: Some LISP deployment scenarios include mobile nodes (in 
>> mobile environments) or Virtual Machines (VMs in data centers), hence, 
>> support needs to be provided in order to achieve seamless connectivity.
>>• Privacy and Security: The WG will work on topics of EID anonymity, VPN 
>> segmentation leveraging on the Instance ID, and traffic anonymization. The 
>> reuse of existing mechanisms will be prioritized.
> 
> I would not call VPN segmentation as security. I view it more as topological 
> member grouping.

Which is also used for security purposes. 
> 
>>• LISP Applicability: In time, LISP has proved to be a very flexible 
>> protocol that can be used in various use-cases not even considered during 
>> its design phase. RFC 7215, while remaining a good source of information, 
>> covers one single use case, which is not anymore the main LISP application 
>> scenario. The LISP WG will document LISP deployments for most recent and 
>> relevant use-cases so as to update RFC 7215.
>> Proposed Charter: Tentative Milestones
>>• November 2023: Submit a LISP YANG document to the IESG for consideration
>>• March 2024: Submit a LISP NAT Traversal document to the IESG for 
>> consideration
>>• June 2024: Submit 8111bis to the IESG for consideration
>>• June 2024 : Submit LISP geo-coordinates for consideration
> 
> This, with name-encoding, can get done sooner. We just have to push harder.
> 
>>• November 2024: Submit merged Multicast document to the IESG for 
>> consideration
> 
> Note, from the previous email you referred to "underlay-multicast-trees". 
> That document has changed its name to reflect what it really is designing, 
> its titled draft-vdas-lisp-group-mapping-00.

As for previous comments we better avoid “merged”, may be just use “multicast 
documentS”.

> 
>>• March 2025: Submit 6832bis pXTRs to the IESG for consideration
>>• June 2025: Submit merged LCAFbis to the IESG for considerations
>>• November 2025: Submit LISP Mobile Node to the IESG for considerations
>>• March 2026: Submit LISP Applicability document to the IESG for 
>> considerations
>>• November 2026: Wrap-Up or recharter
> 
> There sho

Re: [lisp] Move RFC7954 and RFC7955 to HISTORIC

[Luigi Iannone]

Hi All,

This call is now over an no objections have been raised.

We will continue the process to move these documents to historic status.

Ciao

L.

> On 13 Jul 2023, at 15:28, Luigi Iannone  wrote:
> 
> Hi all,
> 
> During the last F2F meeting in Yokohama we mentioned RFCs 7954 and 7955 to be 
> moved to HISTORIC status.
> 
> Just for refresher those documents are about a prefix specifically reserved 
> for EID allocation (hence non-routable).
> The allocation was experimental and temporary and it did never fly.
> 
> Back in 2019 we already discussed this (see below).
> 
> It seems appropriate to have again a last call on this matter to make sure 
> that nobody changed his mind.
> 
> As such this email starts a 4 weeks last call to move these two documents to 
> HISTORIC status.
> The text explaining the rational can be found below.
> 
> Please reply if you have any objection (and articulate the reasons for your 
> objection).
> 
> This call ends on  10 August 2023.
> 
> Ciao
> 
> Luigi
> 
>> On 20 Nov 2019, at 03:43, Luigi Iannone  wrote:
>> 
>> Folks,
>> 
>> as discussed yesterday during the f2f meeting, we plan to move RFC7954 and 
>> RFC7955 to HISTORIC state.
>> 
>> Rationale is described in the text provide below. This text will be 
>> associated to the documents so to keep track of the LISP EID prefix 
>> experiment.
>> 
>> Please let us know if you have any comment.
>> 
>> We plan to move forward in one week time.
>> 
>> Thanks
>> 
>> Ciao
>> 
>> L.
>>  
>> 
>> 
>> 
>> 
>> —— PROPOSED TEXT———
>> 
>> RFC 7954 created an experimental IPv6 prefix, namely 2001:5::/32, to be used 
>> as Endpoint-IDentifier (EID) space for the Locator/Identifier Separation 
>> Protocol (LISP).  The reserved address space was requested for an initial 
>> 3-year period
>> starting in September 2016 (until September 2019), with an option to extend 
>> it by three years (until September 2022) upon the decision of the IETF.
>> RFC 7955 describes a framework for the management of the prefix crested by 
>> RFC 7954. As described in RFC 7955, RIPE NCC volunteered to provide 
>> registration service during the experiment (up to 2022 at latest).
>> 
>> The initial experiment was supposed to last three years, until September 
>> 2019.
>> The option to extend the experiment to three more years was subject to the 
>> requirements written in section 10 of RFC 7954:
>> 
>>  Following the policies outlined in
>>   [RFC5226], upon IETF Review, the decision should be made on whether
>>   to have a permanent EID block assignment by September 2019.  If no
>>   explicit action is taken or, if the IETF Review outcome is that it is
>>   not worth having a reserved prefix as a global EID space, the whole
>>   /32 will be taken out from the "IANA IPv6 Special-Purpose Address
>>   Registry" and put back in the free pool managed by IANA.
>> 
>> In August 2019 RIPE NCC contacted the LISP WG asking if any action was 
>> ongoing concerning the extension of the experiment. The LISP WG concluded 
>> that very few requests have been made during three years and there was no 
>> compelling reason to extent the experiment. No further action has been taken 
>> by the LISP WG or the IETF. As such, in accordance with Section 10 of RFC 
>> 7954, RIPE NCC de-registered the existing assignments and IANA put the 
>> prefix back in the free pool (removing the entry from 
>> https://www.iana.org/assignments/iana-ipv6-special-registry).
>> 
>> At this point, RFC 7954 and RFC 7955 refer to a prefix that does not exists 
>> anymore. As such it make sense to move both documents to the status of 
>> "HISTORIC". This note, associated with the status change of the two RFCs 
>> will allow to keep track of the LISP EID prefix experiment.
> 

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

[lisp] FW: Info for ROSA side meeting at IETF117

[Luigi IANNONE]

HI,

At some point there was LISP draft for service routing, so the following side 
meeting might be of some interest for people here.

Ciao

L.

From: Rosa  On Behalf Of Dirk Trossen
Sent: Wednesday, 19 July 2023 15:11
To: r...@ietf.org
Subject: [Rosa] Info for ROSA side meeting at IETF117

Dear all,

We have updated the IETF117 side meeting wiki with the admin information for 
the side meeting.

You can find the agenda as well as the conference link for remote participation 
at https://github.com/dirk-trossen-huawei/IETF117_ROSA

We will also upload the slide material on Monday for previewing, if wanted.

Luigi Iannone has agreed to moderate the side meeting (many thanks), starting 
at 6.30pm on 24th in the Continental 2-3 side meeting room.

We hope to see many of you there, either in person or remotely. Please do study 
the drafts for preparation and comments/input from your side (you can find the 
drafts on github, in addition to datatracker).

Best,


Dirk (on behalf of the draft authors)
-- 
Rosa mailing list
r...@ietf.org
https://www.ietf.org/mailman/listinfo/rosa
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] LISP WG Agenda

[Luigi Iannone]

Hi All,

The LISP WG agenda looks as at the bottom of this mail.

If we missed something or you have any comment on it please let us know.

Ciao

Luigi & Padma

CHAIR(s):

Padma Pillay-Esnault ( padma.ietf AT gmail.com <https://gmail.com/> )
Luigi Iannone ( ggx AT gigix.net <http://gigix.net/> )
SECRETARY: Alberto Rodriguez-Natal ( natal AT cisco.com <http://cisco.com/> )

AGENDA

Session 1/1 (60 Minutes)

Monday, July 24, 2023

17:30 - 18:30 San Francisco (GMT-7), Session IV, 60 Minutes
02:00 -> 03:30 CEST (Paris time NOTE this is July 25 very early morning)
20:30 -> 21:30 EDT (New York time)
00:30 -> 01:30 UTC (NOTE this is July 25 very early morning)
08:30 -> 09:30 CST (Beijing time NOTE this is July 25 morning)
10:30 -> 11:30 AEST (Sydney time NOTE this is July 25 morning)
Room: Golden Gate 7-8 
https://datatracker.ietf.org/meeting/117/floor-plan?room=golden-gate-7-8

Administration

Padma/Luigi/Alberto
Agenda Bashing
Status reports for WG drafts
5 Minutes (Cumulative Time: 5 Minutes)
Non WG Items

LISP Site External Connectivity

https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/
15 Minutes (Cumulative Time: 20 Minutes)
Prakash Jain


LISP for Satellite Networks

https://datatracker.ietf.org/doc/draft-farinacci-lisp-satellite-network/
15 Minutes (Cumulative Time: 35 Minutes)
Dino Farinacci


Discussion Rechartering

25 Minutes (Cumulative Time: 60 Minutes)
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Move RFC7954 and RFC7955 to HISTORIC

[Luigi Iannone]

Hi all,

During the last F2F meeting in Yokohama we mentioned RFCs 7954 and 7955 to be 
moved to HISTORIC status.

Just for refresher those documents are about a prefix specifically reserved for 
EID allocation (hence non-routable).
The allocation was experimental and temporary and it did never fly.

Back in 2019 we already discussed this (see below).

It seems appropriate to have again a last call on this matter to make sure that 
nobody changed his mind.

As such this email starts a 4 weeks last call to move these two documents to 
HISTORIC status.
The text explaining the rational can be found below.

Please reply if you have any objection (and articulate the reasons for your 
objection).

This call ends on  10 August 2023.

Ciao

Luigi

> On 20 Nov 2019, at 03:43, Luigi Iannone  wrote:
> 
> Folks,
> 
> as discussed yesterday during the f2f meeting, we plan to move RFC7954 and 
> RFC7955 to HISTORIC state.
> 
> Rationale is described in the text provide below. This text will be 
> associated to the documents so to keep track of the LISP EID prefix 
> experiment.
> 
> Please let us know if you have any comment.
> 
> We plan to move forward in one week time.
> 
> Thanks
> 
> Ciao
> 
> L.
>  
> 
> 
> 
> 
> —— PROPOSED TEXT———
> 
> RFC 7954 created an experimental IPv6 prefix, namely 2001:5::/32, to be used 
> as Endpoint-IDentifier (EID) space for the Locator/Identifier Separation 
> Protocol (LISP).  The reserved address space was requested for an initial 
> 3-year period
> starting in September 2016 (until September 2019), with an option to extend 
> it by three years (until September 2022) upon the decision of the IETF.
> RFC 7955 describes a framework for the management of the prefix crested by 
> RFC 7954. As described in RFC 7955, RIPE NCC volunteered to provide 
> registration service during the experiment (up to 2022 at latest).
> 
> The initial experiment was supposed to last three years, until September 2019.
> The option to extend the experiment to three more years was subject to the 
> requirements written in section 10 of RFC 7954:
> 
>  Following the policies outlined in
>   [RFC5226], upon IETF Review, the decision should be made on whether
>   to have a permanent EID block assignment by September 2019.  If no
>   explicit action is taken or, if the IETF Review outcome is that it is
>   not worth having a reserved prefix as a global EID space, the whole
>   /32 will be taken out from the "IANA IPv6 Special-Purpose Address
>   Registry" and put back in the free pool managed by IANA.
> 
> In August 2019 RIPE NCC contacted the LISP WG asking if any action was 
> ongoing concerning the extension of the experiment. The LISP WG concluded 
> that very few requests have been made during three years and there was no 
> compelling reason to extent the experiment. No further action has been taken 
> by the LISP WG or the IETF. As such, in accordance with Section 10 of RFC 
> 7954, RIPE NCC de-registered the existing assignments and IANA put the prefix 
> back in the free pool (removing the entry from 
> https://www.iana.org/assignments/iana-ipv6-special-registry).
> 
> At this point, RFC 7954 and RFC 7955 refer to a prefix that does not exists 
> anymore. As such it make sense to move both documents to the status of 
> "HISTORIC". This note, associated with the status change of the two RFCs will 
> allow to keep track of the LISP EID prefix experiment.

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

Re: [lisp] IETF 117 Preliminary Agenda: Call for agenda items

[Luigi Iannone]

Noted!

Ciao

L.

> On 1 Jul 2023, at 20:40, Dino Farinacci  wrote:
> 
> I would like a 15 minute slot to present "LISP Multicast over Starlink" 
> progress. It includes running a new group allocation protocol (GAAP) on top 
> of the overlay too.
> 
> Thanks,
> Dino
> 
>> On Jun 26, 2023, at 12:33 PM, Luigi Iannone  wrote:
>> 
>> Hi All,
>> 
>> The LISP WG has been scheduled for Monday 24th July. 
>> 
>> Please send an email to the chairs if you want a presentation slot.
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>> P.S. Note that this is the preliminary agenda and subject to changes.
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: IETF Agenda 
>>> Subject: IETF 117 Preliminary Agenda
>>> Date: 23 June 2023 at 23:36:36 CEST
>>> To: "IETF Announcement List" 
>>> Cc: i...@ietf.org, 117...@ietf.org
>>> Reply-To: supp...@ietf.org
>>> 
>>> IETF 117
>>> San Francisco, CA, USA
>>> July 22-28, 2023
>>> Hosted By: NOKIA
>>> 
>>> 
>>> The IETF 117 Preliminary Agenda has been posted. The final agenda will be 
>>> published on Friday, June 30, 2023.
>>> 
>>> https://datatracker.ietf.org/meeting/117/agenda.html 
>>> https://datatracker.ietf.org/meeting/117/agenda.txt 
>>> 
>>> The preliminary agenda includes all planned WG, RG, and BoF sessions. 
>>> Information about side meetings will be available when the final agenda is 
>>> posted. 
>>> 
>>> IETF 117 Information: https://www.ietf.org/how/meetings/117/ 
>>> Register online at: https://registration.ietf.org/117/ 
>>> 
>>> Don’t forget to register for these exciting IETF 117 events!
>>> 
>>> 
>>> Social Event
>>> 
>>> The San Francisco Museum of Modern Art is an internationally recognized 
>>> collection of modern and contemporary art. This collection includes 
>>> masterworks and experimental pieces from SFMOMA’s collection of painting 
>>> and sculpture.
>>> 
>>> There will be a wide array of food and beverages to suit all tastes and 
>>> will include vegetarian and vegan options. Transportation will not be 
>>> provided as the venue is a short 15 minute walk from the headquarter hotel 
>>> (Hilton Union Square). 
>>> 
>>> - Date: Tuesday, July 25
>>> - Start/End Times: 19:00 – 22:30 (Galleries close at 22:00)
>>> - Cost per ticket: $30 per ticket, limit of two tickets per attendee.
>>> - Children under 12 allowed for free
>>> 
>>> More information:
>>> https://www.ietf.org/how/meetings/117/social/ 
>>> 
>>> 
>>> Hackathon 
>>> 
>>> Onsite signup: https://registration.ietf.org/117/new/hackathon_onsite/ 
>>> Remote signup: https://registration.ietf.org/117/new/hackathon_remote/ 
>>> More information: 
>>> https://www.ietf.org/how/runningcode/hackathons/117-hackathon/ 
>>> Keep up to date by subscribing to: 
>>> https://www.ietf.org/mailman/listinfo/hackathon 
>>> 
>>> 
>>> Code Sprint
>>> 
>>> More information and signups: https://notes.ietf.org/notes-ietf-117-tools#
>>> 
>>> ___
>>> IETF-Announce mailing list
>>> ietf-annou...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 

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

[lisp] IETF 117 Preliminary Agenda: Call for agenda items

[Luigi Iannone]

Hi All,

The LISP WG has been scheduled for Monday 24th July. 

Please send an email to the chairs if you want a presentation slot.

Ciao

L.


P.S. Note that this is the preliminary agenda and subject to changes.


> Begin forwarded message:
> 
> From: IETF Agenda 
> Subject: IETF 117 Preliminary Agenda
> Date: 23 June 2023 at 23:36:36 CEST
> To: "IETF Announcement List" 
> Cc: i...@ietf.org, 117...@ietf.org
> Reply-To: supp...@ietf.org
> 
> IETF 117
> San Francisco, CA, USA
> July 22-28, 2023
> Hosted By: NOKIA
> 
> 
> The IETF 117 Preliminary Agenda has been posted. The final agenda will be 
> published on Friday, June 30, 2023.
> 
> https://datatracker.ietf.org/meeting/117/agenda.html 
> https://datatracker.ietf.org/meeting/117/agenda.txt 
> 
> The preliminary agenda includes all planned WG, RG, and BoF sessions. 
> Information about side meetings will be available when the final agenda is 
> posted. 
> 
> IETF 117 Information: https://www.ietf.org/how/meetings/117/ 
> Register online at: https://registration.ietf.org/117/ 
> 
> Don’t forget to register for these exciting IETF 117 events!
> 
> 
> Social Event
> 
> The San Francisco Museum of Modern Art is an internationally recognized 
> collection of modern and contemporary art. This collection includes 
> masterworks and experimental pieces from SFMOMA’s collection of painting and 
> sculpture.
> 
> There will be a wide array of food and beverages to suit all tastes and will 
> include vegetarian and vegan options. Transportation will not be provided as 
> the venue is a short 15 minute walk from the headquarter hotel (Hilton Union 
> Square). 
> 
> - Date: Tuesday, July 25
> - Start/End Times: 19:00 – 22:30 (Galleries close at 22:00)
> - Cost per ticket: $30 per ticket, limit of two tickets per attendee.
> - Children under 12 allowed for free
> 
> More information:
> https://www.ietf.org/how/meetings/117/social/ 
> 
> 
> Hackathon 
> 
> Onsite signup: https://registration.ietf.org/117/new/hackathon_onsite/ 
> Remote signup: https://registration.ietf.org/117/new/hackathon_remote/
> More information: 
> https://www.ietf.org/how/runningcode/hackathons/117-hackathon/ 
> Keep up to date by subscribing to: 
> https://www.ietf.org/mailman/listinfo/hackathon 
> 
> 
> Code Sprint
> 
> More information and signups: https://notes.ietf.org/notes-ietf-117-tools#
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

[lisp] Fwd: NomCom 2023 Call for Volunteers

[Luigi Iannone]

> Begin forwarded message:
> 
> From: NomCom Chair 2023 
> Subject: NomCom 2023 Call for Volunteers
> Date: 6 June 2023 at 01:50:08 CEST
> To: "IETF Announcement List" 
> Reply-To: nomcom-chair-2...@ietf.org
> 
> The IETF Nominating Committee (NomCom) appoints people to fill the open slots 
> on the IETF LLC, IETF Trust, the IAB, and the IESG.  Ten voting members for 
> the NomCom are selected from a pool of volunteers.  A large pool of 
> volunteers helps make the process work better.
> 
> CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer
> 
> NomCom activity is expected to start in July and run through to November.  
> The goal is to do the bulk of the work at IETF 117 and 118, with supplemental 
> conference calls between those times.  Remote participation will be supported.
> 
> The NomCom activities involve collecting requirements from the community, 
> reviewing candidate responses, reviewing feedback from community members 
> about candidates, interviewing candidates, and nominating a slate of 
> candidates.
> 
> RFC 8713 details the NomCom process.  With the recent publication of RFC 
> 9389, this is the first year of new qualification criteria, after a few years 
> of trials.  People qualify for NomCom participation in one of three ways: 
> attendance at IETF meetings (online or virtual), service as a working group 
> chair or secretary, or publication of IETF RFCs.
> 
> https://datatracker.ietf.org/accounts/profile/ lists your eligibility, but 
> you can still volunteer even if that says "No".  You can also volunteer by 
> sending me an email.
> 
> Within the next week or two, I will add more details on the timeline and the 
> selection process.
> 
> Thank you!
> Martin Thomson
> nomcom-chair-2...@ietf.org
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [lisp] On the use of priority associated to RLOCs

[Luigi Iannone]

> On 25 May 2023, at 20:34, Dino Farinacci  wrote:
> 
> 
 
 Now, let’s take one step back: the real question seems to be how to signal 
 in the mapping system that an RLOC belongs to a RTR? 
>>> 
>>> You could do it with a distinguished-name AFI that is encoded with the RLOC 
>>> address.
>> 
>> Excellent. So we have another possibility beside LCAF.
> 
> Well to be specific, if you put a dist-name with the RLOC it is encoded as an 
> AFI-list LCAF.  But I know what you mean. You are proposing/considering a new 
> LCAF type that identifies an RTR.
> 

This could be one solution. But we do not need to do it if there is no 
interest. 
For this document the text suggested by Joel clarifies the peculiar usage of 
the priority field.
I would just amend the text as follows:

"this describes a shortcut we took, not compliant with [RFC9300] and [RFC9301], 
which works among consenting parties when no one else is using the particular 
values in any other way, but we do not recommended it for arbitrary 
deployments.”

Ciao

L.


> Dino
> 

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

Re: [lisp] On the use of priority associated to RLOCs

[Luigi Iannone]

> On 24 May 2023, at 20:38, Joel Halpern  wrote:
> 
> If you want to start the draft by saying "this describes a shortcut we took, 
> which works among consenting parties when no one else is using the particular 
> values in nay other way, but we do not recommended it for arbitrary 
> deployments" then I would probably have fewer concerns.  As you say, you did 
> indeed do it.

This could be a way forward, but implies rewriting accordingly the 
interoperability text that are in the document.

Ciao

L.

> 
> Yours,
> 
> Joel
> 
> On 5/24/2023 1:55 PM, Dino Farinacci wrote:
>>> Trimmed, In line.
>>> 
>>> On 5/24/2023 1:45 PM, Dino Farinacci wrote:
> there are a few things to ponder:
> 
> - Looking at lispers.net the 254 value choice, it looks like a quick hack.
 I would refer to it as a convienent solution that doesn't violate the spec.
>>> claiming that this alternative meaning is not a violation is quite a 
>>> stretch.
>> As an implementor, it was convienent. I'm not saying anything more than 
>> that. I should have used an alternative mechanism.
>> 
> - What about backward compatibility? If we allow overloading, there is no 
> way to understand whether a value indicates a “true” priority or 
> something else, different implementations may interpret the value in 
> different ways with unpredictable results.
 It always means a true value from an xTR point of view.
>>> It is the true value because you said so.  The important point however 
>>> is that you decclare that otehr nodes can tell that the advertiser is an 
>>> RTR from the priority.  That is adding additional inappropriate, and 
>>> overloading meaning to the priority.  
>> I don't know what you mean. The map-server will return RLOCs with 
>> priorities. The ITR uses them according the spec. There isn't anything more 
>> complciated than that.
>> 
>> I do not declare that from an ITR point of view. It is true from an ETR 
>> point of view.
>> 
>> I'm trying to provide clarity and details so the working group understands 
>> how it works not the motivation for using the solution or why it was chosen.
>> 
>> Dino
>> 
>> 
>> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

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

Re: [lisp] On the use of priority associated to RLOCs

[Luigi Iannone]

Hi Dino,

> On 24 May 2023, at 19:45, Dino Farinacci  wrote:
> 
>> there are a few things to ponder:
>> 
>> - Looking at lispers.net the 254 value choice, it looks like a quick hack. 
> 
> I would refer to it as a convienent solution that doesn't violate the spec.
> 
>> - What about backward compatibility? If we allow overloading, there is no 
>> way to understand whether a value indicates a “true” priority or something 
>> else, different implementations may interpret the value in different ways 
>> with unpredictable results.
> 
> It always means a true value from an xTR point of view.

Understood. So the most accurate statement is that it "indicates the priority 
AND additional information, i.e. it is a RTR”.  


> 
>> - What about weight? In the lispers.net NAT traversal it is used as defined 
>> in the main specs, but this means that all RTR have the same priority all 
>> the time. And what if a future value will indicate not to use weight? Or use 
>> it in a different way?  
> 
> This solution does not violate the LISP spec on how ITRs/RTRs use priorities 
> and weights.

You are adding protocol actions not related to priority upon a specific 
priority value…. Without calling it a violation of the specs this is a not 
following the specs as they are for now. Hence the question what should be 
done. 


> 
>> - With the above we end up having RLOCs priorities that can be priority or 
>> something else. In this latter case weight can or cannot be meaningful (or 
>> even be something else altogether). Architecturally speaking it looks to me 
>> less clean. 
> 
> This is simply not true.

Yes, this is not true in the lispers.net  case.
> 
> I think you are overstating the problem.

If we open the door to the use of priority value that are different from just 
priority values the question is quite relevant IMO.

> 
>> Now, let’s take one step back: the real question seems to be how to signal 
>> in the mapping system that an RLOC belongs to a RTR? 
> 
> You could do it with a distinguished-name AFI that is encoded with the RLOC 
> address.

Excellent. So we have another possibility beside LCAF.

> 
>> The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved 
>> bits. One can be allocated to indicate whether the RLOC address belongs to 
>> an RTR.
> 
> That could be too specific to this use-case. What an ETR needs to know is if 
> it should tag RLOCs it gets back from the map-server in Info-Reply messages 
> with this bit.
> 
> It actually could not tag it at all since the map-servers know the addresses 
> of RTR RLOCs when they advertise them. But that means all map-servers need to 
> have the same info and there is configuration coordination required.

Don’t see this. The bit (or tag) is associate to the RLOC, the same way the 254 
value is.


> 
>> A side benefit of this choice would be that older implementations will just 
>> ignore the bit, hence taking no action, rather than interpreting the bit in 
>> a different way. Looks like a safer situation to me. You can even use a 
>> whole new type, so that an implementation either knows how to handle it or 
>> does nothing at all.
> 
> No that won't be the case. The way it works is that the RTR will give an 
> RLOC-set to the ITR. So the ITR doesn't know if an RLOC is an ETR RTR pETR, 
> etc. But the ETR side registeres the RTR RLOCs with 254. That is what is 
> implemented today. If the ETR DOES NOT do this the map-server could figure it 
> out on its own (as I mention above).

I was not referring to you implementation. I was referring to possible 
interoperability issues.

Ciao

L.
> 
> Dino
> 
>> 
>> Thoughts from the WG folks?
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>>> 
>>> Note this is only how the map-server operates. So existing xTRs will get 
>>> back whatever the map-server decides. So if you are not an RTR (that must 
>>> be configured in the said map-server) you will get back an RTR RLOC that an 
>>> xTR will happily encapsulate to. That is, it works with existing xTRs that 
>>> don't know anything about NAT-traversal.
>>> 
>>> This implementation has interoperated with other implementations, but we 
>>> don't claim anything in the draft. And existing xTRs can *receive* packets 
>>> without following the control-plane procedures from the draft. We 
>>> demostrated this with OOR by doing gleaning on the RTR.
>>> 
>>> I have videos demostrating this for unicast and multicast and can send 
>>> pointers if people are interested.
>>> 
>>> Dino
>>> ___
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
> 

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

Re: [lisp] On the use of priority associated to RLOCs

[Luigi Iannone]

Errata!

> On 24 May 2023, at 13:48, Luigi Iannone  wrote:
> 
> 
> 
>> On 23 May 2023, at 23:05, Dino Farinacci  wrote:
>> 
>>> Personally, I find this to be an inappropriate overlaoding of the Priority. 
>>>  While overloading is not uncommon, it often causes problems with protocols 
>>> and I would prefer that we not do so.
>> 
>> We all do. But the implementation has been deployed for nearly 10 years. The 
>> draft is just reporting/documenting how it is used. 
> 
> Dino,
> 
> 
> 
> The fact that you use that specific value in a particular way does mean that 
> the WG should agree to use priority values to indicate other things.

There is a missing NOT.

The right sentence is:

The fact that you use that specific value in a particular way does NOT mean 
that the WG should agree to use priority values to indicate other things.

L.


> The LISP WG is free to decide to deprecate such usage.
> 
> 
> 
> What follows is my personal opinion.
> 
> About overloading priority with other meanings:
> 
> Having 256 values to define priority is quite large and (according to my 
> experience) we can live with a lot less. So from that perspective it is not a 
> big deal.
> 
> YET 
> 
> there are a few things to ponder:
> 
> - Looking at lispers.net <http://lispers.net/> the 254 value choice, it looks 
> like a quick hack. 
> 
> - What about backward compatibility? If we allow overloading, there is no way 
> to understand whether a value indicates a “true” priority or something else, 
> different implementations may interpret the value in different ways with 
> unpredictable results.
> 
> - What about weight? In the lispers.net <http://lispers.net/> NAT traversal 
> it is used as defined in the main specs, but this means that all RTR have the 
> same priority all the time. And what if a future value will indicate not to 
> use weight? Or use it in a different way?  
> 
> - With the above we end up having RLOCs priorities that can be priority or 
> something else. In this latter case weight can or cannot be meaningful (or 
> even be something else altogether). Architecturally speaking it looks to me 
> less clean. 
> 
> Now, let’s take one step back: the real question seems to be how to signal in 
> the mapping system that an RLOC belongs to a RTR? 
> Or in a more general way: How to deliver RLOC-related informations that go 
> beyond priority and weight?
> 
> The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved 
> bits. One can be allocated to indicate whether the RLOC address belongs to an 
> RTR.
> A side benefit of this choice would be that older implementations will just 
> ignore the bit, hence taking no action, rather than interpreting the bit in a 
> different way. Looks like a safer situation to me. You can even use a whole 
> new type, so that an implementation either knows how to handle it or does 
> nothing at all.
> 
> Thoughts from the WG folks?
> 
> Ciao
> 
> L.
> 
> 
>> 
>> Note this is only how the map-server operates. So existing xTRs will get 
>> back whatever the map-server decides. So if you are not an RTR (that must be 
>> configured in the said map-server) you will get back an RTR RLOC that an xTR 
>> will happily encapsulate to. That is, it works with existing xTRs that don't 
>> know anything about NAT-traversal.
>> 
>> This implementation has interoperated with other implementations, but we 
>> don't claim anything in the draft. And existing xTRs can *receive* packets 
>> without following the control-plane procedures from the draft. We 
>> demostrated this with OOR by doing gleaning on the RTR.
>> 
>> I have videos demostrating this for unicast and multicast and can send 
>> pointers if people are interested.
>> 
>> Dino
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 

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

Re: [lisp] On the use of priority associated to RLOCs

[Luigi Iannone]

> On 23 May 2023, at 23:05, Dino Farinacci  wrote:
> 
>> Personally, I find this to be an inappropriate overlaoding of the Priority.  
>> While overloading is not uncommon, it often causes problems with protocols 
>> and I would prefer that we not do so.
> 
> We all do. But the implementation has been deployed for nearly 10 years. The 
> draft is just reporting/documenting how it is used. 

Dino,



The fact that you use that specific value in a particular way does mean that 
the WG should agree to use priority values to indicate other things.
The LISP WG is free to decide to deprecate such usage.



What follows is my personal opinion.

About overloading priority with other meanings:

Having 256 values to define priority is quite large and (according to my 
experience) we can live with a lot less. So from that perspective it is not a 
big deal.

YET 

there are a few things to ponder:

- Looking at lispers.net  the 254 value choice, it looks 
like a quick hack. 

- What about backward compatibility? If we allow overloading, there is no way 
to understand whether a value indicates a “true” priority or something else, 
different implementations may interpret the value in different ways with 
unpredictable results.

- What about weight? In the lispers.net  NAT traversal it 
is used as defined in the main specs, but this means that all RTR have the same 
priority all the time. And what if a future value will indicate not to use 
weight? Or use it in a different way?  

- With the above we end up having RLOCs priorities that can be priority or 
something else. In this latter case weight can or cannot be meaningful (or even 
be something else altogether). Architecturally speaking it looks to me less 
clean. 

Now, let’s take one step back: the real question seems to be how to signal in 
the mapping system that an RLOC belongs to a RTR? 
Or in a more general way: How to deliver RLOC-related informations that go 
beyond priority and weight?

The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved 
bits. One can be allocated to indicate whether the RLOC address belongs to an 
RTR.
A side benefit of this choice would be that older implementations will just 
ignore the bit, hence taking no action, rather than interpreting the bit in a 
different way. Looks like a safer situation to me. You can even use a whole new 
type, so that an implementation either knows how to handle it or does nothing 
at all.

Thoughts from the WG folks?

Ciao

L.


> 
> Note this is only how the map-server operates. So existing xTRs will get back 
> whatever the map-server decides. So if you are not an RTR (that must be 
> configured in the said map-server) you will get back an RTR RLOC that an xTR 
> will happily encapsulate to. That is, it works with existing xTRs that don't 
> know anything about NAT-traversal.
> 
> This implementation has interoperated with other implementations, but we 
> don't claim anything in the draft. And existing xTRs can *receive* packets 
> without following the control-plane procedures from the draft. We demostrated 
> this with OOR by doing gleaning on the RTR.
> 
> I have videos demostrating this for unicast and multicast and can send 
> pointers if people are interested.
> 
> 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] On the use of priority associated to RLOCs

[Luigi Iannone]

Hi All,


TL;DR: Should the priority associated to RLOCs be used to indicate something 
else?

Long Version:

As you may (or may not) know Dino submitted the lispers.net 
 NAT traversal solution 
(https://datatracker.ietf.org/doc/draft-farinacci-lisp-lispers-net-nat/ ) for 
publication on the Independent Stream 
(https://www.rfc-editor.org/about/independent/).

Current ISE Editor is Eliot Lear (well known by old lispers like me ;-) )

During the review of the document an interesting question came up:

Lispers.net  NAT traversal uses priority 254 to indicate 
that the RLOC belongs to a RTR.

No text in old and new specs suggest a usage of the priority to deliver 
something different than the priority itself.
Even the value 255 is related to priority: do not use this RLOC = no priority.

It goes without saying that there is no IANA registry about special value of 
priority associated to RLOCs.

At the same time there is no text that explicitly states “priority indicates 
only the priority and CANNOT be used for something else”.

So the question is: Should we (the WG) consider that priorities can be used to 
indicate something different from priority?

If not: we may want to write it down somewhere.

If yes: Well…. This deserves a longer discussion (may be to be included in the 
new charter…).

Thoughts ?

Ciao

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

[Luigi Iannone]

Hi Dino,

> On 14 Mar 2023, at 20:35, Dino Farinacci  wrote:
> 
>> LISP Mobility: candidate document LISP-MN but does not solve everything 
>> should we enlarge the scope?
> 
> draft-ietf-lisp-eid-mobility as well. 

Right. We can have a general discussion about mobility and what kind of 
documents we need.
Would lisp-mn and lisp-end-mobility be sufficient? Are there any other use 
cases? 


> 
>> LISP Yang Model: We are pretty close to finish this one
>> LISP NAT Traversal: we have a candidate document
> 
> And VPNs are in charter and used quite a lot in LISP deployments, so 
> draft-ietf-lisp-vpn.

Good point.

> 
> Alternative Mapping System Design is part of the charter and the only draft 
> that is pending is draft-farinacci-lisp-decent but not sure this needs to be 
> standardized.
> 
> And we need to decide the outcome of draft-ietf-lisp-te and control-plane 
> security such as draft-ietf-lisp-ecdsa-auth and draft-ietf-eid-anonymity. I'm 
> not sure they need to be standards track. 
> 

They can still be experimental if WG is willing to publishing them. The charter 
may include a security/privacy work item and these documents would be covered.

Ciao

L.



> Dino
> 

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

Re: [lisp] Rechartering Thread 2: From Experimental to ST: these are a bunch of RFC that may be considered

[Luigi Iannone]

Hi Sharon,

If I understand correctly this is a list of real deployments that clearly show 
that  indeed there are a bunch of documents for which it makes totally sense to 
be moved to ST.

Am I correct?

Ciao

L.
 

> On 15 Mar 2023, at 09:05, Sharon Barkai  wrote:
> 
> 
> A full solution project example hopefully all addressing, encapsulation, 
> mcast, and security items are in charter (adopted and wg last call)
> 
> 
> 
> 
> Cost reduction of infotainment data:
> - Infotainment connected to Internet
> - Using public OEM IP address space
> - Vehicles toggle wifi/cellular RLOC
> - Seamless to the Internet sessions
> 
> Automotive Edge Compute Applications:
> - Dynamic HdMapping while vehicles Driving
> - Regional Ad-Hoc Datacenter while Parked 
> - Edge Geo Agents’  EIDs are based on H3 
> - Vehicle (far-edge) AI EIDs are ephemeral 
> 
> The value: 
> - realtime automatic map generation, increase safety, reduced corner cases 
> - mobile edge location capacity multiplied by engaging available far-edge-ai 
> 
> 
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> 
>> On Mar 14, 2023, at 21:38, Dino Farinacci  wrote:
>> 
>> 
>>> 
>>> Hi LISP WG,
>>> 
>>> As for the subject, this email starts the discussion about: From 
>>> Experimental to ST: these are a bunch of RFC that may be considered to move 
>>> ST
>>> 
>>> There are a few experimental RFCs which is worth to be considered to be 
>>> moved to standard track (if we have documented deployment experience), 
>>> namely:
>>> 
>>> RFC 6832: Interworking between Locator/ID Separation Protocol (LISP) and 
>>> Non-LISP Sites
>>> RFC 8060: LISP Canonical Address Format (LCAF) [This is largely used and 
>>> may be merged with 9306]
>>> RFC 8111: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) 
>>> [The only scalable Mapping System so far…..] 
>> 
>> Agree.
>> 
>>> Multicast can be another one work item. 
>>> RFC 6831: The Locator/ID Separation Protocol (LISP) for Multicast 
>>> Environments
>>> RFC 8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast 
>> 
>> The new draft that Prasad submitted this week makes it a trio with the above 
>> to. It addresses how to mix the functionality of 6831 and 8378 when there is 
>> a mix of native multicast and non-native multicast in the underlay.
>> 
>> Dino
>> 
>>> 
>>> Please send us back your thoughts.
>>> 
>>> 
>>> Padma 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

[lisp] Rechartering Thread 2: From Experimental to ST: these are a bunch of RFC that may be considered

[Luigi Iannone]

Hi LISP WG,

As for the subject, this email starts the discussion about: From Experimental 
to ST: these are a bunch of RFC that may be considered to move ST

There are a few experimental RFCs which is worth to be considered to be moved 
to standard track (if we have documented deployment experience), namely:

RFC 6832: Interworking between Locator/ID Separation Protocol (LISP) and 
Non-LISP Sites
RFC 8060: LISP Canonical Address Format (LCAF) [This is largely used and may be 
merged with 9306]
RFC 8111: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) 
[The only scalable Mapping System so far…..] 

Multicast can be another one work item. 
RFC 6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments
RFC 8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast 

Please send us back your thoughts.


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

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

[Luigi Iannone]

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

[lisp] About LISP WG Rechartering

[Luigi Iannone]

Hi LISP WG,

In order to start the rechartering discussion ahead of our meeting in Yokohama, 
we (the chairs) would like to start two threads discussing work items.

The two threads will be:

1. Promised work item: work items currently in the charter but not finished

2. From Experimental to ST: these are a bunch of RFCs that may be considered to 
be ,over to standard track

Expect an email on these two topics in the next minutes ;-)

Ciao

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

[lisp] Fwd: lisp - Requested session has been scheduled for IETF 116

[Luigi Iannone]

Hi All,

Our LISP session has been scheduled.
We have two full hours.

Please send to the chairs your request for a presentation slot no later than 
next Tuesday (14th March).

Ciao

L.
 

> Begin forwarded message:
> 
> From: "\"IETF Secretariat\"" 
> Subject: lisp - Requested session has been scheduled for IETF 116
> Date: 4 March 2023 at 00:06:29 CET
> To: , 
> Cc: aretana.i...@gmail.com, lisp@ietf.org
> Resent-From: 
> Resent-To: padma.i...@gmail.com, g...@gigix.net, na...@cisco.com
> 
> Dear Luigi Iannone,
> 
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request. 
> 
> 
>lisp Session 1 (2:00 requested)
>Tuesday, 28 March 2023, Session II 0400-0600
>Room Name: G412-G413 size: 100
>-
> 
> 
> iCalendar: https://datatracker.ietf.org/meeting/116/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: 
> 
> 
> 
> 
> Participants who must be present:
>  Alberto Rodriguez-Natal
>  Luigi Iannone
>  Padma Pillay-Esnault
> 
> Resources Requested:
> 
> Special Requests:
> 
> -
> 
> 

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

Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09

[Luigi Iannone]

Hi,

> On 19 Jan 2023, at 09:18, Alberto Rodriguez-Natal (natal)  
> wrote:
> 
> Hi Alvaro,
>  
> Thanks for reviewing the new version! Your comments seem fine to me, we’ll 
> add all your suggestions along with the DE text suggested by Med to -11.
>  
> Just one comment regarding the reference to 6830. It is there since 9301 does 
> not suggest any default TTL for mappings, but 6830 does (24-hour) and the 
> value is commonly used in deployments. Let me know if it would fine to keep 
> the reference to 6830 in Informative, otherwise no problem in removing it.
>  

IMO you do not need a reference to 6830, you can modify the text being generic. 
The problem of stale mapping arise any long TTL.
 Instead of :

As per Section 6.6.1 of [RFC6830], the default setting for an EID-to-
   RLOC mapping TTL in the cache is 24 hours.  Upon the expiry of that
   TTL, the xTR checks if these entries are being used and removes any
   entry that is not being used.  The problem with this 24-hour Map-
   Cache TTL is that (in the absence of PubSub) if a mapp


You can put:

  EID-to-RLOC mappings can have very long TTL, in the order of several hours..  
Upon the expiry of that
   TTL, the xTR checks if these entries are being used and removes any
   entry that is not being used.  The problem with several hours-long Map-
   Cache TTL is that (in the absence of PubSub) if a mapp


What do you think?

Ciao

L.



> Thanks!
> Alberto
>  
> From: Alvaro Retana 
> Date: Thursday, January 12, 2023 at 8:40 PM
> To: Alberto Rodriguez-Natal (natal) , lisp@ietf.org 
> 
> Cc: Vina Ermagan , mohamed.boucad...@orange.com 
> , Fabio Maino (fmaino) , 
> lisp-cha...@ietf.org , Dino Farinacci 
> , Luigi Iannone , Albert Cabellos 
> , Stefano Secci , Johnson Leong 
> , JACQUENET Christian INNOV/NET 
> , Sharon Barkai 
> Subject: Re: AD Review of draft-ietf-lisp-pubsub-09
> 
> On November 6, 2022 at 5:32:47 AM, Alberto Rodriguez-Natal wrote:
> 
> 
> Alberto:
> 
> Hi!
> 
> I've looked at your replies and the diffs using the version -10.  I
> still have a couple of comments in-line -- mostly about the
> instructions to the designated experts.
> 
> Please move the text in §8 (Sample PubSub Deployment Experiences) to
> an appendix and update the reference to rfc6830.
> 
> I am starting the IETF Last Call.  I know that you still have to
> address Padma's comments -- you can treat them (and mine) as LC
> comments.
> 
> Thanks!
> 
> Alvaro.

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

Re: [lisp] Padma's feedback on PubSub -09 [was: Re: LISP PubSub to Proposed Standard?]

[Luigi Iannone]

On 5 Jan 2023, at 12:16, Alberto Rodriguez-Natal (natal)  wrote:







Hi Padma,
 
Thanks a lot for your feedback! Let me spin out a new thread to better address your comments.
 
We were about to submit version -10 of the document addressing (hopefully) all the feedback received so far (which has been significant). If it is fine with you, I’ll still proceed with submitting
 version -10 (today or tomorrow, likely) in its current form. Then we can discuss your latest feedback here and any potential changes coming from the discussion can go into -11, sounds good?

 
Also, given that there seems to be support for moving the document to Standards Track, I’ll submit version -10 as Standards already, hoping this is fine.
Hi Alberto,Yes, it is fine. Pad an and myself already discussed about it and we agree that the WG is OK to move this document to PS.CiaoL. 
Regarding your feedback below, I think you’re making some good questions. Let me put together some text to address your comments. I’ll get back to you shortly.
 
Thanks!
Alberto
 


From: lisp  on behalf of Padma Pillay-Esnault 
Date: Thursday, January 5, 2023 at 8:29 AM
To: Alberto Rodriguez-Natal (natal) 
Cc: lisp@ietf.org , Sharon Barkai , Jordi Paillissé 
Subject: Re: [lisp] LISP PubSub to Proposed Standard?




Dear Alberto and authors

 


Thank you for the good work on this doc. I fully support moving this document as a proposed standard,  however I have a few comments on the document. See PPE below


1.  Introduction


<...>


   In general, when an ITR/RTR/PITR wants to be notified for mapping
   changes for a given EID-prefix, the following steps occur:
 
   (1)  The ITR/RTR/PITR sends a Map-Request for that EID-prefix.
 
   (2)  The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
    the Map-Request and includes its xTR-ID and Site-ID.
 
   (3)  The Map-Request is forwarded to one of the Map-Servers that the
    EID-prefix is registered to.
 
   (4)  The Map-Server creates subscription state for the ITR/RTR/PITR
    on the EID-prefix.
 
   (5)  The Map-Server sends a Map-Notify to the ITR/RTR/PITR to
    acknowledge the successful subscription.
 
   (6)  When there is a change in the mapping of the EID-Prefix, the
    Map-Server sends a Map-Notify message to each ITR/RTR/PITR in
    the subscription list.
 
   (7)  Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
    received Map-Notify.
 
   This operation is repeated for all EID-prefixes for which ITR/RTR/
   PITR want to be notified.  The ITR/RTR/PITR can set the N-bit for
   several EID-prefixes within a single Map-Request.
<...>


PPE -  This section relies on section 6.1 of rfc 9301 and gives as an example the simplest use case. The concluding paragraph also gives the impression that this is the only processing
 pub sub needs to do. Both the section 6.1 and here do not address all the use cases.


 


I suggest removing this from the introduction and instead clearly define the scope and then define all the use cases as in a real deployment scenario in section 3. See more about
 this below.


 


<...>


3.  Deployment Assumptions
 
   The specification described in this document makes the following
   deployment assumptions:
 
   (1)  A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
    assigned to each xTR.
 
   (2)  Map-Servers are configured in proxy-reply mode, i.e., they are
    solicited to generate and send Map-Reply messages for the
    mappings they are serving.
 
   The distribution of xTR-IDs (and Site-IDs) are out of the scope of
   this document.


<...>


 


PPE - The section 3 is sparse and could define use cases in this section.  In a real life deployment, there may be a variety of use
 cases such as 


1. an ITR/PITR/RTR joins an existing LISP network and subscribes to specific existing EID prefixes updates (this is addressed in the intro)


2. an ITR/PITR/RTR  joins "early" a growing LISP network and subscribes to an EID prefix NOT YET present in the database ( covered
 by 8.4 in rfc 9301? - more below) 


3. an ITR/PITR/RTR sends multiple requests where the range of prefix/len is removed and readded are slightly different or overlapping, how do we cover the use case of "holes"? 


4. scale - what if we have a large number of subscriptions - do we intend them to be aggregated or rely on 5.5 in rfc 9301?


 


The document would be much clearer if the processing expected for each of these use cases were described explicitly.


 


Consider, the pub sub mechanism is used to minimize the number of messages exchanged and timing issues by using a triggered event solution. However, it is unclear how it works for
 use case 2  when there is no existing EID entry yet.  Upon receiving a negative map reply should there be periodic resend of SMR from the RTR/ITR/PITR? Or is the first SMR stored somewhere on the Mapping System
 on a temporary entry and when the EID is added later does it trigger the response? 

[lisp] New LISP WG Secretary

[Luigi Iannone]

Hi All,

Alberto did kindly step up and volunteered as LISP WG Secretary. 
He will help Padma and myself in the various admins tasks.

Thanks Alberto for stepping up and have a nice New Year’s eve everyone

Ciao

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

Re: [lisp] Review for LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi Dino,

> On 9 Dec 2022, at 22:20, Dino Farinacci  wrote:
> 
> I agree with all your comments and will do a revision. 
> 
> Regarding Type 5, that type was previously allocated *for this draft*. 
> Sometimes it is hard to remember since so much time has passed.

Indeed it has been quite some time….

If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is 
completely incompatible with the specs in this document.

What about asking for type 15 and name it “extended Geo-coordinates”?

Ciao

L.



> 
> So we do not need a new type.
> 
> Dino
> 
>> On Dec 9, 2022, at 6:38 AM, Luigi Iannone  wrote:
>> 
>> Hi Dino,
>> 
>> I reviewed the lisp-geo document. My comments inline.
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Network Working Group   D. Farinacci
>>> Internet-Draft   lispers.net
>>> Intended status: Experimental   23 November 2022
>>> Expires: 27 May 2023
>>> 
>>> 
>>>LISP Geo-Coordinate Use-Cases
>>>draft-ietf-lisp-geo-00
>>> 
>>> Abstract
>>> 
>>>  This draft describes how Geo-Coordinates can be used in the LISP
>>>  Architecture and Protocols.
>>> 
>> 
>> Would be good to add more word. The document does 2 things: propose uses 
>> cases, define geo coordinates encoding.
>> 
>> 
>>> Status of This Memo
>>> 
>>>  This Internet-Draft is submitted in full conformance with the
>>>  provisions of BCP 78 and BCP 79.
>>> 
>>>  Internet-Drafts are working documents of the Internet Engineering
>>>  Task Force (IETF).  Note that other groups may also distribute
>>>  working documents as Internet-Drafts.  The list of current Internet-
>>>  Drafts is at https://datatracker.ietf.org/drafts/current/.
>>> 
>>>  Internet-Drafts are draft documents valid for a maximum of six months
>>>  and may be updated, replaced, or obsoleted by other documents at any
>>>  time.  It is inappropriate to use Internet-Drafts as reference
>>>  material or to cite them other than as "work in progress."
>>> 
>>>  This Internet-Draft will expire on 27 May 2023.
>>> 
>>> Copyright Notice
>>> 
>>>  Copyright (c) 2022 IETF Trust and the persons identified as the
>>>  document authors.  All rights reserved.
>>> 
>>>  This document is subject to BCP 78 and the IETF Trust's Legal
>>>  Provisions Relating to IETF Documents (https://trustee.ietf.org/
>>>  license-info) in effect on the date of publication of this document.
>>>  Please review these documents carefully, as they describe your rights
>>>  and restrictions with respect to this document.  Code Components
>>>  extracted from this document must include Revised BSD License text as
>>>  described in Section 4.e of the Trust Legal Provisions and are
>>>  provided without warranty as described in the Revised BSD License.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Farinacci  Expires 27 May 2023  [Page 1]
>>> Internet-DraftLISP Geo-Coordinate Use-CasesNovember 2022
>>> 
>>> 
>>> Table of Contents
>>> 
>>>  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>>>  2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
>>>  3.  Geo-Points in RLOC-records  . . . . . . . . . . . . . . . . .   3
>>>  4.  Geo-Prefixes in EID-records and RLOC-records  . . . . . . . .   3
>>>  5.  Geo-Prefix and Geo-Point Encodings  . . . . . . . . . . . . .   5
>>>  6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
>>>  7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
>>>  8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
>>>  9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>>>9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
>>>9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
>>>  Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
>>>  Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  10
>>>B.1.  Changes to draft-ietf-lisp-geo-00 . . . 

[lisp] Review for LISP Geo-Coordinate Use-Cases

[Luigi Iannone]

Hi Dino,

I reviewed the lisp-geo document. My comments inline.

Ciao

L.







> 
> 
> 
> 
> 
> Network Working Group   D. Farinacci
> Internet-Draft   lispers.net
> Intended status: Experimental   23 November 2022
> Expires: 27 May 2023
> 
> 
>  LISP Geo-Coordinate Use-Cases
>  draft-ietf-lisp-geo-00
> 
> Abstract
> 
>This draft describes how Geo-Coordinates can be used in the LISP
>Architecture and Protocols.
> 

Would be good to add more word. The document does 2 things: propose uses cases, 
define geo coordinates encoding.


> Status of This Memo
> 
>This Internet-Draft is submitted in full conformance with the
>provisions of BCP 78 and BCP 79.
> 
>Internet-Drafts are working documents of the Internet Engineering
>Task Force (IETF).  Note that other groups may also distribute
>working documents as Internet-Drafts.  The list of current Internet-
>Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
>Internet-Drafts are draft documents valid for a maximum of six months
>and may be updated, replaced, or obsoleted by other documents at any
>time.  It is inappropriate to use Internet-Drafts as reference
>material or to cite them other than as "work in progress."
> 
>This Internet-Draft will expire on 27 May 2023.
> 
> Copyright Notice
> 
>Copyright (c) 2022 IETF Trust and the persons identified as the
>document authors.  All rights reserved.
> 
>This document is subject to BCP 78 and the IETF Trust's Legal
>Provisions Relating to IETF Documents (https://trustee.ietf.org/
>license-info) in effect on the date of publication of this document.
>Please review these documents carefully, as they describe your rights
>and restrictions with respect to this document.  Code Components
>extracted from this document must include Revised BSD License text as
>described in Section 4.e of the Trust Legal Provisions and are
>provided without warranty as described in the Revised BSD License.
> 
> 
> 
> 
> 
> 
> 
> Farinacci  Expires 27 May 2023  [Page 1]
> Internet-DraftLISP Geo-Coordinate Use-CasesNovember 2022
> 
> 
> Table of Contents
> 
>1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
>3.  Geo-Points in RLOC-records  . . . . . . . . . . . . . . . . .   3
>4.  Geo-Prefixes in EID-records and RLOC-records  . . . . . . . .   3
>5.  Geo-Prefix and Geo-Point Encodings  . . . . . . . . . . . . .   5
>6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
>7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
>8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
>9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
>  9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
>Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
>Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  10
>  B.1.  Changes to draft-ietf-lisp-geo-00 . . . . . . . . . . . .  10
>  B.2.  Changes to draft-farinacci-lisp-geo-15  . . . . . . . . .  11
>  B.3.  Changes to draft-farinacci-lisp-geo-14  . . . . . . . . .  11
>  B.4.  Changes to draft-farinacci-lisp-geo-13  . . . . . . . . .  11
>  B.5.  Changes to draft-farinacci-lisp-geo-12  . . . . . . . . .  11
>  B.6.  Changes to draft-farinacci-lisp-geo-11  . . . . . . . . .  11
>  B.7.  Changes to draft-farinacci-lisp-geo-10  . . . . . . . . .  11
>  B.8.  Changes to draft-farinacci-lisp-geo-09  . . . . . . . . .  11
>  B.9.  Changes to draft-farinacci-lisp-geo-08  . . . . . . . . .  11
>  B.10. Changes to draft-farinacci-lisp-geo-07  . . . . . . . . .  12
>  B.11. Changes to draft-farinacci-lisp-geo-06  . . . . . . . . .  12
>  B.12. Changes to draft-farinacci-lisp-geo-05  . . . . . . . . .  12
>  B.13. Changes to draft-farinacci-lisp-geo-04  . . . . . . . . .  12
>  B.14. Changes to draft-farinacci-lisp-geo-03  . . . . . . . . .  12
>  B.15. Changes to draft-farinacci-lisp-geo-02  . . . . . . . . .  12
>  B.16. Changes to draft-farinacci-lisp-geo-01  . . . . . . . . .  12
>  B.17. Changes to draft-farinacci-lisp-geo-00  . . . . . . . . .  13
>Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13
> 
> 1.  Introduction
> 
>The LISP architecture and protocols [RFC9300] introduces two new
>namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs)
>which are intended to separate the semantics of identity and
>topological location from an IP address.  To provide flexibility for
>curr

Re: [lisp] Soliciting comments for draft-farinacci-lisp-satellite-01

[Luigi Iannone]

Hi,


> On 22 Nov 2022, at 21:12, Dino Farinacci  wrote:
> 
> I was asked by Luigi at the LISP WG meeting to start a discussion about this 
> document and solicit review for comments.
> 
> Does the WG think this should be a working group document?

Before going to this step (WG adoption).

Would be good if people read and review this document.

Ciao

L.



> 
> Please send comments. Thanks.
> 
> Dino
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

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

Re: [lisp] LISP PubSub to Proposed Standard?

[Luigi Iannone]

As an individual I think there is sufficient experience to make this draft a 
proposed standard.



Folks, please express your opinion about moving this document to PS.
 
Ciao

L.


> On 10 Nov 2022, at 11:15, Jordi Paillissé  wrote:
> 
> I agree with moving the document forward. It's a valuable functionality.
> 
> Thanks,
> 
> Jordi
> 
> El 6/11/22 a les 13:57, Dino Farinacci ha escrit:
>> 
>>> On Nov 6, 2022, at 12:27 PM, Alberto Rodriguez-Natal (natal) 
>>>  wrote:
>>> 
>>> On the meantime, what is the view of the WG on moving the document to 
>>> Proposed Standard?
>> I think it is critical to carry this fundamental solution as Proposed 
>> Standard. We have struggled for years keeping mappings up to date on 
>> proxy-ITRs.
>> 
>> Pubsub provides an event triggered solution which I believe is fundamental 
>> functionality the architecture needs.
>> 
>> 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

[lisp] NomCom Request for feedback

[Luigi Iannone]

Hi all,

The NomCom is tasked with selecting the IETF leadership, like the IESG and the 
IAB. 
For the NomCom to be able to make an informed decision, they need feedback from 
the wider IETF community.

Please consider providing feedback on people that you interacted with to help 
the NomCom with their important task.

The deadline for this feedback is Nov 28 of 2022.

https://datatracker.ietf.org/nomcom/2022/feedback

Ciao

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