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

From: Brian Haberman <[email-masked]>
Date: Wed, 05 Jun 2013 11:42:58 -0400

All,
      Here is my AD evaluation of draft-ietf-multimob-pmipv6-ropt.  Once 
these issues are resolved, the draft can move to the next step in the 
publication process (IETF Last Call).

* There are several explicit mentions of the Multimob WG in the 
document.  Those sentences should be re-worded to focus on the content 
of the draft, rather than who created the draft.

* In the Intro : s/so-called tunnel convergence/tunnel convergence/

* Is the MTMA really just a variant of an LMA (i.e., LMA handling all 
multicast traffic)?  If so, the definition should clarify that.

* In 3.1 : s/is used used to/is used to/

* In 3.2, there is a reference to Figure 1 that I believe should be a 
reference to Figure 2.

* In 3.2, what is meant by a "direct connection" between the MAG and a 
multicast router?  Are they supposed to be on a shared link?  Traffic is 
routable between the two?  Additionally, why is that connectivity 
restricted from running over a tunnel?  Could they be connected via AMT 
(draft-ietf-mboned-auto-multicast) or GRE tunnels?  If not, some 
justification is needed since many multicast deployments use tunnels.

* Section 4 jumps right into the two ways of getting multicast data to 
the MAG (direct routing and the MTMA) without providing any guidance as 
to when each of the approaches is applicable or describing *how* the 
modes are selected.  Based on text elsewhere, I assume these modes are 
manually selected by the operator.  It would be good to provide some 
operational guidance.

* Section 4.1 references the "binding update list (BUL)" without any 
context.  It would be good to provide either a brief description of what 
it is or a reference to the document that defines it.

* Figure 3 does not show any MLD/IGMP traffic coming from the MTMA. 
Based on the description of the MTMA, I assume it must utilize multicast 
routing protocols and should be acting as an MLD Querier.  When the MAG 
provides its aggregated MLD Report, is that an unsolicited report or is 
it driven by the reception of an MLD Query?

* Section 4.2.2 references RFC 3810 when it is talking about MLD Proxy 
operation.  The reference should point to RFC 4605.

* In 4.2.2, I cannot parse the following : " ... an upstream interface 
of MLD Proxy instance is decided towards certain multicast router..."  I 
would be good to reword that sentence (and possibly break it into two 
sentences).

* Section 5.1.2, why does the option format only allow one Multicast 
Address Record?  MLD Report messages can carry multiple address records 
to minimize overhead, so why the limitation here?

* In general, there does not seem to be sufficient discussion of the 
versions of MLD (or IGMP) supported with this method.  Is it strictly 
limited to MLDv2 (hence the reference to RFC 3810) or can MAGs, MTMAs, 
and multicast routers utilize MLDv1?

* Does the MTMA need any special considerations for support SSM or is it 
truly a multicast router?  It is unclear as to what the differences 
would be between the MTMA and a multicast router, especially given the 
text in section 3.1 that says "The MTMA can be considered to be a form 
of upstream multicast router".  I think there needs to be a crisper 
description of the MTMA.

Regards,
Brian

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 5 Jun 2013 16:40:55 -0400

Hi Brian,

Thanks for the detailed review. We will look at the list of issues and
produce a new version of the document so that we can move forward.

Regards,

Juan Carlos

> -----Original Message-----
> From: Brian Haberman [mailto:[email-masked]]
> Sent: Wednesday, June 05, 2013 11:43 AM
> To: [email-masked]; [email-masked]
> Subject: AD Evaluation : draft-ietf-multimob-pmipv6-ropt
> 
> All,

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 18 Jun 2013 15:39:28 +0200

Hi Brian, all,

[Authors] Thanks Brian for the review. We have produced a new version
(-06) addressing your comments. Please, see inline below for additional
clarifications.

> of the draft, rather than who created the draft.

[Authors] Fixed.

> * In the Intro : s/so-called tunnel convergence/tunnel convergence/

[Authors] Fixed.

> multicast traffic)?  If so, the definition should clarify that.

[Authors] We have improved the definition of MTMA in the terminology
section:

   MTMA or multicast tree mobility anchor:  An entity working as
      topological anchor point for multicast traffic.  It manages the
      multicast groups subscribed by all (or a subset of) the MAGs in a
      PMIPv6 multicast domain, on behalf of the MNs attached to them.
      Hence, an MTMA performs the functions of either a designated
      multicast router or an MLD proxy.

We have also added some explanatory text in Section 3.1.

> * In 3.1 : s/is used used to/is used to/

[Authors] Fixed.

> * In 3.2, there is a reference to Figure 1 that I believe should be a 

[Authors] That reference was part of some duplicated text that is
already mentioned in Section 3.1. The whole sentence referencing Figure
1 in Section 3.2 has been removed.

> justification is needed since many multicast deployments use tunnels.

[Authors] We have tried to improve the text in Section 3.2 to clarify
this point and explictily mention support for GRE and AMT tunnels:

   As seen in Figure 2, each MAG has a direct connection (i.e., not
   using the PMIPv6 tunnel interface) with a multicast router.
   Depending on the multicast support on the visited network, different
   schema can be used to provide this direct connection between the MAGs
   and the multicast router(s), e.g., being connected to the same shared
   link or using a tunneling approach, such as Generic Routing
   Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast
   Tunneling (AMT) [I-D.ietf-mboned-auto-multicast].  To facilitate
   IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy
   function defined in [RFC4605] SHOULD be implemented in the MAG.
   There SHOULD be direct connectivity between the MAG and the local
   multicast router (or additional MLD proxy).

> manually selected by the operator.  It would be good to provide some 

[Authors] We have added a new Section 3.3 (MTMA/Direct routing mode
selection), that introduces how each of the approaches can be selected.

> it is or a reference to the document that defines it.

[Authors] Fixed.

> it driven by the reception of an MLD Query?

[Authors] The aggregated report sent by the MAG is sent triggered by
the reception of the MLD report generated by the MN (assuming that this
report includes groups which the MAG had not previously subscribed to).
The MTMA acts as an MLD Querier. We have re-worded a bit the text in
Section 4.2.1 to make this clearer:

   MN1 sends the MLD report message (when required by its upper layer
   applications) as defined in [RFC3810] in response to an MLD Query
   from MAG (generated as defined by [RFC6224] upon handover).  The MAG,
   acting as a MLD Proxy defined in [RFC4605], will then send an
   Aggregated MLD Report to the multicast anchor, MTMA (assuming that
   this is a new multicast group which the MAG had not previously
   subscribed to).  Multicast traffic will then flow from the MTMA
   towards MN1.  The MTMA acts as an MLD Querier, so it will
   periodically query each MAG about the subscriptions it maintains (not
   shown in Figure 3).

> operation.  The reference should point to RFC 4605.

[Authors] Fixed.

> would be good to reword that sentence (and possibly break it into two 

[Authors] We have re-worded this part.

> to minimize overhead, so why the limitation here?

[Authors] We have updated the option format to remove that limitation.

> and multicast routers utilize MLDv1?

[Authors] We have updated the Dynamic IP Multicast Selector Option
format and added additional text in Section 8 (IPv4 support) to provide
additional information, as requested.

> of upstream multicast router".  I think there needs to be a crisper 

[Authors] As mentioned earlier, we have tried to improve the definition
of MTMA in the document.

Thanks,

Carlos

---

From: Brian Haberman <[email-masked]>
Date: Tue, 18 Jun 2013 10:21:34 -0400

Is there any particular reason why the option format defined in section 
5.1.2 does not have a "number of MARs" field (similar to the MARs 
defined in 3810)?

Regards,
Brian

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 18 Jun 2013 19:19:16 +0200

Hi Brian,

> 5.1.2 does not have a "number of MARs" field (similar to the MARs 

Not really. The "Length" + "Protocol" fields can also be used to derive
the number of MARs, without adding any additional information to the
option, right?

If you think it is better to add the "number of MARs" field, we can do
it in a new revision of the draft.

Thanks,

Carlos

---

From: Brian Haberman <[email-masked]>
Date: Tue, 18 Jun 2013 18:39:19 -0400

> the number of MARs, without adding any additional information to the

It can, but adding an explicit count of the records gives you the 
ability to do some error checking.

> it in a new revision of the draft.

I wouldn't say it is better, just more robust.  I would rather have the 
spec represent what has been implemented.

Regards,
Brian

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 19 Jun 2013 17:41:02 +0200

Hi Brian,

> spec represent what has been implemented.

At the moment we have not yet implemented the multiple MAR option, so
either solution would be equally feasible. Since you believe having an
explicit counter is more robust, we can add the option.

If there are no more comments from you or the group, we can make the
change and produce a new version.

BTW, I've just seen that IETF LC has been started on the document, but
as Informational RFC. There was discussion within the WG about the
intended status and the result was to make it Experimental. Is it a
problem that the LC is initiated for Informational status?

Thanks,

Carlos

---

From: Brian Haberman <[email-masked]>
Date: Wed, 19 Jun 2013 11:49:37 -0400

> explicit counter is more robust, we can add the option.

That is up to you.  It may be worth waiting until you get additional 
comments.

> problem that the LC is initiated for Informational status?

Informational and Experimental are equivalent.  If the WG decides to 
change to Experimental, it can be done without another IETF Last Call.

Regards,
Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Jun 2013 10:59:42 -0500

Folks,

Here is the discussion on the ropt draft so far.

If you have additional comments please post now, do not wait because the
draft is now on IETF Last Call.

Also we need to confirm that this draft should be experimental not
informational.

Regards,

Behcet

On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman
<[email-masked]>wrote:

> ______________________________**_________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 19 Jun 2013 18:04:21 +0200

Hi Brian,

OK, thanks for the clarifications.

Carlos

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 Jun 2013 11:04:10 -0700

> draft is now on IETF Last Call.

Personally I think a MARs counter could be useful.

> Also we need to confirm that this draft should be experimental not

For this, please read
http://www.ietf.org/iesg/informational-vs-experimental.html
first, and then try to see what looks the most appropriate.

Stig

> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     _________________________________________________
>     multimob mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/multimob
>     <https://www.ietf.org/mailman/listinfo/multimob>
>
>
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 19 Jun 2013 14:23:00 -0400

Hi Stig, all,

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stig Venaas
> Sent: Wednesday, June 19, 2013 2:04 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Behcet
> Sarikaya
> Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt
> 

[JCZ]  Seems like we have a preference for adding the counter, so my recommendation would be to add it at the next revision.

> first, and then try to see what looks the most appropriate.

[JCZ]  Thanks for sending the link. After reading through it, I personally believe Experimental is more appropriate.

Regards,

Juan Carlos

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Jun 2013 11:47:10 -0400

I also vote for making it Experimental as I have heard off line various times that people would like to implement these ideas on running code and see the performance results.

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zuniga, Juan Carlos
Sent: Wednesday, June 19, 2013 2:23 PM
To: Stig Venaas; [email-masked]
Cc: [email-masked]; [email-masked]; Behcet Sarikaya
Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt

Hi Stig, all,

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stig Venaas
> Cc: [email-masked]; [email-masked]; 
> Behcet Sarikaya
> > If you have additional comments please post now, do not wait because 
> > the draft is now on IETF Last Call.
> 

Regards,

Juan Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 26 Jun 2013 16:52:41 -0500

> Personally I think a MARs counter could be useful.
I also agree.

> http://www.ietf.org/iesg/**informational-vs-experimental.**html<http://www.ietf.org/iesg/informational-vs-experimental.html>
Of course Experimental looks the most appropriate.

Regards,

Behcet

>> <[email-masked] <mailto:brian@innovationslab.**net<[email-masked]>>>
>> wrote:
>>
>>     ______________________________**___________________
>>     multimob mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob>
>>     <https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>> >
>>
>>
>>
>>
>>