Subject: [multimob] draft-ietf-multimob-pmipv6-ropt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Feb 2013 16:51:19 -0600

Hi JC, Authors,
This draft is a candidate for WG LC soon, so please consider my comments
below and revise accordingly:

Section 3.1. Similarly, more than one MTMA could be
   deployed by the operator (not shown in Figure 1).

How do you avoid tunnel convergence problem if there are more than one
MTMA? You have some hints in Appendix A.3, related to Fig. 8 but it is
still not clear. Please explain it here in 3.1

Section 3.2. each MAG has a direct connection (i.e., not
   using the tunnel interface) with a multicast router.

Does MR need to be next hop? If not what happens?
Again this is later on explained on Page 15, but why not here?

3.3.  Dynamic Selection Support

This section is about MAG as a multicast router.
WG has not yet decided if MAG should be a multicast router. So this section
is out of scope. Please remove.

Section 4.2.1
Is Figure 4 really needed? Maybe remove.

4.2.2.
multicast          establishment.
               vvv  service

4.3.  MAG as multicast router

This section is also about MAG as a multicast router.
WG has not yet decided if MAG should be a multicast router. So this section
is out of scope. Please remove.

5.1.  Dynamic IP Multicast Selector Option
This option brings a lot of questions.
But more importantly, it seems to apply to the case of MAG as multicast
router which is out of scope, so please remove.
I also read the Appendix, I think it is OK.

Thanks for your hard work.

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 12 Feb 2013 12:28:31 +0900 (JST)

Hi,

I've reviewed this draft.
I think this draft provides useful ideas and closes up to the LC, but
the following points should taken into account.

1. multicast router support
   I almost agree with Behcet at this point. This draft should focus
   only on the case MAG acts as MLD proxy. All descriptions related to
   the case MAG acts as multicast routers (i.e. PIM routers) should be
   completely removed.
   (I would say WG does not need to decide only one solution. It
   sounds reasonable for this WG to provide both scenarios, "MAG=MLD
   proxy" and "MAG=PIM router". Both are beneficial for some condition
   or situation. The decision which scenario should be selected is an
   operator's or provider's choice, accouring to their conditions or
   situations. Well, it does not relate to the direction of this
   draft. I'd like to stop discussing about it here.)

2. local subscription
   This draft uses both "remote subscription" and "local subscription".
   But I don't think it is a bit confusing to use these words without
   clarifying the terminologies. The point of this confusion comes
   from several misuse of "direct routing" and "localized routing".
   Localized routing is formally defined in RFC6705. In my sense,
   local subscription includes both direct routing and localized
   routing, while this draft only focuses on direct routing.
   So, my recommendation is to remove these words, "remote
   subscription" and "local subscription", from the draft, and just
   use "subscription via MTMA" and "subscription via direct routing". 

3. direct routing
   Similar to above. It'd be better to clarify that direct routing
   this draft focuses on does not include localized routing.

Lastly, I have one question.
Does this draft consider the case in which MAG enables *both* a tunnel
to MTMA and direct routing? I could not find such consideration...

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 12 Feb 2013 13:36:40 +0900 (JST)

One correction.

>    (I would say WG does not need to decide only one solution. It

I would say WG can provide different solutions for different scenarios.

Regards,
--
Hitoshi Asaeda