Re: [lisp] Comments on https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-10

[Dino Farinacci <[e-mail]>]

> Hi Guru,
> I have looked subject and have a few comments:

Hi Eduard.

> 1.       The draft does mention a few times “without triangle routing in the data path”.
> But section 7.4: “As a result, packets may be natively forwarded to non-LISP sites by an ITR (the return path will through a PITR, however, since the packet flow will be non-LISP site to LISP site).”

Yes, it depends on PITR placement in the network. If PITRs are distributed and placed in access networks, you avoid the suboptimal path as well as distribute load for return packets.

> Do I understand right that it is exactly “triangle routing”? Encapsulation in both directions would be needed if you insist on “without triangle routing” or you could delete the requirement.

Since the non-LISP destination in the packet is NOT in the mapping system, the ITR simply forwards the packet and assumes the underlay can deliver it natively. Return packets from a non-LISP source to a LISP destination must be encapsulated because the LISP destination EID IS NOT typically in underlay routing. So the packet follows a default path  or anycasted to the closest PITR that can do the EID lookup in the mapping system and encapsulate to the ETR of the LISP site. And the path from the non-EID to EID may not take the shortest path to the ETR.

Note when LISP-NAT is used as a interworking solution, packets are always sent on the shortest path at the expense of path symmetry between the EID and non-EID.

> 2.       All discussions are in the style that it is “handover”, not “roaming”. “Roaming” has been mentioned 28 times in the draft but it is exactly what was *not* implemented.

To me "handover" means how you do the "roaming". "Roaming" in the context of LISP means the EID binds to a new RLOC-set and therefore roams around the underlay.

> I mean: what if the next RLOC would be from a completely different administrative domain? What if not just link would be switched but Carrier would be switched?

It doesn't matter, encapsulators that have the EID in their map-cache update the RLOC-set and start sending to the new RLOC. LISP really doesn't care how the underlay delivers packets but it can tell when the underlay telemetry changes and can switch RLOCs from an RLOC-set without any coordination with other nodes.

> IMHO: “roaming” is a mandatory case for the word “Mobile” in the title of the draft.

Well in LISP, an entire /16 of EIDs in a data center rack can move at one time. That is mobility but not of a mobile phone which most people assume it to be.

> Please, at least rename “roaming” to “handover” till roaming would be proposed. It is better to be accurate with Mobile terminology.

Handover in LISP would be how short TTLs are used to update RLOC-sets, SMRs are used to update RLOC-sets, and how PubSub is used to update RLOC-sets. And "fast handover" is the convergence time that is better than the term "slower handover" (or "handoff").

> 3.       It has been mentioned that there is a requirement for “multi-homing”, but it has not been discussed at all later.
> IMHO: an additional section is needed to explain how “TCP connections to stay alive while roaming” – probably “multi-homing” should help with this. 

I have said it throughout this email by referring to "RLOC-set". Which means there is more than one RLOC that can reach the EID registered to the mapping system.

Dino