Simple DNA

1
Simple DNA

• draft-ietf-dna-simple-05
• Suresh Krishnan
• Greg Daley

2
Status

• Most issues have been resolved
• One major issue remains. Resolving this will
  resolve another newly raised issue.
• Received several reviews
• Bernard Aboba, Julien Laganier, Domagoj Premec,
  Jin Hyeock Choi and Alfred Hoenes reviewed the
  document and provided comments (Thanks!)
• Issues being tracked at the issue tracker
• http//tools.ietf.org/wg/dna/trac/report/9 lists
  all issues (both open and closed)
• http//tools.ietf.org/wg/dna/trac/report/1 lists
  open issues

3
Issue 8 Describe identification model of simple
dna

• ISSUE Previously DNA relied on link
  identification. So a host verifies all addresses
  (and IP parameters) at a stroke. However Simple
  DNA aims to verify IP address (and IP parameter)
  per router. I propose we write down the change
  clearly.
• SUBMITTER Jin Hyeock Choi
• STATUS Resolved
• RESOLUTION Added text to indicate that describes
  the router probing based identification model for
  Simple DNA. Also clarified that this is different
  from the model followed by complete dna.

4
Simple DNA Identification model

• Earlier methods of detecting network attachment,
  e.g. the procedure defined in I-D.ietf-dna-protoc
  ol, relied on detecting whether the host was
  still connected to the same link. If the host was
  attached to the same link, all information
  related to the link such as the routers, prefixes
  and configuration parameters was considered to be
  valid. The Simple DNA protocol follows an
  alternate approach where it relies on probing
  each previously known router to determine whether
  to use information learnt from THAT router. This
  allows simple DNA to probe routers learnt from
  multiple earlier attachments to optimize movement
  between a known set of links.

5
Issue 9 Detailed description of ND packets

• ISSUE Simple dna needs to document a detailed
  description of the contents of ND and RS packets
  (such as included options, and source/dest
  addresses).
• SUBMITTER Bernard Aboba
• STATUS Resolved
• RESOLUTION New section 4.5 added that describes
  the contents of the ND packets (NS and RS) sent
  out by the Simple DNA process.

6
Issue 10 Pseudo Code

• ISSUE It would be helpful to have some pseudo
  code describing the simple dna process.
• SUBMITTER Jin Hyeock Choi
• STATUS Resolved
• RESOLUTION Pseudo code has been added to a new
  section in the Simple DNA draft (section 6)

7
Issue 11 Applicability statement

• ISSUE This document needs an applicability
  statement that describes the scenarios under
  which it is useful.
• SUBMITTER Jin Hyeock Choi
• STATUS Resolved
• RESOLUTION New section containing the
  applicability statement (section 2.2) has been
  added. The old applicability section (badly
  named) has been moved to a new section called
  Working assumptions (section 2.5).

8
Applicability Statement

• The Simple DNA protocol provides substantial
  benefits in some scenarios and does not provide
  any benefit at all in certain other scenarios.
  This is intentional as Simple DNA was designed
  for simplicity rather than completeness. In
  particular, the Simple DNA protocol provides
  maximum benefits when a host moves between a
  small set of known links. When a host moves to a
  completely new link that is previously unknown,
  the performance of the Simple DNA protocol will
  be identical to that using standard neighbor
  discovery.

9
Issue 12 When to perform DAD

• ISSUE Simple DNA should describe the conditions
  under which DAD should be performed.
• SUBMITTER Erik Nordmark, Bernard Aboba, Jin
  Hyeock Choi, Dave Thaler
• STATUS Open
• RESOLUTION Need a discussion

10
Issue 13 Include SLLAO

• ISSUE We need to include SLLAO in the NS probes
• SUBMITTER Bernard Aboba
• STATUS Open
• RESOLUTION Can be resolved right after we agree
  on the DAD text. The only reason for a node to
  not include an SLLAO is that it has not performed
  DAD on the address.

11
Way forward

• Any more open/outstanding issues?
• Not aware of any but feel free to raise them
• Reviews
• Do we need wider reviews of this document
• Implementer feedback
• Host/router vendors who have plans to implement
  this proposal
• Progressing the document
• Before the next IETF meeting if everything goes
  well