Subject: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 06 Jun 2009 11:33:44 +0100

https://datatracker.ietf.org/drafts/draft-asaeda-multimob-igmp-mld-mobility-extensions/

I have a few comments (not particularly as a BoF chair) on the above draft.

Best wishes,

Gorry

---

Comments/Questions:

* I could not clearly identify the normative changes to be applied in 
the update - please could you use RFC 2119 language to help clarify the 
intended changes?

* Intro Para 7,
/Futhermore,.../
- I am not sure what this sentence is saying about use in SSM?

* Section 2.3
- I think we SHOULD consider a case for multiple Queriers. In say, WiFi, 
this could be a useful scenario, and it would not be good to disregard 
this case. Do others agree?

* The document speaks of a new Hold type being introduced. As I 
understand, it is assumed that a Join negates a previous Hold? In that 
case, have the authors considered how re-ordering of packets is 
addressed, and that the intended final state would be arrived at over 
paths with (mild) reordering?

* I am curious about the treatment of the Hold and Join when a IGMP/MLD 
Proxy device is inserted between Querier and receiver, and whether there 
are cases where the semantics of a Join message may be misinterpreted?

* Do you expect a Proxy at the IGMP/MLD level to generate Hold messages?

* Has the possibility of an additional specific message type to release 
a hold been considered? - This would allow the join semantics to remain 
unchanged, there may be other pros/cons?

* I'd love to see some bullets (or text) on the Security Considerations 
to help understand how large a change we may be considering.

NiTs

* It is allowed to place the copyright notice at the end of a draft - 
this is slightly easier to read, since the abstract makes the first page.

* The current abstract does not clearly call-out what documents would be 
updated if this were to be published as a PS.

* Abstract Sentence 2, English should be improved
/to request join or leave multicast sessions/
- It could be even better to avoid the notion of join and leave, and say 
to inform the Querier of the set of groups that downstream receivers 
wish to receive?

* Intro Para 2,
/To create feasible condition/
- not sure the current method is infeasible, but could be suboptimal
/traces all downstream/
- English should be improved
/and proceed/
- English should be improved

* Intro Para 3,
- Is this para required, it seems to be generic?

* The current document is not clear on calling-out the changes as BCP 
recommendations (sections 2 and 5?) or standards-track updates (section 
3?). Using RFC2119 language would help here.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 12 Jun 2009 20:55:41 +0200

Hi Gorry,

many thanks for reading the draft and your detailed comments.

In total I agree that this is a very premature document and requires 
thorough rewriting. In particular, I'd like to suggest a splitting of 
the document into two:

  * one BCP document on how to tune MLD best in wireless domains and 
mobile regimes.
  * another standard track document on protocol extensions like the 
listener hold option.

Both parts of the current document are quite sketchy and unfinished. So 
we will happily take your comments and suggestions as input for working 
out the key elements and re-writing the drafts. Presently, I don't see 
much value in discussing further at this state of progress ;)

Thanks,

Thomas

Gorry Fairhurst wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 13 Jun 2009 12:38:59 +0900 (JST)

Gorry,

Thanks for comments.

> * The current document is not clear on calling-out the changes as
> BCP recommendations (sections 2 and 5?) or standards-track updates
> (section 3?). Using RFC2119 language would help here.

Neither PS nor BCP is mentioned as the intention of this draft.
We may divide into two drafts, one for PS and the other for BCP
(timer tuning and optimization being useful as the operational
guideline), if consensus. Some of your comments will be then fulfilled
in these drafts.

Thomas,

> drafts. Presently, I don't see much value in discussing further at
> this state of progress ;)

It's not my thought.
It's good to hear comments in any stage or any time.
While my response may be delayed sometimes, I'll take into account
given comments or reply my opinions later. I'd appreciate any
comment.

Furthermore just saying "premature" does not improve anything..

> ---
> 
> Comments/Questions:
> 
> * I could not clearly identify the normative changes to be applied
> in the update - please could you use RFC 2119 language to help
> clarify the intended changes?

I'll fix it in the separate drafts.

> - I am not sure what this sentence is saying about use in SSM?

It is not about SSM itself. It explains that coexisting exclude mode
operations in multicast communication will reduce SSM advantage,
because an exclude mode operation will re-organize multicast routing
tree with RPT. I'd like to clarify the issue here.

Note that many sentenses in the intro paragraph including this
sentence are for an operational guideline (which will be a BCP draft),
not PS draft maybe.

> * Section 2.3
> - I think we SHOULD consider a case for multiple Queriers. In say,
> WiFi, this could be a useful scenario, and it would not be good to
> disregard this case. Do others agree?

Maybe yes.
Sect.2.3 does not deny the case, but wants to clarify the issue. This
discussion will be in BCP draft.

> understand, it is assumed that a Join negates a previous Hold? In

Yes.

> that case, have the authors considered how re-ordering of packets is
> addressed, and that the intended final state would be arrived at
> over paths with (mild) reordering?

Good catch.
In the next revision, I'd say;
"... The router then sends the corresponding Group-Specific or
Group-and-Source Specific Query upon reception of an IGMP/MLD Hold
message. If the router receives the IGMP/MLD report, it ignores the
IGMP/MLD Hold message and keeps forwarding the data."

Make sense?

> * I am curious about the treatment of the Hold and Join when a
> IGMP/MLD Proxy device is inserted between Querier and receiver, and
> whether there are cases where the semantics of a Join message may be
> misinterpreted?

In that case IGMP/MLD Proxy device is the querier for its downstream
nodes and *it* deals with the Hold message.

Currently IGMP/MLD Proxy does not forward Hold messages to its
upstream routers. So the data still comes to that proxy even if it
receives Hold from its downstream.
I prefer this simple scenario.

> * Do you expect a Proxy at the IGMP/MLD level to generate Hold messages?

ditto.

> * Has the possibility of an additional specific message type to
> release a hold been considered? - This would allow the join
> semantics to remain unchanged, there may be other pros/cons?

So the answer is same as of above "re-ordering" issue.

> * I'd love to see some bullets (or text) on the Security
> Considerations to help understand how large a change we may be
> considering.

I got it.

I'll improve the whole text as well.

Thanks,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 14 Jun 2009 11:31:04 +0900 (JST)

I'm sorry, I found a bug in my previous mail. So I'd correct my reply.

> I prefer this simple scenario.

This my answer is not correct.

For instance, PMIPv6 multicast explained in the following draft;
http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-01
MAG can behave as an MLD proxy.
In that case, MAG MUST forward MLD hold messages given from its MNs to
the LMA, and LMA deals with the messages and decides if it keeps join
state or not.

Therefore, yes, IGMP/MLD proxy must forward hold messages to its
upstream routers.
This is the required extension for the use of hold/release extension.

Thanks for reminding me.
Regards,
--
Hitoshi Asaeda

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 14 Jun 2009 08:38:47 +0100

Yes, that seems appropriate to me, thanks for the clarification.

Best wishes,

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 14 Jun 2009 08:38:44 +0100

See comments in-line, and look forward to an updated contribution.

Do you plan to split the draft into two parts or two I-Ds next revision?

Gorry

> guideline), if consensus. Some of your comments will be then fulfilled
I think we agree.

> tree with RPT. I'd like to clarify the issue here.
OK - some clarification would be good next revision.

> Note that many sentences in the intro paragraph including this
Maybe. I'd like to see how the specification develops and then look 
again whether this has been addressed.

> I prefer this simple scenario.
Updated in later email.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 14 Jun 2009 19:25:19 +0900 (JST)

> Do you plan to split the draft into two parts or two I-Ds next revision?

Split into two I-Ds.

One for PS draft (protocol extensions including hold/release messages
and operations) and the other for BCP draft (timer tuning and protocol
optimization without message format change).

Regards,
--
Hitoshi Asaeda