Subject: [lisp] LISP IETF-74 Meeting Minutes

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 6 Apr 2009 09:45:45 -0700

Hello,

Bellow are the meeting minutes for the San Francisco IETF.  The deadline
for comments is 4/20/2009.

-Darrel

-----------------
-- LISP BoF - IETF-74
- Chairs Darrel Lewis/Sam Hartman

jabber: [email-masked]

1) Agenda Bashing - Darrel Lewis

  no additional agenda info

   Introduction by Jari about status of WG, while it isn't officially
    formed, his view is the time is better spent as a WG than a BoF.
    Wasn't time to complete WG formation process prior to the meeting in
SF, 
    the final decision of WG status by the IESG is pending.

2) Charter Discussion - Sam Hartman
  Sam Hartman -
    Accurately describe what LISP separates
      EID/LOC split discussion
    Changes -
    End Site Identifier vs End System Identifier
    Discuss end host changes are out of scope
    Focus on incremental deployability

    Concerns -
      endsite-identifier problematic
      idenitify vs identifier (multiple interfaces no a single system)

  (skipping ahead by co-chair)
    Charter(3)
    question from the floor - 'Global portion and local portion' is
confusing
                              Perhaps re-word this away from 'global'...
                              Discussion of Noel's email about the
charter
    Comments on whether the listeners think this should be chartered as
a WG
      ietf-list

    Quesiton from the floor - HIP interrelationship/interworking with
this WG
    Answer - HIP is focused on the end-station, forcing host-based
changes at
             the expense of router changes (not changing
routers/routing)

    Comment from the floor - Identify in HIP vs Identifier in LISP,
                             can we use different terms for this? There
is
                             term collision, which is confusing.
    Chair - Focus please on how the charter is unclear, not how wording
isn't
            clear.
    Comment - HIP/LISP id/loc split is nicely sited in the Charter's
link to
              the IAB document about id/loc split
    Chair - Perhaps HIP == host-based loc/id split
                    LISP == network-based loc/split

    Comment - Please accurately describe 'what we are doing', attempt to
reach
              consensus on terminology and charter.

3) LISP Draft review - Dino Farinacci

  current draft discussions -
    draft-farinacci-lisp-00.txt - 01/2007 - fallout from the 2006 IAB
Workshop
    draft-farinacci-lisp-01.txt -
    draft-farinacci-lisp-02.txt - editorial changes
                         03.txt - clarified for both AFI's
                         04.txt - mobility considerations
                         05.txt - added control/data ports + ALT
discussion
                         06.txt - defined data-probes + MTU + referenced
                                  external docs (see slides)
                         07.txt - More clarification of EID, added
multicast
                                  support
                         08.txt - 04/2008 - more discussion on EID
                         09.txt - 10/2008 - clarification on EID-prefix
                         10.txt - 11/2008 - added traceroute bits,
indicated
                                  where LISP could run
                         11.txt - 12/2008 - added stateful + stateless
MTU
                                  considerations
                                  (Question on MTU pushed to end)
                                  clarified where this should be used,
small
                                  multi-homed sites
                         12.txt - 03/2009 - talk about map server cache
state
                                  issues
     Doc Status -
       Fairly Stable, implemented 1.5-2 full systems, packet format is
stable
       Possibly adding network management fields, as-name/as-number
     Open policy - LISP is open, no IPR claims, all volunteer effort
from
       vendors/ops/researchers/inventors
     Peer review from many external folks
       (Noel/Vint/DaveClark/PaulMockapetris/LenBosack)

  MTU Issues/Questions -
    Stateless case - DF=0 means we can't drop the packet, must handle
                     Frag packet, pass along to the end for reassembly
    In the end, the MTU discussion needs more work, please move to list.

  HIP vs LISP discussion, how does HIP deal with ipv4 - HIP Proxy
    being pushed to move along away from HIP discussion(s)
  Chair - Looking for reviews from: Transport, HIP, Security ... at
least

4) What is LISP+ALT - Vince Fuller

  Split of what namespaces are used where:
    EID - local site
    RLOC - Internet-at-large
    Mappings of EID -> RLOC happen at the ETR (Egress Tunnel Router)
  Discussion of the LISP+ALT workings (see animated slides)
  Document History - 11/2007 -> current
                     Spec stable since 10/2008
                     Working code today on NXos systems with 6+months
                       of testing/experimentation on live network.
  Need more implementations, more testing, more experimentation
  Need to discuss at least: cache in ITR, negative cache replies

  What further review do we need/want here:
    Focus on completion of this WG/BoF focus on LISP+ALT only
    Security focus on LISP, ALT and the entire LISP+ALT system
      map-replies/map-requests have alternate security implications

5) LISP Map Server Draft discussion - Vince Fuller

  draft-fuller-lisp--ms-00.txt

  Eliminate ALT complexities in xTR's
  Map-Servers are co-located in the LISP-ALT routers, not required
though.
  Map-Server/Map-Resolver -
    Resolver accepts Request from ITR to make the EID-to-RLOC mapping
    Server accepts request from the ALT, forwarding that to the ETR.
  ETR's are still authoritative for EID-RLOC mappings
    Map-Server is now a cache-layer
    See slides for illustration(s)
  For Future work -
    Negative caching (cache-management in general)
    caching in map-resolvers
  Questions about pushing this into a WG draft vs more individual works
    For ALT + MapServer: Some consensus to move this to a WG Draft
  Questions about 'is this a BoF or a WG?'
  More discussions about 'experiment before direction/decision' vs
                         'direction decision before experimentation'
  Incremental changes to current techniques, focus on less complexity
  Evaluation of complexity is possible says Dave Oran, forthcoming
message
    to the list about measuring this.
  Jarri clarifies - BoF slot, the slot being run as a WG.

6) Interworking Mechanisms - darrel lewis
  draft-lewis-lisp-internetworking-02.txt
  Proxy Tunnel Routers (PTR)
    Originates few EID prefixes
    traffic is assymetrical
    ingress only
    allows lisp sites to see benefits of ingress TE immediately
    Placement as close to the traffic-source == less stretch
  LISP-NAT - this is still NAT, that's good and bad, possibly useful for
    broadband interworking deployments
  Status/further-work
    PTRs and uRPF considerations
    Should work come for Broadband interworking?
    LISP-NAT for IPv6 as well?
    PTR behaviours and scaling - anycast? implementations in hardware?
                                 cache-management concerns and testing
  External Reviews - general security reviews?
                     review by 6to4 implementors as well
  Call to bring this into a WG document.

7) LISP Multicast - dino

  draft-farinacci-lisp-multicast-00.txt - 04/2008

    Result is a simple procedural change to PIM
  (S-EID,G) in reciever domains
  (S-RLOC,G) in core
  -01 posted 11/2008
  No current implementations
  Need expert mcast implementor review
  Presented in PIM + MBoned WGs.
  Call for picking this up as a WG doc

- Chair Sucker Search - Sam
  Securing the Mapping System - draft necessary
    2 callers interested
  Security Analysis of LISP/ALT
  Network Management

8) LISP Mapping Versioning - Luigi Iannone

  Requirement for versioning of the Mapping database
    see slides for animation(s)
  Use this as a method to find unauthorized path generation in the
mapping
    database (drop on version larger than currently known version)
  Use this as a method to update the end site mapping databases
    (notify on version lower than currently known version)
  Accept benign version equality
  Today we have SMR + Reachability bits already in LISP
    Reachability Bits - hints, when these change, require map-request to
be sent
    SMR - 
  With versioning though - in the data-plane we can know directly when a
map
    request is required, less control-plane complexity, push this
complexity
    to the data-plane processing
  Data driven updates to the mapping database, no monitoring required at
all 
   xTR devices.
  (more illustrations/animations - see slides)
  Alternate LISP Header changes potentially to enable the version
marking
  Comments -  
    Dino - what about alt-4 - nonce overload
    DaveOran - linkstate mapping overloaded onto the LISP Mapping
               keep in mind what has come before - isis linkstate issues
    Dino - clarifications on terminology
  Call to WG adopt this?
    More discussion on-list required at this time.

9) Next Steps / Open Discussion

  Discussions on applicability, deployability, status of the 
    WG/BoF/whatever-this-is-today
  Management vs MIB work, where can you see all the parts that are
    important.
  Possibility add instead of 'Network Management' - Operations +
Management
  Impact on upper layers 

  Dave Harrington - OpsAWG WG Doc to think about management of the
protocol

  Discussion of rate + state based on huston-graphs/data
    This looks to address 'state' but not 'rate'
    dino - 'rate' addressed at the first ISP & aggregation of RLOC space

10) End Early

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 7 Apr 2009 16:57:32 +0200

Hi,

just one comment inline.

On Apr 6, 2009, at 18:45 , Darrel Lewis (darlewis) wrote:

[snip]
>    request is required, less control-plane complexity,

I said that.

> push this

I did not said this. The complexity on the data-plane is the same like  
SMR+ReachBits.

But thanks, this is another point to clarify in the next version of  
the draft, to be discussed on the list.

Cheers

Luigi

>    More discussion on-list required at this time.

[snip]