Subject: [lisp] Lisp 108 meeting comments

From: Sharon Barkai <[email-masked]>
Date: Thu, 30 Jul 2020 12:11:32 +0300

Just wanted to say that the  meeting was very short, and perhaps make a couple suggestions

1. LISP NAT Traversal 

This is an important problem which is inherent from the fact that rlocs are a stored in the map server-resolver and not just in the data-path.

I think we need a full interim and a strategy to deal with it starting with brute force: all EIDs and XTR which are CPE or behind NAT can use RTRs in the provider edge - or same NAT zone as the map server-resolver - allocated dynamically by the map server-resolver.

From this starting point we can start to offer optional breakout optimizations, For example:

- If the map server-resolver and the ITR are in the same NAT domain
- when the map server gets a query which it knows is for an ETR which is behind NAT
- it asks the ETR to self-resolve for that specific query for that specific ITR
- so the ETR will talk to the ITR before talked-to by the ITR

Or things like that, but remove NAT doubts from all LISP Edge Networks and LISP VPNs.

2. LISP-Nexagon

Edge street processing and Edge AV-OSS are getting hot. If we do not issue at least one good IETF layer3 geo-pub-sub then the following will likely happen:

From the folks who brought us mobility application networks directly over layer2 which never got implemented will be getting mobility layer2 edge networks based on RSUs that will not be installed in our lifetime. Where as SIMSensors will be everywhere streets and vehicles very soon.

A bit blunt but many of us are not young anymore  apropos 0x3Dino :) so need to make progress also in the interim till 109.

Hope makes sense.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794