Subject: [DNA] On the BCP documents

From: Pekka Nikander <[email-masked]>
Date: Sun, 07 Nov 2004 15:55:54 -0500

JinHyecok and Sathya,

Greg and I would like to make a few comments related to lengthy
discussion with regard to the proposed BCP draft.

Firstly, we'd like to see the two BCP related drafts,
     draft-narayanan-dna-bcp-01.txt
     draft-jinchoi-dna-cpl-01.txt
to be merged and then adopted as a merged document a
WG item.  Ideally, it would be very nice if you could
do that together.  However, if that appears to be difficult,
it is also possible to create a design team to produce such
a merged document.

Secondly, we don't think that the DNA goals document
should _unnecessarily_ restrict the BCP work.  Our understanding
of our charter is that the purpose of the BCP work is to document
what you can do without changing the current protocols.  In
some cases, such a "solution" may be incomplete or probabilistic,
as long as it does not violate the existing standards.  However, if
the BCP document proposes such "incomplete solutions", it is still
worth to explicitly document their limitations.

--Pekka & Greg

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 08 Nov 2004 21:13:45 +0900

Dear Pekka & Gregg

> WG item.  

Kindly tell me why. I looked through both drafts thoroughly 
and see few benefit to merge them. 
 
I point out the lengthy discusson is entirely about Sathya's 
draft & few word is mentioned on CPL draft. I wonder how 
you come to the merging recommendation from that.    

> Ideally, it would be very nice if you could

I wish we discuss on whether we do this or not first, before 
deciding who will do this. 
 
> should _unnecessarily_ restrict the BCP work. 

I take notice of the word 'unnecessarily'. 

> Our understanding
> what you can do without changing the current protocols.  

I agree. BCP work is to present a way (or ways) to perform DNA 
without standard change. I understand that BCP & Solution aim 
the same thing and 'whether standard change is allowed or not' 
is the main, or maybe only, difference between them. 

> In
 
The reason I raised the issues about BCP draft is NOT that 
it present incomplete solutions BUT that it contains materials 
that are not part of BCP solutions

For example, the draft talks about how a host performs DAD 
after DNA completion. Though I think it would be helpful, 
I don't think that's part of DNA and wish BCP draft focus more
on how to perform DNA without standard change. 

Actually those materials, such as DNA & DAD or DNA or 
bi-directional reachability, concern both BCP & Solution works, 
so I think, for organizational point of view, it would be better 
to present them in a separate draft, not inside BCP. 

Do you still think it's wise for BCP draft to contain those 
materials, such as DNA & DAD?  

Best Regards

JinHyeock

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 08 Nov 2004 09:13:00 -0500

> and see few benefit to merge them.

Well, from a standardisation point of view, it would be nice
if we had a single, nice BCP document.  (Remember, IETF is
mostly about standardisation.)  If I understood correctly
what Greg said, Greg and I think that both drafts represent
nice pieces of work that seem to belong to the BCP space.
Hence, merging them would be good.

A counter point is that if there reasons for having
several documents in the BCP space, e.g., because a single
document would be excessively long, we *can* have several
documents there.  However, even combined, the two documents
are still much less than 100 pages.  Hence, from that point
of view, I don't see a reason why they could not be combined.

Ideally, at least I would like the BCP document to outline
(or specify, or whatever) several procedures that can be
considered BCP.  The applicability of the procedures would
probably depend on what kind of info you get from the link
layer, and on other factors.  For example, if you get reliable
link up and down indications, you may get good enough
results without CPL, using something more simple minded.

Personally, from a deployment point of view, I don't expect
much of the BCP work to be deployed soon.  Some yes, but most
probably any larger deployment will take place together with
the "DNA solution", just to make hosts able to act nicely
independent of whether they enter a network where the
"DNA solution" has been deployed or not.  Most people just
don't update their stack that often.

<snip>

> is the main, or maybe only, difference between them.

I mostly agree, but, personally, I wish that the BCP document
would also explain more the background, and give more information
in that sense.  It does not need to be all normative text.

<snip>

> that are not part of BCP solutions

Well, we can discuss today if the WG agrees with you.  Personally,
I don't see a reason why the BCP cannot explain background,
and reasons why some things are suggested to be done in a certain
way.  In a way, what we are preparing may not be a typical BCP,
but it does not seem to be a Standard either.  It could be even
just Informational, and maybe the IESG changes it to be so.
On the other hand, the goal is to define the community consensus
on how you could (or should) do DNA in existing networks that
do not implement the forthcoming "DNA solution", and hence I still
think that the BCP status looks like the best one.

Due to the variety of networks, stacks, and implementations,
the situation looks like that there is no single one-size-
fits-all procedure, but you may want to do it differently
depending on your conditions.  Hence, to me, it makes sense
to explain and ponder upon these conditions in the BCP,
even if briefly.  Thus, I don't agree with you that all
that is not "part of BCP solutions" should be removed.
But this is just my personal opinion; the WG decides, not me.

> on how to perform DNA without standard change.

As I explained already above, personally I don't seen any need
for such strict focus.  The documents are not multi-hundred-page
ones, at least not yet.  If they grow that large, then there
may be a point to remove some of the stuff.

> to present them in a separate draft, not inside BCP.

Again, personally, I don't see why.  The document is not too long.

> materials, such as DNA & DAD?

Personally, yes.

I guess it may be a good idea to discuss this at the f2f meeting
today.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 08 Nov 2004 10:12:56 -0800

> Hence, merging them would be good.

Perhaps the disagreement is due to different interpretations of 
"merging". While I'm all for producing one BCP document which has 
concrete advise for an implementor, "merging" too mean sounds like an 
editorial task of taking two drafts and editing them into one.

I think both drafts have lots of text which isn't necessary for the 
purpose of providing concrete advise for an implementor.
Thus I think we should take the concrete advise/ideas out of both and 
form a new draft which convers CPL, DAD, MLD, etc.

> in that sense.  It does not need to be all normative text.

Some background is useful so that the reader/implementor can understand 
why the recommendations are the way they are.
But if there is too much to read less people will read the document as 
well. So this calls for some careful balancing.

    Erik

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 09 Nov 2004 04:50:02 +0900

> of view, I don't see a reason why they could not be combined.

I wish that we make decision based on which way, whether single 
or multiple drafts, would be better to present BCP work to reader/
implementers.  

> results without CPL, using something more simple minded. 

Also I would like to specify a few BCP procedures but wonder 
whether it's wise to put them all together in one draft. Aside 
CPL, I can think of, at least, 4 schemes. 

Our team implemented 4 DNA schemes 
1) ECS (Eager Cell Switching), 
- whenever link-layer connection changes, a host assume 
a link change has happened. 

2) NUD like, 
- after a hint, a host probes the current router three times 
with NS and assumes a link change if no NA returns.  

3) 1 NS and timeout 
- similar to 2), but uses 1 NS instead of 3. 

4) RA beaconing.
- A host keeps monitoring current RA messages and if it 
misses a few RAs, it assumes a link change. 

Also we can think of schemes using RS/ RA exchange & timeout. 
So I am afraid there would be too many BCP schemes for one draft. 

We didn't submit a draft but the you can find our results at: 
 
http://www.thinkonweb.com/sait/MD.doc 
 
We also measured 1) MD delay and 2) Error rate of each scheme
on a testbed.  
 
> don't update their stack that often.

I see.
 
> in that sense.  It does not need to be all normative text.

I guess we agree that BCP document can contain some background 
materials but may disagree w.r.t 'How much'. 
 
> But this is just my personal opinion; the WG decides, not me.

We'd better check item by item. Also as long as DNA is properly 
treated, I don't mind including things that don't constitute DNA 
solution, while that's not my taste. 
 
> may be a point to remove some of the stuff.

My point is that it would make a better point to put it in separate 
draft because it concerns both BCP & Solution.  
 
> I guess it may be a good idea to discuss this at the f2f meeting

ok. 

Best Regards

JinHyeock