Subject: [multimob] Teleconference minutes

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 May 2009 07:55:42 -0700 (PDT)

Folks,
  There was a short call today. Here is a very short summary:

  In the call Suresh raised some issues similar to the points made during the BoF last November. He suggested that those questions have to be answered before moving ahead. He will post some text on the list today to initiate some discussion on this in the hopes of maybe coming up with a draft.

  There was some discussion on whether or not IPv4 multicast is in scope. Marshall thinks this is mainly IPv6 activity. Behcet said IPv4 is included. No conclusions were reached.

  Marshall thinks that Thomas posted a good road map which was followed up on the list by many and he thinks this is encouraging for the next BoF. He said coming up witha revised charter and contacting the AD are the next steps.

Regards,

Behcet

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 14 May 2009 11:09:32 -0400

On May 14, 2009, at 10:55 AM, Behcet Sarikaya wrote:

>   In the call Suresh raised some issues similar to the points made  
> during the BoF last November. He suggested that those questions have  
> to be answered before moving ahead. He will post some text on the  
> list today to initiate some discussion on this in the hopes of maybe  
> coming up with a draft.
>

The important step here is getting some operators to declare that they  
see this as a problem that needs to be addressed. (Even if the current  
deployments are experiments, if there is a foreseeable problem in the  
future, it still can and IMO should be addressed now.)

If anyone knows how to get such operator statements, I think that they  
should go ahead and try to get them.

Regards
Marshall

>   There was some discussion on whether or not IPv4 multicast is in  
> scope. Marshall thinks this is mainly IPv6 activity. Behcet said  
> IPv4 is included. No conclusions were reached.
>
>   Marshall thinks that Thomas posted a good road map which was  
> followed up on the list by many and he thinks this is encouraging  
> for the next BoF. He said coming up witha revised charter and  
> contacting the AD are the next steps.
>
> Regards,
>
> Behcet
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 May 2009 09:49:52 +0700

Marshall Eubanks [mailto://[email-masked]] writes:

> see this as a problem that needs to be addressed. 

I agree, with the operative term being "needs to be addressed": even if
there are problems, do they really need to be fixed or will things work well
enough as they are?

...

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 14 May 2009 23:25:57 -0400

> there are problems, do they really need to be fixed or will things  

Given the state of things, this will have to be a judgement call. But  
we need
operator input (and judgement).

Marshall

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 May 2009 07:45:39 -0700 (PDT)

Hi Glen,

  See my comments below.
  Regards,

Behcet

________________________________

From: Glen Zorn <[email-masked]>
To: Marshall Eubanks <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Thursday, May 14, 2009 9:49:52 PM
Subject: RE: [multimob] Teleconference minutes

Another one is multihomed mobile nodes. They may receive multiple copies of multicast data. 

Some other items we have in the proposed charter are of optimization nature, yes things work as they are but at what price?

[behcet] Some would, some others wouldn't. The most notable ones: Proxy Mobile IPv6 did not define multicasting support in RFC 5213. That leaves a gap as to how multicasting can be supported to the mobile nodes.

---

From: <[email-masked]>
Date: Fri, 15 May 2009 17:20:17 +0200

Dear all,
For a mobile operator using 3GPP/LTE with global customers a broad deployment of multicast services may become a problem when customers abroad and on the move are connected via a non-3G access - as using plain PMIP6 (e.g. with Bi-directional Tunneling) for the interconnection to home network, as described in http://www.ietf.org/internet-drafts/draft-sarikaya-multimob-overwireless-ps-00.txt would create a lot of inter-continental traffic. To save such expensive resources the extension of mobility protocols and/or multicast management protocols would be very beneficial.

Best regards,
Dirk

Dirk von Hugo
Deutsche Telekom AG
Laboratories
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Phone: +49 6151 937-2536        
Fax: +49 521 92109586
Mobile: +49 151 14620590
E-Mail: [email-masked]  
================================================================

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Marshall Eubanks
Gesendet: Freitag, 15. Mai 2009 05:26
An: Glen Zorn
Cc: [email-masked]
Betreff: Re: [multimob] Teleconference minutes

Marshall

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 19 May 2009 18:16:15 -0400

Hi Folks,
   Before we try for a BOF we need to answer the following question so 
that we do not spend the BOF discussing whether PMIPv6 already supports 
multicast or not.

* Is the performance penalty experienced by the operator using PMIPv6 
(AS IS) with multicast significant enough to warrant changing PMIPv6 
and/or the multicast protocols?

This question needs to be answered by the operators who are planning to 
deploy PMIPv6 and multicast along with deployment scenarios (if 
possible) before we can make any headway.

Thanks
Suresh

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 20 May 2009 12:05:28 +0100

I agree this is now the core issue to understand.

Gorry

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 20 May 2009 13:37:16 +0200

Hi Suresh,

you are right - the issue is in two ways:

  * first is the "real" penalty inherited from home tunneling - we have 
done simulation analysis on that some years ago: this is strongly 
dependent on the HA position and on the actual topology.

  * probably the more important aspect is the experience or "feeling" of 
operators. This is more on "how do operators want a PMIP multicast to be".

It would be good to hear opinions and experiences.

Thomas

Gorry Fairhurst wrote:
>> that we do not spend the BOF discussing whether PMIPv6 already 
>> supports multicast or not.
>>
>> This question needs to be answered by the operators who are planning 
>> to deploy PMIPv6 and multicast along with deployment scenarios (if

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 20 May 2009 23:03:52 +0900 (JST)

I totally agree with Suresh, while I have some concern for Thomas's
comments.

>   * first is the "real" penalty inherited from home tunneling - we
> have done simulation analysis on that some years ago: this is
> strongly dependent on the HA position and on the actual topology.

I don't think it is the "real" penalty. Home subscription (or
bi-directional tunneling) is simple and may be Okay for some situation
or providers. Living with bi-dir tunnel is not the real problem.

(Thomas said HA above, but I assume we have been discussing PMIPv6
multicast and follow it.)
The real problem in PMIPv6 multicast is that PMIPv6 does not provide
any "multicast state transition" for "both home and remote
subscription". This causes the "real" performance penalty and may
cause heavy packet loss.

In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just
subscribes interesting channels with MLD. When MN moves and attach
nMAG, both LMA and nMAG do not forward multicast data to that MN as
they don't have any multicast state for that MN and the MN does not
send *unsolicited* MLD reports for all subscribed channels again after
he attaches nMAG. (The current MLD sends unsolicited report only once
upon subscription; hence it is impossible to do it at the protocol
level.)

This major problem exists in both home and remote subscription.
Hence "supporting remote subscription" is not our sole goal or rather
inappropriate wording in the charter.

>   * probably the more important aspect is the experience or
> "feeling" of operators. This is more on "how do operators want a
> PMIP multicast to be".

It's good to clarify the expected condition from operator's
viewpoint. If this discussion can be based on some operators
experiences, it'd be nicer.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 20 May 2009 23:16:04 +0900 (JST)

> inappropriate wording in the charter.

I'm sorry. I wanted to say; we can mention "supporting remote
subscription" in the charter, but it is not the main aim of PMIP6
multicast extension and not our sole goal.
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 May 2009 07:51:46 -0700 (PDT)

Hi Suresh,
  I have a specific comment which you can see below. 
In general I would like to know what your answer would be yourself? I know you and I are not operators, but we do have opinions, don't we? :)

Regards,

Behcet

----- Original Message ----
From: Suresh Krishnan <[email-masked]>
To: [email-masked]
Sent: Tuesday, May 19, 2009 5:16:15 PM
Subject: [multimob] Gauging need for enhancing PMIPv6 multicast support

Hi Folks,
  Before we try for a BOF we need to answer the following question so that we do not spend the BOF discussing whether PMIPv6 already supports multicast or not.

* Is the performance penalty experienced by the operator using PMIPv6 (AS IS) with multicast significant enough to warrant changing PMIPv6 and/or the multicast protocols?

[behcet] Hitoshi mentioned some real performance problems. I would like to point out that PMIPv6 currently does not support multicasting explicitly.
This fact has been acknowledged by a PMIPv6 author by saying informally that we should have put this in the base spec, but we missed.
So any operator trying to deploy multicast with PMIPv6 would be at loss on how to do it. 
During the first BoF in Minneapolis this was discussed, I remember different people suggesting different ways of deploying multicast in PMIPv6.
How would an operator do this? Which suggestion do they follow?

Our answer is it should be IETF to standardize a solution so that all operators can use it.

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 20 May 2009 18:08:40 +0200

Hitoshi, Behcet,

  sorry, but I'm really confused.

  Hitoshi, you said: "The real problem in PMIPv6 multicast is that PMIPv6 
does not provide any "multicast state transition" for "both home and 
remote subscription". as well as "[...] both LMA and nMAG do not forward 
multicast data to that MN as they don't have any multicast state for that 
MN [...]".

  RFC5213 clearly states that the LMA has the functional capabilities of a 
HA as defined in RFC3775. Thus it supports bidir-tunneling.

  One may argue that the MAG acts in the sense of the MN according to 
RFC3775, which implies multicast capabilities, as well. However, RFC5213 
states in section 6.10.5: 

"[...] the mobile access gateway MUST use the destination address of the 
inner packet for forwarding it on the interface where the destination 
network prefix is hosted."

and (more important)

"If the mobile access gateway cannot find the connected interface for that 
destination address, it MUST silently drop the packet."

  ... I think we should try to argue very clearly. Otherwise we get the 
same problems as in the last BoF.

  Anyhow, any opinions from the operators subscribed to the list - there 
are some: Do you prefer an improved PMIP multicast support (cf. Suresh 
question)?

Cheers
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 21 May 2009 01:38:37 +0900 (JST)

Matthias,

> HA as defined in RFC3775. Thus it supports bidir-tunneling.

Whether LMA has the functionality of HA or not doesn't matter.

> states in section 6.10.5: 

It doesn't matter. MN or other equipment does not notify his multicast
state to its LMA or upstream router when he moves.

In home subscription in MIP, for instance, MN is the tunnel end point
and hence he can continuously receive multicast packets even if he
moves. This does not require any multicast state transition to HA. But
in PMIP6, MN is not the tunnel end point. When MN moves, nMAG must
inherit his multicast state, but no way to do it. This is the point.

> destination address, it MUST silently drop the packet."

I cannot understand what point solves the problem..

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 May 2009 09:41:32 -0700 (PDT)

----- Original Message ----
From: Matthias Waehlisch <[email-masked]>
To: Hitoshi Asaeda <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, May 20, 2009 11:08:40 AM
Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support

Hitoshi, Behcet,

[behcet] Why?

MN [....]".

[behcet] That's why the charter says PMIPv6 does not support multicasting explicitly. Yes there are some implicit things.

  One may argue that the MAG acts in the sense of the MN according to 
RFC3775, which implies multicast capabilities, as well. 

[behcet] Maybe but how? We are saying that let's define it clearly.

However, RFC5213 

and (more important)

[behcet] So unicast packets are addressed here, that's my interpreration.

[behcet] Matthias, if you are unhappy about anything in the charter, please state it clearly and also pls. provide an alternative text. That could take us somewhere.

Regards,

Behcet

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 20 May 2009 19:16:08 +0200

Hi again,

On Thu, 21 May 2009, Hitoshi Asaeda wrote:

> > RFC3775, which implies multicast capabilities, as well. However, 
> > RFC5213 states in section 6.10.5:
> 
  No - that's unclear for me. If a MN moves from MAG to nMAG, the LMA does 
not change. In particular, the LMA holds its previous states for a certain 
amount of time (cf. pg. 15 RFC5213). When the MN is attached to the nMAG, 
the LMA updates its binding and forwards data. If the LMA has sent 
multicast data before the movement, the LMA will sent mcast data 
afterwards. This corresponds to MIPv6.

  If the state timer of the LMA expires, it doesn't matter. The MAG is a 
function on an access router. Thus this entity operates MLD in the router 
part, which includes sending General Queries. This corresponds to MIPv6.

> I cannot understand what point solves the problem..
  I would say it prevent multicast.

  Anyhow, I'm just saying that we need stringent argumentation. Refering 
to Rajeev at the last BoF: We "need to enumerate the problems clearly." - 
otherwise we will end with the same result.

Cheers
  matthias

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 21 May 2009 09:06:14 +0900 (JST)

> the LMA updates its binding and forwards data.

For unicast, yes.

> If the LMA has sent 

How LMA knows which multicast channels should be forwarded when *that*
MN moves to nMAG?

> part, which includes sending General Queries. This corresponds to MIPv6.

Then MN replys *solicit* report and finally could receive multicast
data. But this time lag is not negligible at all and this *is* the
real performance problem I said.

Regards,
--
Hitoshi Asaeda

---

From: Jinwei Xia <[email-masked]>
Date: Thu, 21 May 2009 17:40:46 +0800

Hi Matthias

> > > "[...] the mobile access gateway MUST use the destination 
> address of 
> > > the inner packet for forwarding it on the interface where the 
> > > destination network prefix is hosted."
> > > 
> > > and (more important)
> > > 
> > > "If the mobile access gateway cannot find the connected interface 
> > > for that destination address, it MUST silently drop the packet."
> > 

Other questions you listed above have been answered by Hitoshi in another
mail.  

However this point you concern is a drawback of RFC5213, which only consider
unicast. The IP destination address in downstream packet is MN-HoA, whereas
it is multicast group address in IPdestination address field in multicast
downstream packet. This issue  is not negligible for multicast support in
PMIPv6.  This is why we should extend PMIP to support multicast.

BR
	Jinwei

> 
>   Anyhow, I'm just saying that we need stringent 
> argumentation. Refering to Rajeev at the last BoF: We "need 
> to enumerate the problems clearly." - otherwise we will end 
> with the same result.
> 
> 
> Cheers
>   matthias
> 
> --
> Matthias Waehlisch
> .  FU Berlin, Inst. fuer Informatik, AG CST .  Takustr. 9, 
> D-14195 Berlin, Germany .. mailto:[email-masked] .. 
> http://www.inf.fu-berlin.de/~waehl

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 21 May 2009 17:10:36 +0200

Hi Hitoshi,

  sorry for the late reply.

On Thu, 21 May 2009, Hitoshi Asaeda wrote:

> >   No - that's unclear for me. If a MN moves from MAG to nMAG, the LMA 
> > does not change. In particular, the LMA holds its previous states for 
> > a certain amount of time (cf. pg. 15 RFC5213). When the MN is attached 
> > to the nMAG, the LMA updates its binding and forwards data.
> 
> For unicast, yes.
> 
  Please refer to the section/page in RFC5213 where it is defined that 
states are tied to unicast only.

> > If the LMA has sent multicast data before the movement, the LMA will 
> > sent mcast data afterwards. This corresponds to MIPv6.
> 
  cf. RFC3775.

  Again, if the LMA is HA compliant, the LMA is enabled to act as mcast 
proxy. After movement, the nMAG will send a binding update to the LMA, 
which updates the tunnel endpoint. Multicast data will be sent to the 
updated tunnel - only the tunnel endpoint address changed.

> >   If the state timer of the LMA expires, it doesn't matter. The MAG is 
> > a function on an access router. Thus this entity operates MLD in the 
> > router part, which includes sending General Queries. This corresponds 
> > to MIPv6.
> 
> data. But this time lag is not negligible at all and this *is* the real 
> performance problem I said.
> 
  What is PMIP-specific in this scenario? It corresponds to MIPv6: The HA 
maintains a binding cache, as well.

Regards
  matthias

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 21 May 2009 17:49:34 +0200

Hi all,

sorry for returning late into the discussion.

What I read from the continued argument: it does not seem to be 
transparently clear how to deploy a minimal multicast support in a 
PMIPv6 environment. So this again stresses the need for a BCP document 
as proposed in the agenda.

Let's allow for some time to write up this document - and return to 
discussing details on its basis.

Best regards,

Thomas

-- 

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, 22 May 2009 01:40:09 +0900 (JST)

> updated tunnel - only the tunnel endpoint address changed.

Ok, now I understand we are not expecting the same situation.
You are talking about somehow providing multicast services without
protocol modification, while I'm talking the required function (or
required optimization?) for IP multicast support in PMIP6 domain.

In a nutshell, transmitting same multicast data over a number of
bi-dir tunnels established with LMA and MAG is not the real demand or
expectation of pure IP multicast, and we have been thinking about the
solution with the effective PMIP6 protocol modification.

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Fri, 22 May 2009 18:11:24 +0200

Dear all,
As stated before unfortunately I am not yet able to report operational experience since 3GPP Rel. 9 specifying the PMIP6 option for Enhance Packet Core of packet based LTE radio access (4G) is not yet concrete enough for planning deployment - but in case a scenario as foreseen by T-Mobile US (http://www.theonlyphoneyouneed.com/) for 2G and WLAN and for voice at present will be upgraded to multicast services (messaging, video, ...) a practible solution as planned by multimob is definitely required.
Perhaps other operators can add experimental results here? 

Best regards,
Dirk
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hitoshi Asaeda
Gesendet: Mittwoch, 20. Mai 2009 16:04
An: [email-masked]
Betreff: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 22 May 2009 09:22:00 -0700 (PDT)

Hi Hitoshi,
  Can you please explain more? Here you are pointing to the avalance problem which is well known. But I think that Matthias' point was related to the handover. How do you justify your handover processing?

Regards,

Behcet

----- Original Message ----
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Sent: Thursday, May 21, 2009 11:40:09 AM
Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support

Regards,

---

From: <[email-masked]>
Date: Mon, 25 May 2009 12:15:45 +0200

Hi all,

I share Dirk's opinion. Specification of PMIPv6 in 3GPP/EPC is not enough mature for planning deployment and, thus, we are far from being able to report experience. However there are motivations for multicast in mobility situation. Today, Mobile IPTV on 3G network is a pure unicast service; but growth of video traffic on 3G will require soon solutions for a better resource management. A solution is the offload where video traffic is handoff from 3G and WLAN when it is possible, so efficient mobility management is required. A complementary solution is obviously to leverage on multicast delivery especially as multicast is currently used for IPTV on fixed network. In this context multimob outcomes could help.

Regards
Pierrick    

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : vendredi 22 mai 2009 18:11
> À : [email-masked]; [email-masked]
> Objet : AW: [multimob] Gauging need for enhancing PMIPv6 multicast support
> 
> Dear all,
> As stated before unfortunately I am not yet able to report operational
> experience since 3GPP Rel. 9 specifying the PMIP6 option for Enhance
> Packet Core of packet based LTE radio access (4G) is not yet concrete
> enough for planning deployment - but in case a scenario as foreseen by T-
> Mobile US (http://www.theonlyphoneyouneed.com/) for 2G and WLAN and for
> voice at present will be upgraded to multicast services (messaging, video,
> ...) a practible solution as planned by multimob is definitely required.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 May 2009 12:21:14 +0200

Hi Pierrick,

great to hear - and yes, we want to be ahead of operator deployment :-).

Right now we are working on this minimal multicast deployment solution 
for PMIPv6 - so hopefully, we will soon have a track to a converging 
view on how multicast can be rolled out in PMIPv6 without any 
"headstanding".

Best regards,

Thomas

--

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2009 11:09:08 +0100

I think I am more concerned whether there is a perceived need for this 
work, rather than a standard that relies on this.  Specifically, is this 
likely to be the correct solution for this need?

This may require a prediction of the future deployment, and it would be 
good to see then that we all agree on the use-cases and needs that would 
result.

Gorry

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 May 2009 13:43:23 +0300

Suresh,

> and/or the multicast protocols?

My key takeaway from the previous BOF was that we had no agreement on 
what"AS IS" means. That is, some people felt that the specification 
clearly dictated an inefficient model, and others -- including one of 
the chairs of the NETLMM WG -- felt that the specification allowed 
different ways to build and configure networks, including at least some 
forms of efficient multicast treatment.

So I think the question is actually more complex. I think we have a 
continuum:

(a) we don't even care, because we are not going to use multicast with 
proxy mip
(b) no new protocol mechanisms needed, and specifications are clear on 
how to use existing ones efficiently
(c) no new protocol mechanisms needed, but we need better operational 
instructions on how set up proxy mobility in the most efficient way
(d) better operational instructions and new protocol mechanisms are needed

Jari

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 May 2009 13:08:10 +0200

Hi Jari,

thanks for clarification!

> (a) we don't even care, because we are not going to use multicast with 

This, I guess, should be answered by operators and service providers - 
there have been a few strong statements for the use of multicast, but 
silence from many others.

> how to use existing ones efficiently

Discussions on mailing lists and in meetings seem to speak a clear 
language: there is quite some confusion, ranging from "PMIPv6 objects 
multicast" up to "clearly it works with multicast".

Clear or not: RFC5213 does not discuss multicast and seems to leave room 
for open questions.

> instructions on how set up proxy mobility in the most efficient way

As we believe it is needed, we are currently working on such an 
operational instruction document - without modifying protocols. However, 
the current PMIPv6 architecture does not allow for multicast route 
optimization, so minimal solutions cannot follow the "most efficient way".

> (d) better operational instructions and new protocol mechanisms are needed

There is plenty of room for optimization: The question, whether it's 
needed and desired, is more of an operational/political one.

Best regards,

Thomas

--

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 May 2009 14:47:38 +0300

Thomas,

>
>> (b) no new protocol mechanisms needed, and specifications are clear 
>> on how to use existing ones efficiently
>
> Clear or not: RFC5213 does not discuss multicast and seems to leave 
> room for open questions.

I tend to agree with this -- if we need to have a debate, then at least 
some better documentation is warranted.

Jari