1 / 11

LISP-NERD RRG (IETF 69)

LISP-NERD RRG (IETF 69). Eliot Lear. NERD is…. A Not-So-novel EID to RLOC Database A signed set of mappings A suggested initial distribution mechanism- HTTP A push model approach draft-lear-lisp-nerd-01.txt. Guiding Principles and Assumptions.

flint
Télécharger la présentation

LISP-NERD RRG (IETF 69)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LISP-NERDRRG (IETF 69) Eliot Lear

  2. NERD is… • A Not-So-novel EID to RLOC Database • A signed set of mappings • A suggested initial distribution mechanism- HTTP • A push model approach • draft-lear-lisp-nerd-01.txt

  3. Guiding Principles and Assumptions • This is provisioned data - it is relatively static • There is some “other” means to communicate operational state changes • In-flight packet loss or delay is bad for applications • The data does not change from hop to hop • We are scaling to between 107 and 108 mappings (2050) • Beg, Borrow, Steal • PKI works best with few signers and many verifiers - sign once and don’t care about path

  4. NERD Process: Getting The Database to Authorities • There exists one or more database authorities that manage mappings for some portion of the EID address space • The end user communication to these authorities is similar to that of name service registrars • NERD database authorities collect and validate mapping requests • Authorities then produce a SIGNED database of entries, as well as a SIGNED set of changes from previous versions

  5. NERD Process: Getting the data to ITRs • When ITR boots first time it retrieves a full copy of the database via HTTP • Caches are strategically placed and common CDN technologies are used to direct request • ITRs periodically request updates through same CDN • Optionally an ITR can request via its BGP neighbor or from a configured source the database and updates

  6. ITR ITR ETR Pictoral Sign-and-push netnews Authority http server http cache ??? P2P Pull to Site Pull to Site Register RLOCs admin

  7. Some Sloppy Math 16 bytes for first RLOC 8 bytes for each Additional RLOC

  8. With That In Mind

  9. What Does That Mean? • A daily 0.1% of 720MB change using just 100 servers takes 24 seconds to transmit on 1gb wire

  10. Use of a PKI • Makes some operators shake in their boots • This is not the common use • Allows for separation of data format from distribution mechanisms • By default can be hidden from operators

  11. Questions • Do we really need a “pull model” given the amount of data? • How many sources are there really? • Who can be those sources? • Who owns the mapping? • Can we mix and match NERD with other things?

More Related