Subject: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for?

From: Greg Daley <[email-masked]>
Date: Fri, 15 Jul 2005 15:41:51 +1000

Dear WG,

At the moment, there are two documents aimed at providing input
to the DNA solutions process:

draft-pentland-dna-protocol-00.txt
draft-jinchoi-dna-protocol2-00.txt

It seems that the primary focus of difference between these
two proposals is in Link Identification.

Therefore, I'd like to look into the existing proposals to
extract what are the agreed components which the WG believes
are necessary regardless of the solution.

In this way I hope to build most of the solution, in a way
which allows a "drop in" of the agreed Link Identification
solution, when agreement is reached on that issue.

Does that sound reasonable?

Here are a list of steps which I guess may be agreeable for
the WG as components of the general DNA solution.

Requirement Levels and message contents are ignored unless explicitly
stated.

Please tell me if you agree that this is a reasonable set of
general components required for DNA, without exploring Link
Identification.

Please indicate if there are components which you think are missing
from the general DNA solution, or items present in the list which
you don't agree with:

1. Link-Layer indications on hosts

    Use of "Link-Up" indications as in draft-ietf-dna-link-information,
    in order to start DNA operations

2.  RS transmission upon Link-Up indication

    Transmission of an RS with an Optimistic Source Address when a
    Link-Layer indication is received.

3. Unicast Solicited RA Delivery

    Delivery of Solicited RAs to unicast addresses by default,
    in order to avoid MinDelayBetweenRAs (or MIN_DELAY_BETWEEN_RAS)
    timers.

4. TSLLAO in RSs with Optimistic Addresses

    Where an RS is sent from an Optimistic Address, Tentative Source
    Link-Layer Address Options are used in order to allow for
    unicast response from the router without using Neighbour
    Discovery (NS/NA exchange).

5. Hash Ordered FastRA delivery

    When unicast solicited RAs are scheduled, ordering is worked out
    amongst DNA routers to ensure one responds immediately, and other
    routers do not collide with the scheduling

6. Token Bucket Rate Limiting of FastRAs

    Rate limitation of RA delivery is undertaken in order to prevent
    overload of wireless media.  A token bucket is used to allow
    no more than TOKEN_RATE FastRAs to occur per interval, and
    limit the burst size.

7. Where received RAs do not provide explicit Link Identification,
    Complete Prefix Lists (draft-ietf-dna-cpl-00)  are used.

    Regardless of the DNA solution's LinkID choice, it is likely that
    DNA hosts will encounter networks without DNA routers.   Where
    a host is present on a non-DNA network, existing CPL rules should
    be applicable.

----------------

This leaves the role of Link Identification, which may interact
with the above measures, but is still for discussion.

Please provide feedback regarding this list, it would be good to know
what we agreed was needed in a general DNA solution.

Greg

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 15 Jul 2005 11:58:55 +0530

Hi Greg,

> two proposals is in Link Identification.

The later draft is just focuses on the link identification method
which can be taken into the former document if WG chooses.

> Does that sound reasonable?

Yes, this looks reasonable.

>    in order to start DNA operations

Link Up indication may not be available with all implementations.
A host should also be able to start DNA if it has any other indication.
However I agree that we should use LinkUp when available.

Rest of the list looks goo to me.

-Syam

---

From: James Kempf <[email-masked]>
Date: Fri, 15 Jul 2005 08:32:05 -0700

> Does that sound reasonable?

Sorry, but no. I think we ought to do a concensus call on which of the two
the WG wants and make a decision. There's little point in delaying any
longer.

        jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 18 Jul 2005 13:05:51 +1000

Hi James,

> the WG wants and make a decision. There's little point in delaying any

I guess you think that the other parts don't require discussion
(as they are agreeable...???)

I'm not really interested in delaying determination of the solution
either, and want to see if there's consensus before the meeting.

That means that we need to see what people understand about the solution
(even outside those who have been so active in the design area).

If you'd like to start an on-list discussion about the Link
Identification, it would be possible to start a consensus call.
We'd need two weeks to conduct the consensus call (as per RFC2418
section 3.3).

Given the time left until the IETF meeting (and our projected Thursday
session) it would be possible to either run the consensus call to end
before the session, or after it:

July/August:
S  M  T  W  T  F  S
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31  1  2  3  4  5  6

I'd prefer that a consensus call allows presentation of ideas in the
session, if there's not a strong consensus position apparent beforehand.
At the session, we could redirect people to the ML in order to
participate in the call to ensure that their input isn't lost.

I'll take input on this today and tomorrow, in order to allow some
flexibility in the choice of solution (to discuss whether people think
the consensus call should end before or after the session).

WG: Please start discussion of Link Identification solutions ASAP, so as
to assist building consensus.

Greg

---

From: James Kempf <[email-masked]>
Date: Mon, 18 Jul 2005 08:52:35 -0700

> (as they are agreeable...???)

I'm in favor of discussion of issues. DNA has an issue list, I think an
email on each individual issue should be sent out, a time limit sent for
discussion, and, at the close of discussion, consensus should be called on
the issue. In other WGs, the draft editor or a WG chair manages issue
resolution.

> We'd need two weeks to conduct the consensus call (as per RFC2418

I'll be offline until the meeting starting on Sat.

BTW, I think the consensus call in RFC 2418 means for the entire draft, not
individual issues. WG chairs and editors are free to set their own time
limit there,

> before the session, or after it:

OK. I think it would help to have this as an issue in the issues list, and
on the issues Web page.

            jak

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 19 Jul 2005 18:04:53 +0900

Dear Greg

Thanks for your trouble advancing DNA solution. 

I think that there are a few missing components in your list. 
Framework draft presents the solution components as below,   

3.1  Solution components

   1. RA message optimized for DNA, which 1) properly indicate link
      change and 2) carries necessary information for a new IP
      configuration.

   2. A way to quickly deliver an RA to a host upon a new link-layer
      connection.

   3. Optimistic DAD [17] and TSLLAO [18] that is being specified in the
      IPv6 WG.

   4. A procedure to apply DAD during the DNA procedure that is both
      efficient and safe should there be a duplicate.

   5. A procedure for MLD so that the multicast groups are reported on a
      new link.

   6. A procedure that handles DHCPv6 address (and other) configuration
      for those cases when stateless address autoconfiguration is not
      used.

Though your list properly deals with 2, 3 and link identification, it doesn't 
include 1, 4, 5, 6. 

Especially I'd like to mention 1, RA optimized for DNA. 

In case a host is attached to a different link, it would be useful for 
the first RA message to include the necessary information to initiate 
a new IP configuration. I think we need to consider what kind of 
information the RA should include. We think that 

the RA should include 
   1) The information to indicate link change
   2) Router address (to select new default router, in case of a link
      change)
   3) Prefix(es) (to form a new IP address, in case of a link change)
   4) Link-layer address of a router (to immediately send a packet)

and the RA would better include 
   1') A global IP address of a router
   2') All prefixes that the router advertises

I'd like WG look this over to reach an agreement.  

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock