Markdown Version | Session Recording

Session Date/Time: 12 Nov 2021 12:00

lisp

Summary

The lisp working group meeting at IETF 112 covered updates on existing documents, including the critical Lispsec draft, and presentations on Lisp L2/L3 EID Mobility, Lisp VPNs, Map Server Reliable Transport, and two new use cases for LISP: Lispfix for network sampling and Lisp in Hexagon for vehicle mobility. Key discussions revolved around the status of these drafts, proposed updates, and technical feedback from the chairs and audience, particularly concerning security, document clarity, and adherence to existing LISP RFCs.

Key Discussion Points

• Document Status and Bottlenecks:

  • Several documents are awaiting publication, with Lispsec identified as the primary bottleneck.
  • Luigi is shepherding Lispsec, and Damien is taking over as the editor, with a goal to finish before Christmas. Co-authors are urged to be responsive.
  • The LISP YANG model is nearing readiness.
  • Older working group items require review to determine future publication.
  • Lisp NAT Traversal is a candidate for the last remaining charter item.

• Lisp L2/L3 EID Mobility (Mark):

  • This draft provides methods for a common control plane to support Layer 3 and Layer 2 overlays with EID mobility.
  • Layer 3 Overlays: Focuses on EID mobility, describing data-driven SMR and Pop-Up notifications for updating map caches when EIDs change location.
  • Layer 2 Overlays: Uses MAC addresses as EIDs, dedicates a specific instance ID for L2/L3 separation. Mobility is similar to L3. TTL handling for inner packets should not change. Broadcast and multicast (BoM) traffic utilizes common groups (multicast underlay or signal-free multicast). ARP/ND resolution can be optimized via the mapping system using a dedicated instance ID.
  • Multi-homing (Work in Progress): Proposed using a "segment ID" (or potentially "site ID") to identify multi-homed segments, leveraging merge semantics and map-notify bits.
  • Feedback: Chairs requested clarification on using instance IDs for L2/L3 (configured, not reserved). The document needs to be updated to reference current RFCs (not RFC 6833) and consider Lispsec implications. The use of "site ID" over a new "segment ID" for multi-homing was suggested.

• Lisp VPN (Mark):

  • This draft describes the segmentation of the IP space using Instance IDs and Extended EIDs for control plane procedures and data plane forwarding (unicast/multicast).
  • It addresses cross-VPN communication (extranets) through policy-driven traffic leaking between Instance IDs and introduces "Home ID" encoding for destination IID identification.
  • Multicast extranets leverage signal-free multicast, where the egress XTR performs the Instance ID conversion.
  • The solution is extensively used in practice and has stable code. Authors requested a working group last call.
  • Feedback: Joel Alpern raised concerns about the use of "distinguished names" (afi type 17) without clear definition, potential for collision, and dependency on an unadopted draft (DINOS). Luigi noted the need to update RFC references and discuss potential issues with extranet configuration mismatches.
  • Decision: No working group last call at this time. The document requires revision based on the feedback.

• Map Server Reliable Transport (Mark):

  • This draft proposes moving from periodic UDP registrations to a reliable transport mechanism (e.g., TCP, HTTP, or Quick) between the XTR and Map Server.
  • Motivation: Addresses scalability issues, control plane load, and lack of flow control inherent in periodic UDP for large LISP deployments, high mobility, and inter-system redistribution.
  • Mechanism: XTRs initially use UDP, then establish a reliable session (if supported). The Map Server sends a "Registration Refresh" message to trigger full registration, after which registrations remain active as long as the session is up, eliminating periodic re-sends.
  • It introduces explicit positive/negative acknowledgements and allows the Map Server to actively request information or specific scope refreshes.
  • Request: Adoption as a working group document.
  • Feedback: Chairs requested clarity on how XTRs determine reliable session establishment. Significant security concerns were raised regarding the current authentication methods (TCP/STP options) without a robust security layer like Lispsec, TLS, or Quick security. The draft is expired and needs to be updated.
  • Chair's View: The concept of reliable transport for map registration is valuable, but Lispsec remains the priority.

• Lispfix (Sharon & Aviv Haskell):

  • A non-working group item proposing a LISP-based approach for compute-first aggregation of large data from network sampling (IPFIX), particularly for detecting anomalies.
  • Background: Uniform network sampling combined with AI is proving more effective and efficient than full network probing, especially for threat prediction. However, achieving uniform sampling in large, virtualized, cloud-native environments is challenging.
  • Proposal: Utilize LISP to steer IPFIX traffic to logical EID collectors for uniform, per-application sampling. This involves matching samples to group memberships (e.g., bloom filters, regex) and routing them to distributed analyzers using the LISP overlay. EIDs can hide underlying equipment from analyzers, and the infrastructure provider can handle IPFIX aggregation.
  • Feedback: Questions were raised about the priority of sampled packets and the structure of EIDs to support this use case. The authors seek feedback for drafting version 00.

• Lisp in Hexagon (Sharon):

  • A non-working group item describing LISP's use in production for vehicle mobility (e.g., NYC, Tokyo).
  • Learnings: LISP unifies disparate mobility use cases (vehicle-to-vehicle, vehicle-to-cloud, and intermediate scenarios) through hierarchical and layered EID abstraction of geospatial networks.
  • LISP addresses key industry issues:
    • Dynamic Resource Allocation: Dynamically setting resources for geolocation services transparently using EIDs.
    • Geoprivacy: EID layering provides privacy as vehicle EIDs are ephemeral.
    • Seamless Context Switching: H3EIDs enable seamless transitions when vehicles move between geolocation areas.
    • Maintaining Identity: EIDs maintain vehicle identity across different mobile carriers (not dependent on changing IPs).
  • The authors confirmed that existing LISP specifications provide sufficient flexibility for these use cases without requiring protocol modifications.
  • Request: An indication of the RFC publication timeline was requested due to industry difficulty working with drafts.

Decisions and Action Items

• Lispsec: Damien will take over as editor, working with Luigi, with a goal to finish the document before Christmas. Co-authors must be responsive to changes.
• Lisp L2/L3 EID Mobility (Mark):
  • Action Item: Revise the document to reference current LISP RFCs (not RFC 6833).
  • Action Item: Consider the implications of Lispsec (mandatory to implement).
  • Action Item: Consider using "site ID" instead of a new "segment ID" for multi-homing.
• Lisp VPN (Mark):
  • Decision: The document will not proceed to WG last call yet.
  • Action Item: Discuss the "distinguished names" (afi type 17) concerns with Victor and Dino, ensuring clear definition and collision avoidance.
  • Action Item: Update RFC references (not RFC 6833).
  • Action Item: Add text addressing potential mismatches in extranet configuration/updates.
• Map Server Reliable Transport (Mark):
  • Action Item: Add text explaining the policy or signaling for how an XTR determines it can set up a reliable session.
  • Action Item: Significantly enhance security considerations to include Lispsec, TLS, or Quick security.
  • Action Item: Update the expired draft and its references.
  • Implicit Decision: Adoption as a WG document is on hold until Lispsec is finalized and the document itself is revised.

Next Steps

• Authors of Lisp L2/L3 EID Mobility, Lisp VPN, and Map Server Reliable Transport are to revise their drafts based on the feedback and action items from this meeting, with particular attention to updating RFC references and addressing security concerns.
• The Lispsec document remains the highest priority to unblock other publications.
• The Lispfix authors will continue to gather feedback for draft-00 of their proposal.
• The working group will await updates on the RFC publication timeline for Lisp in Hexagon.
• The next meeting will likely revisit these documents, contingent on the progress of Lispsec.