[DNA] RE: DNA Goals Issues

["Bound, Jim" <jim.bound@hp.com>]

Hi JinHyeock,

> Thanks for your detailed comments. I like your opinion about 
> disagreement 
> and also will try that we disagree in an agreeable way. :-)  

But of course and one cannot read into email unless it is rude and best
to take it as android discussion in cyberspace.
 
> 
> I understand that you propose that the parts of Goals drafts
> 1) be removed and
> 2) be made a separate draft, if possible. 

Correct.

> 
> After clarifying the parts to be removed with your 
> confirmation, I will start threads about whether we remove it or not.

Thanks
 
> 
> I ask chairs whether the separate draft is possible. 
> 
> It's ok for me to remove the parts of the draft that WG does 
> not consider indispensable. For me, The less the better. 
> 
> I only wish you gave this input when I submitted the previous 
> version. That would have saved lots of my efforts. 

We are all very busy and we do the best we can I have had this happen to
me on drafts too.  Also be prepared during a last call people will catch
things that were not objected to before most likely.  It is the nature
of our community culture and mostly because we who contribute are just
very busy.

> 
> Also there are a few statements that we disagree on their validity. 

Do you mean you or "we"?  Or I may misunderstand your sentence above.
  
> 
> To break a deadlock to speed up the process, I request 
> reviewers (Greg & Pekka) to express their opinions on the 
> contending issues. 
> The draft went through reviewing process more than 2 months.  

Time is important but 2 months is not long and we must take time to get
this right for our goals.
The IPv6 rhetoric is completely unecessary IMO.

> 
> Kindly find my in-line comments.

I took liberty to remove where no response by me is required.


> You propose that the parts of Goals drafts
> 1) be removed and
> 2) be made a separate draft, if possible. 
> 
> I'd like to clarify the parts you suggest to be removed from 
> Goals drafts. 
> I understand the parts to be removed are 
> 
> 1. Seconds paragraph of Abstract
> 
>     Rapid attachment detection is required when a host has 
> on-going data
>     traffic.  Current DNA schemes are inadequate to support real-time
>     applications.  The existing procedures for advertising network
>     information incur reception delays and do not provide enough
>     information to properly determine the identity of links.  For
>     to-be-defined, efficient DNA schemes, a way to correctly 
> represent a
>     link change, a complete and consistent procedure for network
>     information advertisement and a rapid delivery of the 
> advertisements
>     will be necessary.
> 
> 2. All of Sec 2 DNA in Existing IPv6 Systems except the following two.
> 
>     Though the set of all the assigned prefixes may be used 
> to represent
>     a link identity, it is difficult for a host to attain and 
> retain all
>     the prefixes with certainty.  Moreover there may be  links without
>     any advertised prefix.
> 
>     (Jim's comments: Turn the above into a goal and suggest things to 
>     look for in the goals.)
> 
>     Hence, to check for link change, as of today, a host must 
> resort to
>     guessing, based on Router Discovery and Neighbor Unreachability
>     Detection (NUD).  A host can examines whether 1) its 
> existing default
>     router is still reachable and 2) its IP addresses are still valid.
> 
>     (Jim's comments: I can know I am on a new link from the 
> link layer 
>     and physical layer for WiFi, 3G, etc..Ethernet MACs are new. The 
>     answer could be a new field in those layers and maybe we 
> should look 
>     at that and talk with IEEE?)

Above is correct of my view.

> 
> But your opinion about 'Sec 3 Problems in DNA' is not 
> entirely clear to me. 
> Kindly notify me whether you suggest that
> 1) we remove the section altogether or
> 2) we modify the section.

This section is not appropriate for goals.

 3.2 The Inadequacy of RA information 

Anything that discusses any thing other than general technology should
be remove IMO esp. RA and RS statements.
 
> 
> > > We thought that it would be useful for Goals draft to 
> include some 
> > > analysis but you seemed to disagree. Right? Kindly 
> confirm yourself.
> > 
> > I NEVER said that please do not put words in my mail.  I 
> never said no 
> > analysis is not required I said stating what is wrong with 
> IPv6 in an 
> > IETF permanent document (in other words before) is 
> inappropriate in a 
> > goals document.  It is to important for documentation and this WG 
> > process.
> 
> Some analysis may be inappropriate for the goals drafts. But 
> I suspect many of them are plain wrong (conflicting with 
> facts). But I suggest that we concentrate on deciding whether 
> a statement to be included or not in the draft, rather than 
> arguing over whether it is valid or not. If the inclusion 
> decision depends on the validity, then we may argue about validity. 

I don't agree.  My point is not validity but rather the appropriate
venue for discussion of current IPv6 operatioins and that is not the
point of a goals draft.
 
> 
> > > The second part is more about analysis. In case WG decide 
> to do away 
> > > with the analysis, we will make a modification accordingly.
> > 
> > I am trying to follow IETF status quo and rules of engagement.  I 
> > don't know of a single document that has two paragraphs in the IETF 
> > for the abstract?  If I am wrong I simply have not seen it 
> and review 
> > many documents in the IETF.
> 
> I thought that, instead of one long paragraphs, two short 
> ones are easier to understand. 

I personally don't agree and like the way all drafts are currently
except this one does it in the IETF.  The key is to be able to state the
draft objective in one paragraph and do it in concise manner.

> 
> > > The host only changes it's link-layer connection. It's 
> not certain 
> > > whether it moves to a new link or not yet.
> > 
> > Hmm terminology issue.  If it changes its link connection it either 
> > has moved or on two different links.
> 
> Yes, terminology is confusing. Kindly take notice that the 
> host changes its link-layer connection, NOT link connection. 
> I differentiate 'link-layer connection' and 'link connection' 
> and avoid the second term entirely.  

That is a good idea to remove that term.  Also note that this brings up
interesting point.  The host could hear new link-layer connection and
still want to keep the existing link-layer connection.  I am on UTMS and
also can pick up WiFi connection entering a meeting room.

> 
> A host can change its link-layer connection without neither 
> moving to a new link nor being on two different links at the 
> same time. 

Agreed.

> 
> > Hearing both links is an interesting
> > property of seamless mobility and requires analysis as a 
> goal for this 
> > WG so I now suggest adding that as a goal.

I agree.

> 
> A host can hear both links if it has two separate interfaces, 
> for example 3Gpp & 802.11b. Can one interface be attached to 
> two different links? 

I think it should be but that is out of DNA scope completely I think.
Ipv6 permits that the link-layer can be two interfaces but must be
presented as one IP connection.  This case is one interface and two
separate link-layer connections.  This requires thought and should be
separate draft and this may be IPv6 WG work not DNA work.

> 
> > > > >    Hence, to determine the need of a further configuration, a 
> > > > >    host needs to check at least that:
> > > > > 
> > > > >     1) Whether it knows a (partially) reachable 
> default router.
> > > > 
> > > > I don't think this is true unless you add on a new link.
> > > 
> > > A host is under uncertainty. It doesn't know whether a 
> link change 
> > > happened or not.
> > 
> > This is where we do not agree and we can agree to disagree. 
>  Point of 
> > further discussion for sure.
> 
> First I'd like to make it clear about what we do not agree, 
> because I suspect our difference of opinion is just a 
> difference of terminology. 

That could be.

> 
> My statement is that 
> 
> At the time a host changes its LINK-LAYER connection, it 
> doesn't know whether it still remains at the same LINK or not. 
> 
> Do you disagree with the above statement? 

I would say it "may' or "may not" know I think it is possible to know
but we may need to add the prefix suggestion BCP or 

http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-02.tx
t

> 
> > > > Not sure about this.  How is this possible.  If I can 
> get a packet 
> > > > from an address then I can send to an address? Does 
> this need to 
> > > > be worded differently or more explanation.
> > > 
> > > Assume I receive an RA from a new Router. It confirms that I can 
> > > receive a packet from the router. But it doesn't confirm 
> the router 
> > > can receive a packet from me.
> > 
> > My point is that the only technology that has this 
> asymetric property 
> > are radio transmissions not 802.xx protocols wired or 
> wireless.  Is my 
> > understanding.  So lets keep it focused and this is another 
> goal for 
> > DNA to define the L2 properties with respect to routing and 
> link detection.
> 
> You suggest as a DNA goal the following. 
> 
> Define the L2 properties with respect to routing and link detection. 

Yes.  But I would say "describe" and again that may be an info or bcp
draft.

> 
> I wonder this may be under link-layer hint work. 

Could be yes.

> 
> > > This is the current state of art. 
> > 
> > I don't agree that is invalid statement on state of art there is no 
> > real deployment of MIPv6 yet to even say this or IPv6 with WiFi etc.
> 
> While no real deployment, there are several MIPv6 
> implementations. But I suggest we stop arguing about 'the 
> existing DNA schemes', lest we should jump into ontology to 
> ponder upon what it means to EXIST. For me, already more than 
> enough metaphysical discussions with bean counters. I promise 
> to keep away from the term, 'existing DNA schemes' 

Thanks.

> 
> > > > > 3.1  Wireless link properties
> > > > > 
> > > > >    1) Unclear boundary
> > > > > 
> > > > >    Unlike wired environments, what constitutes 
> wireless link  is variable
> > > > >    in both time and space.  It doesn't have clear 
> boundaries. This may
> > > > >    be illustrated by the fact that a host may contact 
> multiple (802.11)
> > > > >    access points at the same time.  Moreover reachability on 
> > > > >    a wireless link is very volatile, which may make 
> link detection hard.
> > > > 
> > > > Any device is aware of which wireless net is attached 
> to and that 
> > > > data is available so I am unclear the statements above 
> are valid? 
> > > > I also do not agree link detection is hard.
> > > 
> > > In Wireless environment, a host may ping-poing between two links 
> > > rapidly. In that case, a host will have difficulty.
> > 
> > I don't agree but define what exactly technically 
> "difficulty" means 
> > above?
> 
> What I have in mind is this. It takes time for a host to 
> detect the identity of a currently attached link. If the host 
> ping-pong between two links and doesn't stay enough time at a 
> link, the host can't complete detecting link identity. 

OK that is valid yes.

> 
> Do you want the above paragraph removed? Kindly clarify. 

I think clarify as you did above.

> 
> > > > This has nothing to do with Goals and a podium to 
> present one view.
> > > > RA's are not to represent link change so lets make one.
> > > > But this is a goals document.
> > > 
> > > DNA Goal is to 'detect a link identity'. Isn't it useful to write 
> > > that an RA can't indicate a link identity?
> > 
> > If stated a goal is to make RA's provide link IDs then yes 
> that would 
> > be a goal but state they can't without corresponding goal 
> sounds like 
> > extra baggage and no value and potential political 
> wordsmithing that 
> > is not relevant to the goals document.
> 
> So do you suggest to remove the above part? Your proposal 
> regarding Sec 3 is not entirely clear to me.  

I responded to above I think.

>  
> > > > >    1) Link local scope of Router Address
> > > > > 
> > > > >    Usually a router address is contained in the 
> source address field of
> > > > >    RA messages.  That router address is link-local 
> scope and its
> > > > >    uniqueness can't be guaranteed out side of a link.
> > > > > 
> > > > >    So if it happens that two different router 
> interfaces have the same
> > > > >    link-local address, a host can't detect that it 
> has moved from one
> > > > >    interface to another by checking the router 
> address in RA messages.
> > > > > 
> > > > >    On the other hand, a host can't be sure that its 
> default router is
> > > > >    reachable, even if it can communicate with the 
> router that has the
> > > > >    same address as its existing router address. That 
> router may be a
> > > > >    different one, which happens to have the same 
> link-local address as
> > > > >    its default router address.
> > > > 
> > > > We can require that the router use non-link local 
> addresses with a 
> > > > prefix and those cannot be duplicated across the links. 
> I am not 
> > > > advocating that but the above statement is not entirely 
> honest or 
> > > > tells the whole story and also again not a goal.
> > > 
> > > The above is about the existing problem of link-local 
> scope of router 
> > > address.   
> > 
> > But is incomplete not referencing it can use non-link-local scope.
> 
> I see. What would you suggest?

I don't see the point of even discussing what the router does for goals
but state what is needed.

> 
> Either
> 1) remove the part or
> 2) modify the part to refer non-link-local scope.

Remove is my input.

> 
> > > > So we fix that in RA's or add new RA fro mobile nodes.
> > > 
> > > Under current standard, hosts can't be 100% sure that it 
> knows all 
> > > the prefixes, even if it does. That uncertainty results in the 
> > > uncertain address validity determination.
> > 
> > I simply 100% do not agree at all techncially that this 
> cannot be done 
> > with a new set of RA's.
> 
> It seems that you are worried the above may convey the wrong 
> impression. 
> Do you suggest the part to be removed? 

Just don't talk about solutions.

>   
> > > > >    For rapid attachment detection, hints can be used 
> to tell a host that
> > > > >    a link change might have happened.  This hint 
> itself doesn't confirm
> > > > >    a link change, but can be used to initiate the appropriate
> > > > >    procedures.
> > > > 
> > > > Correct but lets go look at the IEEE properties of each 
> link media 
> > > > first and be sure.
> > > 
> > > There are hints from L3. 
> > 
> > Ugggggggggg.  That should be a goal to verify.
> 
> Hints activate DNA procedures. MIPL code used to activate MD 
> procedure whenever it receives a new RA (the RA with a new IP 
> address & prefix). 
> The receipt of a new RA is a hint. 

OK.

>   
> > > > >    3) Random delay execution for RS/ RA exchange
> > > > > 
> > > > >    Router Solicitation and Router Advertisement 
> messages are used for
> > > > >    Router Discovery.  According to [4], it is 
> sometimes necessary for a
> > > > >    host to wait a random amount of time to send an RS 
> and for a router
> > > > >    to wait to reply an RA.
> > > > > 
> > > > >    Before a host sends an initial solicitation, it 
> SHOULD delay the
> > > > >    transmission for a random amount of time between 0 and
> > > > >    MAX_RTR_SOLICITATION_DELAY (1 second).  Also 
> Router Advertisements
> > > > >    sent in response to a Router Solicitation MUST be 
> delayed by a random
> > > > >    time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).
> > > > 
> > > > This is configurable.
> > > 
> > > Configurable under RFC 2461? 
> > 
> > Yes.
> 
> You mean that it is possible that   
> 
> Router Advertisements sent in response to a Router 
> Solicitation NEED NOT be delayed by a random time between 0 
> and MAX_RA_DELAY_TIME (0.5 seconds).

Yes.

Thanks
/jim