Subject: [DNA] DNA Protocol vs. Protocol 2

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Tue, 14 Jun 2005 20:20:41 +0900

Hello folks, 

In my understanding, Brett and Jinhyeock documents
seem to achieve the same goal. I am just curious
to know of why we need two documents not merged
one. Is there any internal decision from DT ? 

To me, a single document seems mostly like an 
appropriate approach...

Regards,
---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> JinHyeock Choi
> Sent: Saturday, May 28, 2005 9:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [DNA] [New I-D] DNA Solution: Link Identifier based approach
> 
> 
> Dear DNA Group
> 
> We submitted the following draft as a solution work. 
> 
> DNA Solution: Link Identifier based approach
> draft-jinchoi-dna-protocol2-00.txt
> 
> As Brett mentioned, two approaches were discussed 
> in DT, Landmark based & Link Identifier based. 
> 
> The draft presents the second one and describes how
> to check for link change with the prefix based linkid.   
> 
> Routers pick the smallest prefix as the linkid prefix and 
> include the linkid prefix in every RA. In short, if a host 
> sees the same linkid prefix, it is at the same link and if it 
> sees a different linkid prefix, it has moved to a new link.  
> 
> This document is available at the URL:
> 
> http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-00.txt
> 
> We are looking forward to your feedback.
> 
> Best Regards
> 
> JinHyeock Choi
> 
>

---

From: James Kempf <[email-masked]>
Date: Tue, 14 Jun 2005 08:34:07 -0700

Actually, the two documents contain protocols that are designed to solve the
same problem in two completely different ways. So I don't think it is a
matter of merging them, I think one or the other must be chosen.

WG chairs, do you have any thoughts about how the decision on this will be
made? Will we try to make a decision prior to the IETF meeting through
discussion and s concensus call on the list, or do you want to wait until
the meeting and have presentations on each proposal, then a straw poll?

            jak

---

From: Syam Madanapalli <[email-masked]>
Date: Wed, 15 Jun 2005 13:22:01 +0530

I think it is better to split the DNAv6 draft into three
1. Link Identification
2. Fast RA
3. DNA Procedure or Operation
 This way it is easy to understand and implement. This will also
help WG to better understand about each method that is solving
a particular problem.
 -Syam

---

From: Brett Pentland <[email-masked]>
Date: Wed, 15 Jun 2005 18:29:43 +1000

All three of these are parts of a DNA solution and to me they are
just sections of a single document.  Having three separate documents
adds overhead, but I don't really see it adding much value.

I might make sense to break it into three if we want to be able to
pick and choose bits and pieces but then we end up with all sorts of
interoperability problems.  I think it's better as a single document,
and if clarity is a problem, then that probably just indicates that
the document needs some reorganisation.

Brett.

---

From: Sathya Narayanan <[email-masked]>
Date: Wed, 15 Jun 2005 10:55:33 -0400

I agree with Brett.

The first draft produced by the design team, 
http://www.ietf.org/internet-drafts/draft-dnadt-dna-discussion-00.txt, 
discussed different solutions for the two components of DNA (Link 
Identification and FastRA) individually. Splitting the solution now will 
be a step backwards.

thanks,
Sathya

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 16 Jun 2005 12:42:39 +0530

Hi Brett,

> adds overhead, but I don't really see it adding much value.

What I was thinking is that these three can be used individually, one can
implement just Fast RA on routers, may be for other purposes.

> interoperability problems. 

I said 3 drafts but a single solution for now as a solution of the DNA
WG. These drafts will address different issues of DNA. There will
not multiple solutions that solves the single problem.

> I think it's better as a single document,

This just a thought, everybody feels that single document is good, then
it is fine with me. When I read the DNAv6 first I felt it is very complex,
as it is solving multiple issues.

And may be we can improve the clarity of the document by reorganisation.

---

From: Brett Pentland <[email-masked]>
Date: Thu, 16 Jun 2005 18:23:39 +1000

> And may be we can improve the clarity of the document by reorganisation.

I'm open to suggestions.  What sort of reorganization would help?

As it stands, section 3 is an overview and it clearly breaks the problem
down into separate sections:

    3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      3.1   What Identifies a Link?  . . . . . . . . . . . . . . . . .  6
      3.2   Link Identification  . . . . . . . . . . . . . . . . . . .  6
      3.3   Fast Router Advertisment . . . . . . . . . . . . . . . . .  7

Section 5 goes into the details of what each device has to do to solve
both problems:

    5.  DNA Operation  . . . . . . . . . . . . . . . . . . . . . . . . 11
      5.1   DNA Router Operation . . . . . . . . . . . . . . . . . . . 11
        5.1.1   Data Structures  . . . . . . . . . . . . . . . . . . . 11
        5.1.2   Router Configuration Variables . . . . . . . . . . . . 12
        5.1.3   Bootstrapping DNA Data Structures  . . . . . . . . . . 13
        5.1.4   Processing Router Advertisements . . . . . . . . . . . 13
        5.1.5   Processing Router Solicitations  . . . . . . . . . . . 13
        5.1.6   Complete Router Advertisements . . . . . . . . . . . . 15
        5.1.7   Scheduling Fast Router Advertisements  . . . . . . . . 15
        5.1.8   Scheduling Unsolicited Router Advertisements . . . . . 16
      5.2   DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16
        5.2.1   Data Structures  . . . . . . . . . . . . . . . . . . . 16
        5.2.2   Selection of a Landmark Prefix . . . . . . . . . . . . 17
        5.2.3   Sending Router Solicitations . . . . . . . . . . . . . 17
        5.2.4   Processing Router Advertisements . . . . . . . . . . . 17

Is this general structure ok (just needing some reorganization within
sections)?

Brett.

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 16 Jun 2005 14:54:42 +0530

Over all the TOC is okay, what I was mentioning is about the content
of the sections.

>      3.3   Fast Router Advertisment . . . . . . . . . . . . . . . . .  7

Can we describe these 2 completely in this sections? Meaning, can we
for example, just replace the Link Identification method with some other 
approach?

---

From: James Kempf <[email-masked]>
Date: Mon, 20 Jun 2005 09:30:44 -0700

I disagree.

The problem is that someone wanting to implement the protocol would have to
track down each draft and figure out how they fit together. We went through
exactly the same debate in the MIP6 bootstrapping DT, and decided against
splitting the draft because it would make the task of figuring out how the
protocol worked more complicated. It is hard enough just following up on
references in IETF documents, by having to do searches on the clumsy IETF
Web site, much less having to do the same thing for the protocol spec
itself.

Now, if the IETF used modern hypertext-based documentation technology,
rather than antiquated ASCII files, to publish its specifications, I would
have completely the opposite opinion. However, we're stuck with ASCII for
now, unfortunately.

            jak

----- Original Message ----- 
From: "Syam Madanapalli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Soohong Daniel [email-masked]" <[email-masked]>; "JinHyeock
Choi" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 15, 2005 12:52 AM
Subject: Re: [DNA] DNA Protocol vs. Protocol 2

---

From: James Kempf <[email-masked]>
Date: Mon, 20 Jun 2005 10:18:15 -0700

> for example, just replace the Link Identification method with some other

No, I think the protocol needs one link identification method. That means,
as difficult and painful as it may seem to the WG, we need to choose between
the two drafts.

            jak