Re: [DNA] WGLC for draft-ietf-dna-frd-02.txt

[Jari Arkko <jari.arkko@piuha.net>]

I have also performed a quick review of this spec.

Overall, the draft addresses a significant problem
and we need a solution in this space. However,
more work is needed and I would suggest taking
the draft back to the editors and have them
prepare a new proposal based on the high-level
comments received so far.

Multiple mechanisms: The draft suggests a variety
of mechanisms as opposed to choosing one. The draft
uses either triggering or caching. For triggering,  the
draft uses either an RS with the tentative option, or MIES.
For caching, the draft allows manual config, learning based
on RAs, or MICS. Sometimes we have to have multiple
mechanisms, but I'm not sure I see the rationale for that
here. Perhaps there was past discussion that I did
follow. But I would suggest that the WG/editors consider
the choices and make the necessary hard decisions.
For instance, it seems that triggering via rs+tsslao
avoids most problems, as it does not need multicast
RAs, does not impact SEND AFAICT, and has no
impact on advertised lifetimes.

RS with tentative address construction: This is
not discussed in the draft. Source = undefined,
tsllao = poa's L2 address? And I'm assuming responses
to such RSes will be valid RAs in all existing hosts that
only support RFC 2461?

Unicast RA construction: Is there a description of what
the contents of the RA sent from the cache are? It
is mentioned that it is sent in an unicast L2 frame,
but are there any changes to the IP packet, e.g.,
destination address, lifetimes, etc?

Scanning procedures: I agree with Thomas' observation
about the alternative scanning procedure. Also, I
don't think Section 5.1.2 should recommend anything
about AR behaviour, and should operate on standard
IPv6 routers.

802.16: There's very little DNA specific information
here, and a lot of information that is overlapping
with 802.16, Wimax Forum, or 16ng WG tasks. I
would suggesting deleting this section.

Damping: I suspect that a damping procedure should
be defined to avoid causing RS storms due to attachments
that relate to ping-ponging between nearby networks,
a large number of hosts arriving at the same access point
and so on.

Dangling references. Draft-ietf-dna-tentative is
a pointer to an expired draft, and the merged
document is not yet available. There is no pointer
to the OP procedure. The hash chain procedure
is defined in an individual draft which is currently
not on the program in any WGs as far as I can
remember. And a new SEND solution is not in
DNA's charter.

--Jari