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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
