RE: RE : [DNA] Review of draft-yegin-dna-l2-hints-01.txt

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

This is very important for all to agree what a hint is.  I think I am on same page as Bernard in the abstract that the hint should be internal to the node and stateless if possible. (Bernard if I am way off base here I apologize).  I know today from code that a handheld can detect a new link at layer 1 or 2.  My bias is to develop a DNA mobile solution and only with IPv6 (I believe IPv4 is a non-starter in the market) using hints from layers 1 and 2 and then begin to learn from RA's et al.  Then working on IP layer 3 hints is the second order of business and again that can be done after we get seeing layer 1 and 2 done.  The reason for his is deployment and need will happen faster than this WG can produce results for layer 3.

I still owe response on goals and will do that as best I can I have been on vacation now and prior to that travel.  I am working early in the a.m. mostly during my vacation and will try to provide goals response soon.

/jim 

> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au 
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of 
> NJEDJOU Eric FTRD/DMR/REN
> Sent: Tuesday, July 13, 2004 5:00 AM
> To: Bernard Aboba; Alper Yegin
> Cc: dna@eng.monash.edu.au
> Subject: RE : [DNA] Review of draft-yegin-dna-l2-hints-01.txt
> 
> Hello DNA folks
> Sorry for late reactions,
> 
> 1)What can be inferred from a couple of Bernard comments is 
> that he is not having the same definition of a hint as we've 
> had when writing the document. 
> A hint for us (Alper correct me if I am wrong) was an 
> informational parameter carried along with a trigger received 
> from L2. Such paramters being able to contain For GPRS: such 
> information as IP address, default gateway, DNS server, 
> brought by the IPCP exchange when buildig up the PPP link 
> resulting from the PDP context establishment For 802.11: the 
> SSID advertised by the AP the STA has associated with
> 
> Whereas a hint for Bernard seems rather to be an indication 
> (possibly wrong) that should prompt the action of checking if 
> change of configuration at IP layer is needed or has 
> occurred. Bernard is this the way you define a hint? If it is 
> then we are not talking about the same thing. Hints for you 
> therefore rather seem to be fallible triggers
> 
> We should first all agree on these terminology issues i think 
> before moving to other considerations. 
> 
> 
> 
> > -----Message d'origine-----
> > De : owner-dna@ecselists.eng.monash.edu.au
> > [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part 
> de Bernard 
> > Aboba Envoyé : vendredi 2 juillet 2004 05:30 À : Alper Yegin Cc : 
> > dna@eng.monash.edu.au Objet : RE: [DNA] Review of 
> > draft-yegin-dna-l2-hints-01.txt
> > 
> > 
> > > The IP address configured as part of the L2 establishment is 
> > > considered as the hint in 3GPP2 and 3GPP. The document 
> has a bug on 
> > > the IPv6CP part, but other than that is there more to hints 
> > for 3GPP*?
> > 
> > I'm not sure that DNAv4 provides any value on 3GPP links.  
> > For example, these links provide an explicit indication of 
> > whether the IP address has changed, and so there is no 
> > optimization to be done.  For example, these links don't 
> > support ARP, and there is no need to confirm reachability to 
> > the default gateway.  So I'd say that DNAv4 is bypassed 
> > altogether on 3GPP.
> > 
> > With respect to IPv6, there may be value... but the DNAv6 BCP 
> > needs to be clear about what that is.
> > 
> > > I'm not sure what to identify as hints in 802.11. What do 
> you think?
> > 
> > One hint is the SSID and/or the BSSID.
> > 
> > > As far as the DNA process is concerned, triggers are always 
> > reliable. 
> > > If L2 says it has changed its point of attachment, I don't 
> > think L3 is 
> > > going to argue against it.
> > 
> > Without damping, on 802.11 it is possible for "link up" and 
> > "link down" indications to be sent 5-50 times a second.  Were 
> > DNA to be triggered each time such an indication is received, 
> > a packet storm will result.
> > 
> > Thus, treating these indications as "triggers" rather than 
> > "hints" can have serious consequences.
> > 
> > > As for hints, they are 100% reliable for 3GPP and 3GPP2. 
> > And they are 
> > > non-existent for 802.11 (subject to change pending feedback).
> > 
> > I agree that 3GPP and 3GPP2 indications are more reliable -- 
> > to the point where there is no point doing DNAv4 at all, 
> > since there is no optimization to be achieved.
> > 
> > > Actually this is the intent. The latter is left to the 
> DNA solution 
> > > specification(s).
> > 
> > Is the only objective of the document to provide a definition 
> > of "link up" for various technologies?
> > 
> > > Please see my response to Greg on the reliability of 
> > triggers. Let us 
> > > know what you think.
> > 
> > My experience is that 802.11 "triggers" are not reliable, but 
> > that other triggers can be very reliable (GPRS/3GPP).
> > 
> > > What generates the L2 trigger is a L2 event.
> > > What "happens" as a result of the trigger is the DNA 
> > processing. For 
> > > example, DNA process may initiate router discovery when 
> it receives 
> > > the Link-up trigger.
> > 
> > I'd suggest that this would not be wise in cases where the 
> > trigger itself is not reliable (802.11).
> > 
> > > OK, I'd remove that as this "anticipation" concept falls 
> > outside the 
> > > scope of DNA.
> > 
> > I think it does because there may not be anything that can be 
> > done with this information.
> > 
> > > The text says "may", not "MUST" or "SHOULD". If DNAv4 has a 
> > reason to 
> > > ignore this trigger, it's fine I think.
> > 
> > I don't think any of the DNA specifications make use of "link 
> > down", only "link up".  So saying that they "may" be used is 
> > confusing, no?
> > 
> 
>