Subject: Re: [multimob] Session in IETF-81: Multicast Context Transfer for Mobility Protocol Standards

From: <[email-masked]>
Date: Thu, 7 Jul 2011 14:37:03 +0200

Dear Thomas, Matthias, Rajeev, and Gorry,

though your handover related draft draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04 had not changed much since last session I would like to ask some questions I had when re-reading it recently:

First of all I like the simple idea for the NMAG/NAR to just send MLD to PMAG/PAR to receive 'old' multicast data. It only might complicate things when MAG and LMA are native multicast routers by having to add MLD proxy functionality.
I wonder whether in reactive scenario without buffering at PMAG/PAR a loss of data may occur before NMAG-NAR has completed subscription ...

Some minor observations:

Saying on page 6:
On reception of the HI message, NAR returns a multicast acknowledgement in its HACK answer
   that indicates its ability to support each requested group

Doesn't this imply in Figs. 2 and 4 that "Join to multicast groups" at NMAG/NAR has to occur _before_ replying to PMAG/PAR with "HAck(Multicast AckOpt)" because otherwise NMAG/NAR cannot confirm ist ability?

Saying on page 8:
 Note that group traffic may already arrive from a MN's subscription
   at the time NAR receives the HI message.
This deals with group traffic from another MN's subscription arriving at NAR, right?

And just for clarification: In Fig.3 the RtSolPr/PrRtAdv is meant to happen between MN and PAR (as fepicted) to show the previous attachment, and not between MN and NAR, corresponding to sect. 4.1.3. saying:
   NAR will advertise its multicast support by setting the M-bit in
   PrRtAdv.

Saying on page 9 (on PMIPv6):
 In either case, the PAR will become knowledgeable about multicast group subscriptions of the MN.

PAR means the same as PMAG (PAR) in the following text - and do I understand correctly that PAR shall indicate that MAG is also the 1st router of the AN towards MN?

Finally some very minor nits:

Page 6:
As group membership information are present => As group membership information is present

Page 13:
and intersect the request subscription => and intersect the request for subscription
Bidiretional => Bidirectional

Page 16:
details on message formats. => details on message formats).

BTW I would recommend a consistent writing throughout the document of HACK/HAck/HACk (e.g. RFC 5949 says "Hack"), FBACK/Fback, and NMAG/nMAG ...

As we say: nix für ungut, ja?
;-)
Thanks!

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Donnerstag, 2. Juni 2011 18:31
An: [email-masked]
Betreff: [multimob] Session in IETF-81

Folks,
  We need to come up with a draft agenda by June 10.
I expect that Quebec City session will be more on handover related drafts.
Tunnel convergence drafts were discussed in depth in Prague.

Based on this, please send your session requests to the chairs.

Regards,

Behcet

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jul 2011 09:21:33 -0700 (PDT)

BTW 
nix für ungut, ja?
means no offense :-).

Behcet

-
> though your handover  related draft 
>draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04 had not changed  much since 
>last session I would like to ask some questions I had when re-reading  it 
>recently:
> 
> First of all I like the simple idea for the NMAG/NAR to just  send MLD to 
>PMAG/PAR to receive 'old' multicast data. It only might complicate  things when 
>MAG and LMA are native multicast routers by having to add MLD proxy  
>functionality.
> I wonder whether in reactive scenario without buffering at  PMAG/PAR a loss of 
>data may occur before NMAG-NAR has completed subscription  ...
> 
> Some minor observations:
> 
> Saying on page 6:
> Doesn't this imply in Figs. 2 and 4 that "Join to multicast groups"  at 
>NMAG/NAR has to occur _before_ replying to PMAG/PAR with "HAck(Multicast  
>AckOpt)" because otherwise NMAG/NAR cannot confirm ist ability?
> 
> Saying on  page 8:
> And just for clarification: In Fig.3 the RtSolPr/PrRtAdv is meant  to happen 
>between MN and PAR (as fepicted) to show the previous attachment, and  not 
>between MN and NAR, corresponding to sect. 4.1.3. saying:
> PAR  means the same as PMAG (PAR) in the following text - and do I understand  
>correctly that PAR shall indicate that MAG is also the 1st router of the AN  
>towards MN?
> 
> BTW I would recommend a consistent writing throughout  the document of 
>HACK/HAck/HACk (e.g. RFC 5949 says "Hack"), FBACK/Fback, and  NMAG/nMAG ...
>

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 8 Jul 2011 22:50:42 +0200

Hi Dirk,

  thanks a lot for your message and sorry for the delay. Please see 
comments inline.

On Thu, 7 Jul 2011, [email-masked] wrote:

> draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04 had not changed 
> much since last session I would like to ask some questions I had when 
> re-reading it recently:
> 
> First of all I like the simple idea for the NMAG/NAR to just send MLD 
> to PMAG/PAR to receive 'old' multicast data. It only might complicate 
> things when MAG and LMA are native multicast routers by having to add 
> MLD proxy functionality. I wonder whether in reactive scenario without 
> buffering at PMAG/PAR a loss of data may occur before NMAG-NAR has 
> completed subscription ...
> 
  as usual in PFMIPv6, packet loss may occur if there is no buffering: 
"MN will be able to participate in multicast group communication with a 
handover performance comparable to that for unicast, while network 
resources consumption is minimized." (page 6).

> NMAG/NAR has to occur _before_ replying to PMAG/PAR with 
> "HAck(Multicast AckOpt)" because otherwise NMAG/NAR cannot confirm ist 
> ability?
> 
  No, with respect to the group service the Multicast Acknowledgement 
Option indicates if (a) group service is unsupported or (b) group 
service is administratively prohibited. This does not say if the group 
service is available.

  If the NAR waits for direct multicast traffic this would require some 
timeout mechanisms and (in the worst case) would lead to an additional 
delay.

> This deals with group traffic from another MN's subscription arriving 
  Yes, but it can also indicate that a branching point is close to the 
NAR.

> And just for clarification: In Fig.3 the RtSolPr/PrRtAdv is meant to 
> happen between MN and PAR (as fepicted) to show the previous 
> attachment, and not between MN and NAR, corresponding to sect. 4.1.3. 
> saying:
>
  Not necessarily. A NAR sends a PrRtAdv based on a RtSolPr by the MN. 
In this case, it advertises its multicast support, as well. This is 
mentioned just for completeness. Maybe we should clarify this.

> PAR means the same as PMAG (PAR) in the following text - and do I 
> understand correctly that PAR shall indicate that MAG is also the 1st 
> router of the AN towards MN?
> 
  Yes, we will correct this.

> HACK/HAck/HACk (e.g. RFC 5949 says "Hack"), FBACK/Fback, and NMAG/nMAG 
  Agree with all of corrections.

> As we say: nix für ungut, ja?
  And many thanks your the careful reading!

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet 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: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 13 Jul 2011 13:45:43 +0200

Dear Dirk,

first of all many thanks for your careful review!

While I was away, Matthias has answered to most of your questions / 
issues ... so let me just add a few details.

On 07.07.2011 14:37, [email-masked] wrote:

> though your handover related draft draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04 had not changed much since last session ...

Yes, we actually wait for progress with this document - actually, the 
first draft is from San Francisco IETF (years back ;) ).

> First of all I like the simple idea for the NMAG/NAR to just send MLD to PMAG/PAR to receive 'old' multicast data. It only might complicate things when MAG and LMA are native multicast routers by h…

Actually, as a full mcast router you are not required to have an 
additional MLD proxy functionality. All you need is the ability to parse 
MLD records (which is normally present at routers). Whenever you are a 
full router, you can use the NAR-PAR tunnel as a Multicast-enabled link, 
which is identical to MLD proxying (for that uplink) here.

> I wonder whether in reactive scenario without buffering at PMAG/PAR a loss of data may occur before NMAG-NAR has completed subscription ...

As Matthias wrote: there is packet loss (like in the unicast case) which 
we analyzed and quantified in Reference [FMIPv6-Analysis].

> Doesn't this imply in Figs. 2 and 4 that "Join to multicast groups" at NMAG/NAR has to occur _before_ replying to PMAG/PAR with "HAck(Multicast AckOpt)" because otherwise NMAG/NAR cannot confirm is…

As Matthias said: this is not a report on mcast routing success, thus 
not generated from actual packet observation.

>     NAR will advertise its multicast support by setting the M-bit in

RtSolPr/PrRtAdv is the general client signaling of FMIPv6. So it occurs 
between MN and all ARs.

I guess, the rest was already exhaustively discussed.

See you in Quebec!

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 °