RE: Categorizing the L2 information and naming them (was RE: [DNA]Review of draft-yegin-dna-l2hints-01.txt)

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

Sorry for the latency in getting back on this thread....

> For example, the value of "associating with the same SSID" is in part
> determined by the configuration of the network in question.  If this
is a
> flat network, with lots of APs within a single subnet, then it may be
a
> good guess that "associating with the same SSID" implies "remaining
within
> the same subnet".  For example, if on average one attaches to 100 APs
> remaining within a subnet before changing subnets, then the hint may
be
> reliable enough to cause DHCPv4 to be bypassed.  But if the subnet
changes
> every 3-5 APs, it is optimal to ignore the hint altogether avoid DNAv4
> altogether.

I'm not sure if you are suggesting this but it's rather hard to take
such environmental factors into the (IETF) DNA solution.
 
> > Checking the incoming trigger/hint against the hysteresis would be
the
> > first action DNA module could take.
> 
> I'm not sure how "hysterisis" plans into DNA.  The hint is either
> sufficiently reliable or it isn't.  If we're just talking about "link
up"
> with no hint, then it is not necessarily true that DNA is involved at
all.
> For example, it is possible to do RS/RA, NS/ND without DNA.

I think there is still a DNA process here. It is the process that
generates the NS, gets a copy of the NA, makes some comparisons, and
derives a conclusion. 

> > In an implementation the trigger can be received as a message that
may
> > carry 0 or more hint data items.
> 
> Sure.  Since the "hint data items" are what is most important (after
all,
> RFCs such as RFC 2131 already refer to triggers so that part is not
new),
> I'd suggest that the document needs to discuss this.

Yes, triggers are not new. They are already used in one form or another.
Actually even DNA is not that new. Maybe it is not called DNA, but
various stacks already perform this task (DNA BCP to explain how....).

Alper