[DNA] Re: On the BCP documents

[JinHyeock Choi <jinchoe@gmail.com>]

> >> 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.
> >
> > Kindly tell me why. I looked through both drafts thoroughly
> > 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.

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.  

> 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. 

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.  
 
> 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.

I see.
 
> <snip>
> 
> > 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.
> 
> 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.

I guess we agree that BCP document can contain some background 
materials but may disagree w.r.t 'How much'. 
 
> <snip>
> 
> > 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
> 
> 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.

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. 
 
> > 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.
> 
> 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.

My point is that it would make a better point to put it in separate 
draft because it concerns both BCP & Solution.  
 
> > 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.
> 
> Again, personally, I don't see why.  The document is not too long.
> 
> > Do you still think it's wise for BCP draft to contain those
> > materials, such as DNA & DAD?
> 
> Personally, yes.
> 
> I guess it may be a good idea to discuss this at the f2f meeting
> today.

ok. 

Best Regards

JinHyeock