Subject: Re: [multimob] PMIPv6 Requirements Draft Updated

From: "Hui Deng" <[email-masked]>
Date: Wed, 17 Sep 2008 14:56:04 +0800

Hi, Hitoshi,

I had posted the draft, let's discuss in the mailing list.
Please check with:
http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-00
.txt

See reply inline.

> -----Original Message-----
> From: Hitoshi Asaeda [mailto:[email-masked]]
> Sent: Tuesday, September 16, 2008 11:23 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
[email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: PMIPv6 Requirements Draft Updated
>
> Hi,
>
> Couple of comments.
>
> 1. 3.1
>    "R1 - PMIPv6 multicast mobility management MUST transparently support
>    the reception of ASM and SSM channels."
>    Why MUST? It's too strong assumption. Some SPs may want to support
>    only SSM. In my sense, SSM is MUST, ASM is MAY.
==> if I replace "and" by "or", does it remove your concern?

> 2. 4.1
>    Text of this section is so much aware of service model like IPTV.
>    AAA and QoS stuff should not "SHOULD" in any place of this
>    document.
>    The way how AAA/QoS is managed depends on service models or service
>    providers. Only we can say "AAA or QoS may be necessary for some
>    multicast services and depend on the service models or providers."
==> "IPTV" appear only as the example of here, As you said "QoS" only appear
as May, For "AAA", how about this?
   AAA functions MAY resident at the LMA, in
   particular admission control and accounting, MAY be preserved and
   applicable under multicast services.

> 3. 4.2
>    "Hence support of MLDv2 [RFC3810] is required at the MAG."
>    I prefer to say, "MLDv2 or LW-MLDv2 is required". This document
>    only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not
>    needed?
==> fine, thanks

>
>    CAC is common word except with ATM? :)
==> Sure, but prefer remove "CAC", keep "Connection Admission Control"

>    Anyway, we should put more functional statements; what functions
>    are needed, and why.
==> Please try to propose it, thanks,

-Hui

> Regards,
> --
> Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 17 Sep 2008 23:23:33 +0900 (JST)

> ==> if I replace "and" by "or", does it remove your concern?

No, not really. ASM and SSM are independent.
In fact, I'd rather simply say, "SSM must be supported in PMIPv6
multicast."

> >    only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not

Since this document only discusses ipv6, so only saying MLDv2 and
LW-MLDv2 is fine.

> ==> Please try to propose it, thanks,

Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA
should be preserved at LMA".
Sect.4.2 says "CAC is supported at MAG, Network Attachment Control
should be supported at MAG".

In my feeling, the current statements require implementing these
functions in multicast protocols used in PMIPv6.
At first, these statements should be explained from operators
viewpoint. Not "LMA should control bw, MAG supports CAC", but
"Controlling bw is an operational requirement and may be implemented
at LMA". Then improve the whole sentence. (What are other operators'
requirement and why.)
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 18 Sep 2008 12:10:35 +0900 (JST)

Hi,

> ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and
> currently we see an IPTV  deployment on the basis of ASM (SSM strength is
> interdomain transparency, which is not needed nor desired in
> provider-bound IPTV offers).

It is not feasible.
I strongly disagree the sentense, "ASM is MUST".

> Anyway, the multicast flavor to actually deploy is the choice of any 
> individual provider ... but we want to define protocols (multicast
> extensions to PMIPv6), which enable such deployment. Therefore we should
> offer both multicast flavors and preserve the choice.

This is not the reason, ASM is MUST.
If you prefer the filexible choice, we should not say anything about
ASM and SSM.

> Also: from the client perspective, ASM is easier to implement. Since we
> are not heading to re-define multicast core routing (I suppose), we don't
> have to worry about ASM-specific problems in the inter-domain. That we can
> leave to the providers ... and to the work of the multicast routing WGs.

Obviously it is not always true; ASM is easier to implement.
I cannot agree above statements.

The possible solution is to not mention if ASM is required or not in
this draft.
Well, I can slightly think such discussion is not necessary in this
draft. But if some requirement discussed in this draft relates to the
multicast communication model and needs to mention ASM, then I do
recommend to remove "ASM is MUST" and use weaker sentence.

> There have been earlier (striking) arguments by Patrick to keep the MLD
> debate(s) out of this document. The issue here is the version 2, which is
> needed for SSM. Otherwise I would agree with Patrick to remain agnostic of
> MLD flavors and optimizations.

I've not started MLD discussion in this draft. It is out of scope of
this doc.
My concern is that the sentence, "MLDv2 is required", seems to imply
full functions defined in MLDv2 will be required. It is not true.
The point we want to imply here is that this draft requires the
capability of SSM by saying "MLDv2 is required".
Therefore "MLDv2 or LW-MLDv2 is required" makes better sense.

Regards,