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

[Alper Yegin <alper.yegin@samsung.com>]

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

I agree there is not much for DNAv4 to do in that case, other than to
get the link up and look at the IP address and turn this information
into "subnet has changed!" message to its subscribers (which may include
Mobile IPv4 process). But I'd still have a DNAv4 process, so that
regardless of the L2 types other processes simply plug into the DNA
process to know when IP subnet has changed. Alternative could be to
listen to routing sockets for IP address change, but that's diverging
from using a central DNA process (which I think is an unstated goal of
this work).

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

Given the lack of one2one mapping between SSID and IP subnets, I still
don't see the value of knowing SSID. When would knowing SSID make a
difference in the DNA process?

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

I see the problem. If such a case is likely, there needs to be some
damping in the stack. That can be in L2, or in DNA. Before reacting to a
trigger, we should make sure it is damped. That doesn't seem to take
away anything from the reliability of the triggers though. 

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

And the hints.... But not how they should be used to perform DNA.

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

Maybe this is a perception thing, but I see this as the trigger is
reliable but it better be damped.

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

We don't have an agreed upon DNAv6 solution yet though. 

Alper