Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 01 Nov 2008 10:52:40 +0100

Hi Hui,

if I see things correctly, this scenario is already used in the pmipv6 
solution draft ... so it is probably helpful to first properly identify 
it in the requirements document.

IMHO, as the main objective, the requirements document should clearly 
identify the "world we work in", i.e., all the requirements & 
constraints, as well as the general scenarios.

If we suppress relevant issues here and bring them up in the solutions 
later, the might be neither transparent nor helpful.

Best regards,

Thomas

Hui Deng wrote:
> Hi,  Thomas,
>  
> I agree this scenario works for some deployment, but question here is 
> whether we need extend any pmip6 protocol to support this scenario?
>  
> thanks
>  
> -Hui
> 
> 2008/10/24 Thomas C. Schmidt <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Hi Behcet,
> 
>     Behcet Sarikaya wrote:
> 
>         [thomas] RFC5213 does not address multicast routing (that's why
>         we are
>         discussing it). The scenario described in fig 2 is *not* addressing
>         mobile multicast senders,
> 
>         [behcet] Then I think the text and figure on the local routing
>         is not needed because local routing in PMIPv6 refers to the
>         routing of packets coming from the uplink and as you said this
>         would be multicast sender situation which you left out in the
>         requirements draft.
> 
> 
>     [thomas] This is a misunderstanding: Fig 2 does *not* refer to
>     sender mobility.
> 
> 
>         but a typical content distribution setting as
>         for instance used in a provider-centric IPTV service. This means, a
>         provider issues multicast streams from within his network
>         domain, aiming
>         at an efficient way to preserve (his own) network resources.
> 
>          From the minimal perspective of RFC5213 (unicast routing) there
>         is no
>         efficient way to do this. That's why we are trying to identify
>         protocol
>         extensions that smoothly cooperate with RFC 5213.
> 
>         [behcet] The situation you are talking about could become valid
>         if route optimization is used with PMIPv6. In that case the
>         content server in between MAG and LMA would send directly to
>         MAG. If route optimization is not used then all traffic goes
>         through LMA-MAG tunnel. Route optimization for PMIPv6 is some
>         future work, there are drafts but we don't know if the
>         standardization will go ahead.
>         Route optimization with multicasting is even more complicated
>         problem. If you wish to state some requirements for this very
>         complicated case please go ahead.
> 
> 
>     [thomas] Hmm, I'm not trying to add complicated requirements. This
>     is the overview about possible scenarios.
>      We're all just trying to think of a reasonable scope to address and
>     solve the problem (so does the recent pmip6-extension-draft ... see
>     also the last mail from Hitoshi).
> 
>     If multicast on PMIPv6 is supposed to serve as a solution for
>     large-scale content distribution (like in IPTV applications), then
>     we should not just propose to tunnel all traffic from one LMA to the
>     MAGs. That's a bitter pill for those who have to pay for the
>     infrastructure.
> 
> 
>     Best regards,
> 
>     Thomas
> 
>     -- 
> 
>     ° Prof. Dr. Thomas C. Schmidt
>     ° HAW Hamburg, Dept. Informatik
>     ° University of Applied Sciences
>     ° Berliner Tor 7, D 20099 Hamburg, Germany
>     ° Fon: +49-40-42875-8452, Fax: -8409
>     ° http://www.informatik.haw-hamburg.de/~schmidt
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Hui Deng" <[email-masked]>
Date: Sun, 2 Nov 2008 09:24:39 +0800

Hi, Thomas

It seems my question wasn't answer, does PMIP6 need extention to support
local routing?

Regarding to your suggestion, that scenario in pmip solution is just
briefly mentioned.
other than our figure plus detail description. It might be ok that we could
describe local routing with similar word number like pmip6 rfc?

thanks

-Hui

2008/11/1 Thomas C. Schmidt <[email-masked]>

> solution draft ... so it is probably helpful to first properly identify it
> in the requirements document.
>
> identify the "world we work in", i.e., all the requirements & constraints,
> as well as the general scenarios.
>
>> 2008/10/24 Thomas C. Schmidt <[email-masked] <mailto:
>> [email-masked]>>
>>
>>    Hi Behcet,
>>
>>    Behcet Sarikaya wrote:
>>

---

From: <[email-masked]>
Date: Thu, 6 Nov 2008 16:08:06 +0100

Hi Hitoshi,

Stating "All multicast traffic goes through an LMA-MAG tunnel" is probably not an issue for short term deployment of multicast services. However I think we should not presume of the mid-term/long-term architecture and give options allowing operators to envisage different architectures. It is not only for local routing purpose; for instance, I guess we can imagine architecture reusing multicast IPTV backhaul for fixed network. In that case multicast routing between MAG and LMA could make sense. 

So, to conclude I think we should keep the option where the MAG may act as a multicast router and not request the LMA to always be on the multicast delivery path.

Any thoughts of other people?

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Hitoshi Asaeda
> Envoyé : samedi 1 novembre 2008 06:41
> À : [email-masked]
> Objet : Re: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-
> 01.txt
> 
> > So, I'd like to again ask the question especially to operators who
> > plan to or may prepare PMIPv6 multicast services; Is there a big
> > impact or problem if all multicast traffic goes through an LMA-MAG
> > tunnel?
> 

> > Note that our PMIPv6 multicast extension draft tentatively supports
> > the local routing, but I personally think it can be removed if
> > consensus.
> 
> Well, it may not be necessary to completely remove the possibility
> from the document, but specify "optional" as the minor case. Same for
> the requirement draft.
> --
> Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 06 Nov 2008 16:32:35 +0100

Hi Pierrick,

I closely agree with your statements - please see below:

> So, to conclude I think we should keep the option where the MAG may act as a multicast router and not request the LMA to always be on the multicast delivery path.

Multicast deployment in PMIPv6 via LMA -> MAG tunnels (these are 'n' 
tunnels) is always a quick and simple, but fairly inefficient solution. 
Of course we don't want to prevent this approach, but fixing PMIPv6 
multicast standards to this alone might not be really helpful in 
practice. We should also be aware of MTU-size issues resulting from 
tunnels at the receiver side.

There are at least two reasonable alternatives:

  * LMA -> MAG point-to-multipoint tunnels, which increase distribution 
efficiency, but still bear MTU-size issues

  * MAG as last-hop multicast router, with LMA being on the path or not. 
As far as I can foresee, operators might be interested in using this 
option, as - being aware of 'legitimate' multicast offers - they can 
keep full control of multicast forwarding states & traffic.

Best regards,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 07 Nov 2008 00:52:53 +0900 (JST)

Hi Thomas,

Thanks for your comments.

>   * LMA -> MAG point-to-multipoint tunnels, which increase
> distribution efficiency, but still bear MTU-size issues

Seems interesting, but what is MTU-size issue here?

>   * MAG as last-hop multicast router, with LMA being on the path or
> not. As far as I can foresee, operators might be interested in using
> this option, as - being aware of 'legitimate' multicast offers -
> they can keep full control of multicast forwarding states &
> traffic.

Why MAG, which is not working as a multicast router but MLD proxy,
cannot control forwarding states and traffic?

Thanks,

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 07 Nov 2008 00:39:54 +0900 (JST)

Hi Pierrick,

> Stating "All multicast traffic goes through an LMA-MAG tunnel" is
> probably not an issue for short term deployment of multicast
> services. However I think we should not presume of the
> mid-term/long-term architecture and give options allowing operators
> to envisage different architectures. It is not only for local
> routing purpose; for instance, I guess we can imagine architecture
> reusing multicast IPTV backhaul for fixed network. In that case
> multicast routing between MAG and LMA could make sense. 

If it is reasonable from operator's perspective, I'm happy to keep it
as is.

> So, to conclude I think we should keep the option where the MAG may
> act as a multicast router and not request the LMA to always be on
> the multicast delivery path.

I understand. Thanks for your comment.

Folks, other comments (either agree or disagree) would be always
welcome.
Thanks,
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 06 Nov 2008 17:12:54 +0100

Hi Hitoshi,

> Seems interesting, but what is MTU-size issue here?
Just the regular MTU-size reduction from the tunnel overhead.

> cannot control forwarding states and traffic?

Sorry, this was not precise: the regular MLD proxy function of course 
does not provide an explicit group control. However, operators can 
control multicast traffic distribution in their network and they could 
prevent MAGs from implementing unwanted states by some ACL mechanism 
(beyond MLD).

Best regards,

Thomas
--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 07 Nov 2008 01:39:21 +0900 (JST)

> Just the regular MTU-size reduction from the tunnel overhead.

I got it.

> Sorry, this was not precise: the regular MLD proxy function of
> course does not provide an explicit group control. However,
> operators can control multicast traffic distribution in their
> network and they could prevent MAGs from implementing unwanted
> states by some ACL mechanism (beyond MLD).

I think it would be possible for an MLD proxy to implement some ACL
mechanism without the protocol modification.
But anyway, discussing such requirement is useful. Thanks.
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 06 Nov 2008 18:02:43 +0100

> But anyway, discussing such requirement is useful. Thanks.

Sure - this was not proposing to extend protocol. Just a discussion of 
possible deployment scenarios ... and operator options.

Regards,

Thomas
--

---

From: "Hui Deng" <[email-masked]>
Date: Sun, 9 Nov 2008 23:59:36 +0800

Hi, Thomas,

I would agree this scenario,
as I asked before, it will not extend any protocol, only description of
functionality of network entity, maybe more implementation issue.

then my question here is do we need keep this a specific scenario figure in
our draft?

thanks again.

-Hui

2008/11/7 Thomas C. Schmidt <[email-masked]>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 09 Nov 2008 17:44:01 +0100

Hi Hui,

Hui Deng wrote:

> then my question here is do we need keep this a specific scenario figure 
> in our draft?
>
I guess yes: may be we even should add a third scenario with the LMA on 
path ... the objective being a helpful sketch of the scenarios we 
operate in.

Best regards,

Thomas

> 2008/11/7 Thomas C. Schmidt <[email-masked] 
>     Sure - this was not proposing to extend protocol. Just a discussion
>     of possible deployment scenarios ... and operator options.
> 
> 
>     Regards,
> 
>     Thomas
>     -- 
> 
>     [email-masked] <mailto:[email-masked]>

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 Nov 2008 09:52:53 -0800 (PST)

Hello all,
  At Multimob BoF last week it became clear that PMIPv6 requirements draft concentrated (probably) too much on the operating requirements and failed to state some simple traffic requirements.
  I remember these traffic requirements were already stated in the pre BoF meeting we had in Dublin.
  Any comments? Suresh?

Regards,

Behcet

---

From: "John.zhao" <[email-masked]>
Date: Mon, 01 Dec 2008 17:08:45 +0800

Hi,Behcet and all
 
    My two cents.
     As my understanding,we need optimize the traffics between MAG and LMA
and also include the tunnel between old MAG and new MAG. 
 
    Best Rgds
Thanks,

john.zhao

Hello all,
  At Multimob BoF last week it became clear that PMIPv6 requirements draft
concentrated (probably) too much on the operating requirements and failed to
state some simple traffic requirements.
  I remember these traffic requirements were already stated in the pre BoF
meeting we had in Dublin.
  Any comments? Suresh?

Regards,

Behcet