Subject: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 5 Dec 2011 16:02:19 -0600

Hello all,
  There was consensus on the source mobility solution draft in Taipei.
 This mail is to confirm the consensus.

This document can be found at:
http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt

This mail starts a WG adoption call on this draft.

The intended status for this document is proposed standard.
If adopted, the draft will be named:

draft-ietf-multimob-pmipv6-source-mobility.

Please your comments by December 12, 2011.

Chairs

---

From: <[email-masked]>
Date: Tue, 6 Dec 2011 13:51:16 +0100

Dear all,

I agree to adopt the merged draft as WG document and assume that some considerations on PIM-SM and BIDIR PIM will be added.
Beside I have some minor remarks to improve readability:

On P. 4 it says:

> A multicast unaware MAG would simply discard these packets in
   the absence of a multicast forwarding information base (MFIB).

However in sect. 4.2. the MFIB is not mentioned for MAG, only in 4.3. for LMA. Perhaps we should add a sentence on it before saying also whether a synchronisation between MAGs and LMAs MFIB is envisaged.
On the other hand MFIB was already introduced in RFC6224 ... So this is obvious to the experienced reader.

On P.5 it says:
Thus multicast streams originating from an MN will arrive at
   the corresponding LMA and directly at all mobile receivers co-located
   at the same MAG.

However on P. 6 the restriction is made:

   MN - while being attached to the same MAG as the mobile source, but
   associated with a different LMA, cannot receive multicast traffic on
   a shortest path.

Again this may be obvious being a standard RFC6224 procedure but the fact might be mentioned already in the sentence on P. 5 not to cause misunderstanding.

On p.8 I stumbled on the MAG proxy (or MAG-proxy) mentioned and found that the term was inherited from RFC6224. I think it denotes the IGMP/MLD proxy instance located at the MAG, right?

I also found following very minor nits

P.4:
a multicast destination addresses => a multicast destination address
P.5:
IPv6 unicast address configuration with PMIPv6 bindings have been performed. => IPv6 unicast address configuration with PMIPv6 bindings has been performed.
P.6:
It is worth noting that a MN  => It is worth noting that an MN
P.7:
On the arrival of a MN, => On the arrival of an MN,
transition from a MN. => transition from an MN.
P.8:
Multicast streams from and to MNs arrive at a MAG on point-to-point
   links (identical to unicast). between the routers and independent of
   any individual MN.
=> not sure what to add, perhaps similar as in RFC 6224:
Multicast streams from and to MNs arrive at a MAG on point-to-point
   links (identical to unicast). >>Aggregated multicast streams between the
   MAG proxy instance and the LMA remain link-local<< between the routers and independent of
   any individual MN. ??

Please check!

P.9:
will seemlessly embed PMIP mobility gateways => will seamlessly embed PMIP mobility gateways

My 2 cents ;-)
Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Montag, 5. Dezember 2011 23:02
An: [email-masked]
Betreff: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00

Hello all,

Chairs
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 06 Dec 2011 10:23:36 -0600

Hi Dirk,

many thanks for the detailed feedback: we will carefully go over the 
document and improve/fix all these issues. We fully agree that a number 
of efforts need to go into the document.

We also are in the late stage of providing a corresponding proxy 
implementation which will be released soon.

Plan is: Document update and software release before Christmas :-)

Best wishes,

Thomas

On 06.12.2011 06:51, [email-masked] wrote:
>     links (identical to unicast).>>Aggregated multicast streams between the

-- 

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: Fri, 09 Dec 2011 09:07:39 +0900 (JST)

Hello,

> Please your comments by December 12, 2011.

1. The goal of this document is unclear. It seems that it focuses on
   both the MLD proxy type MAG and the PIM support. But there is no
   description about PIM support. See section 5. It just says "TODO"
   for both PIM-SM and Bidir PIM. It is impossible to understand
   anything from this condition.
   Moreover, this draft does not consider multicast routing functions
   on MAG. Except incomplete section5, only in section 1, it says;
   "Alternate solutions leverage performance optimization by providing
    multicast routing at the access routers directly, or by other
    dedicated schemes."
   I'd suggest that this draft just focuses on the source mobility
   only for rfc6224 and clearly mentions it. Title should be also
   changed as the current one is too broad.

2. With the regular MLD proxy (rfc4605), multicast packets sent from a
   host that attaches to the downstream link of an MLD proxy can be
   forwarded to both the downstream and upstream links. The problem
   for source mobility in rfc6224 is that multicast packets sent by MN
   should be directed to eliminate detour of the packets in case of
   MNs not charing MAG and/or LMA in some case and should not be
   directed in other cases, according to operators' policy. This
   scenario should be also considered when multiple MLD proxy
   instances are enabled in a MAG. Addressing this issue is the main
   contribution of source mobility for rfc6224.
   However, there is no detail discussion about it in section 6.1 and
   no solution defined at all. Section 6.1 only says "TODO datails" at
   the end.

3. There is no source handover discussion. A source mobility draft
   should be also described it with appropriate scenarios and data
   flows.

According to these considerations, it is too early to decide that this
draft is adopted.

Regards,
--
Hitoshi Asaeda

---

From: Aaron Feng <[email-masked]>
Date: Fri, 9 Dec 2011 10:52:40 +0800

I think draft-schm​idt-multim​ob-pmipv6-​source-00 can be adopted as
wg ID, though it
still needs some extensions to optimize.
In BIDIR PIM
1) there's no need to check whether the source is directly connected, which
is suitable for moilbe scenario.
2) If there are only receivers on branches of the network between the
source and the RP in PIM SM, traffic will also only flow toward the RP up
to that branching point, but not further on toward the RP, which may
contribute to local routhing.
Therefore, BIDIR PIM may be another hint.
           Best Regards,
           Aaron

---

From: seil jeon <[email-masked]>
Date: Sat, 10 Dec 2011 16:17:09 +0900

Hi Thomas,

I feel that the scope of this document is not clear because as you know, we
have no problem statement but only base deployment solution presented in
multimob.

My thought to move forward is as followed.

1. If this document targets to source mobility can be applied in RFC 6224,
that is MLD proxy on MAG, I agree for WG adoption of this document on the
condition that the document is well arranged after the section of routing
optimizations is removed in access network.

The introduction is now addressed as "This document describes the support
of mobile multicast senders in Proxy Mobile IPv6 domains as it is provided
by the base deployment scenario [RFC6224], as well as optimizations
throughout the access network infrastructure to efficiently solve the
source mobility problem as dicussed in [RFC5757]."

2. If this document includes routing optimizations, I think the document is
not ready to move forward.
   As Hitoshi pointed out, it needs to consider and address potential
issues. Now, section 5 seems to me as simple consideration not the solution
for multicast routing optimizations.

Best Regards,

Seil Jeon

-----------------------------------------------------------------------------------------

Soongsil Univ. Ubiquitous Network Research Center (SUNRC)

Homepage: http://sites.google.com/site/seiljeon

2011/12/9 Hitoshi Asaeda <[email-masked]>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 11 Dec 2011 15:35:50 -0500

Hi Bechet/Thomas,

I support adopting draft-schmidt-multimob-pmipv6-source-00 as a WG draft.

I also have the following comments which I think can be addressed in the next update once it becomes a WG draft:

1) Editorial - 2nd paragraph of section 1 (Introduction)
	- From: "... on the price of possibly ..."
	-   To: "... at the price of possibly ..."

2) Section 3 (Base Solution for Source Mobility: Overview), 2nd paragraph
	- Is it really a "downstream" link in this perspective or an "upstream" link?  Anyways, I know in cellular the direction from the MN to the network is referred to as the "uplink".

	- Also in the next paragraph (3rd paragraph), you refer to "upstream" ... Maybe this points to the need to really clearly define upstream/downstream directions in this I-D.

3) Figure 1
	- The bottom half of the Figure containing the "Multicast Senders and Listeners" is very busy and hard to decipher.  I suggest cleaning up this part of the figure as it took me a few reads of the associated text to understand it.

4) Section 3
	- There is a reference of an MN "using its source address with Home Network Prefix (HNP)".  Can you explain to me how this works for a 3GPP cellular network?  My understanding in 3GPP is that the GGSN assigns a dynamic IP address which is seen by anyone communicating with the MN in the Internet.  So is this GGSN assigned address the HNP you are referring to (i.e. the GGSN address would be the multicast source address)?  Or is this GGSN address different from the PMIP HNP you are referring to?

That's all for now.  I will continue reading the draft and send more comments later on.

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Monday, December 05, 2011 5:02 PM
To: [email-masked]
Subject: [multimob] WG adoption call ondraft-schmidt-multimob-pmipv6-source-00

Hello all,

Chairs

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 29 Dec 2011 21:23:28 +0100

Hi Akbar,

sorry for answering late - please see inline.

> 	-   To: "... at the price of possibly ..."

Thanks - we'll correct.

> 	- Is it really a "downstream" link in this perspective or an "upstream" link?  Anyways, I know in cellular the direction from the MN to the network is referred to as the "uplink".

In the sentence under question, the perspective is from the MAG 
("Multicast packets will arrive at the
    currently active MAG via one of its downstream local (wireless) 
links.") Being the MAG and following the Internet routing hierarchy, the 
wireless links towards MNs are downstream, while the tunnels to LMAs go 
up the routing hierarchy and therefore are coined upstream.

> 	- Also in the next paragraph (3rd paragraph), you refer to "upstream" ... Maybe this points to the need to really clearly define upstream/downstream directions in this I-D.

This follows the same picture - terminology is also consistent with the 
MLD/IGMP proxy notion. But we can add a remark in Section 2 on 
up-/downstream directions.

> 	- The bottom half of the Figure containing the "Multicast Senders and Listeners" is very busy and hard to decipher.  I suggest cleaning up this part of the figure as it took me a few reads of the…

O.K. - we can try to make this easier.

> 	- There is a reference of an MN "using its source address with Home Network Prefix (HNP)".  Can you explain to me how this works for a 3GPP cellular network?  My understanding in 3GPP is that the…

Well, this is somehow a confusing question. 3GPP does not use PMIPv6 and 
I guess you refer to IPv4. Anyhow, the MN uses the (permanent) source 
address (with HNP) that is assigned to it. The point here is that no 
special address selection mechanism is applied here. This would be the 
same in 3GPP, while the 3GPP MBMS works differently.

Thanks again! We are currently working on an update of the draft and 
will include your comments.

Best wishes,

Thomas

--