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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Jari

Thanks for your feedback. Kindly find my inline comments.

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

ok.

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

We presented multiple mechanisms because network environment may
differ and there may be different applicability scenario for each
scheme. For example, in WiMAX, whenever an MN makes an attachment, the
AR, ASN GW, perceives a new attachment during registration procedure.
Therefore RA triggering (without RS with tentative option) is more
suitable. On the other hand, RA proxying with scanning can work with
ordinary router without any modification.

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

Glad that you seem to like the idea. However the scheme necessitates
router modification to handle tentative option and people showed some
concerns. Kindly find following exchange between Greg and me.

  [JinHyeock]
  Main difference between MN soliciting and AP soliciting is that,
  with the latter, we can realize a scheme (similar to Hash based
  FastRA) in a simpler way.

  We can assume that an AP knows all the ARs in a link.
  So AP can send UNICAST RS (to remove random delay)
  and solicit ARs in turns (for load balancing).

  When a new host is attached to the AP,
  AP can sends an unicast RS to a chosen AR
  1) with unspecified source address
  2) with the host's MAC address in TSLLAO.

  Upon receiving the unicast RS,
  the AR can send an RA immediately
  (because it is solicited in unicast).
  in unicast (using TSLLAO)

  Also AP take turns to solicit ARs,
  such as this time AR1 next time AR2
  to achieve load balancing.

  Hence no load balancing mechanism is needed
  in ARs.


  [Greg]
  > When a new host is attached to the AP,
  > AP can sends an unicast RS to a chosen AR
  > 1) with unspecified source address
  > 2) with the host's MAC address in TSLLAO.
  >
  > Upon receiving the unicast RS,
  > the AR can send an RA immediately
  > (because it is solicited in unicast).
  > in unicast (using TSLLAO)
  >
  > Also AP take turns to solicit ARs,
  > such as this time AR1 next time AR2
  > to achieve load balancing.
  >
  > Hence no load balancing mechanism is needed
  > in ARs.

  This is actually using the hackiest part of TSLLAO ;)
  In some devices it won't be possible to modify the
  outbound MAC address of the packet on the router, but
  it seems in this environment, you could either discover
  the ones which handle the TSLLAO, or mandate modified
  routers.

  Should we leave that part in the TSLLAO draft for
  the moment then? :)

  > > Surely the same logic is needed for the AP or there would be
  > > collisions if there are multiple routers on the link.
  >
  > Yes, AP needs some logic (but simpler one, in my opinion) and
  > for hosts and routers, only TSLLAO is needed.
  > Other than that there is nothing to change in them.
  >
  > How do you think of it?

  I think that if protocols were in a beauty contest, it would
  be the ugliest cheetah around.

  It's really not possible to tell how much simpler it is, though.
  The APs need to track a list of all routers, some of which may
  not be trusted at L3 (Do they do SEND?).  In each of the ARs,
  the RA delivery scheme needs to be modified (TSLLAO w/o Ncache,
  Delay removal for Unicast RS).

  In other schemes, ARs need to track other DNA routers. In
  each of the ARs, modifications to the RA delivery scheme are
  needed (TSLLAO, delay + scheduling modification, unicast response).

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

yes.

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

In IP level, the RA has 'multicast destination address'. In MAC level,
the RA has the address from tentative option as a destination address.

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

ok.

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

The section presents how FRD works without MAC address. 802.16 doesn't
use MAC address for the data transfer, so we showed how RA is
delivered with CID, instead of MAC address. We were concerned that
people are not familiar with 802.16, so presented some 802.16
information.

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

ok.

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

ok. We'll make a fix.

I am off to Mannheim for 16ng interim in an hour. This week my reply
may be erratic, so I ask your kind understanding.

Thanks for your kind consideration.

Best Regards

JinHyeock