Subject: [multimob] A couple of comments on draft-ietf-multimob-pmipv6-source-02

From: Stig Venaas <[email-masked]>
Date: Fri, 08 Feb 2013 14:54:42 -0800

Hi

The document is in a pretty good shape. I found one issue though.

In 4.3.3 it says:

    On handover, the mobile source reattaches to a new MAG (DR), and
    PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
    point of attachment.  However, in the absence of a corresponding
    multicast forwarding state, the new DR will treat S as a new source
    and initiate a source registering of PIM phase one.  In consequence,
    the PIM transition from phase one to two will be iterated per
    handover, leading to an enhanced signaling load and repeated delay
    variations.

This is not really the case. The new MAG should be sending registers to
the same RP as the previous MAG did. If registration had completed so
that no more data registers were sent by the previous MAG (only periodic
null-registers to maintain the (S,G) state on the RP), the RP would
immediately respond with a register stop when it receives a register
from the new MAG. Basically, the RP behavior does not depend on who is
sending the registers.

Independent of the registers, if the RP had joined the SPT to receive
from the source, the SPT would be updated and joins would go towards
the new MAG.

The same for 4.3.4.

Two minor editorial things I spotted:

such as IPTV or sever-centric gaming on mobiles.  However, current
                 ^^^^^

    bindings) has been performed .  Still multicast packets arriving at
                               ^^^

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 09 Feb 2013 10:16:46 +0100

Hi Stig,

thanks ... we'll be back on this shortly ... currently on travel ;)

Cheers,

Thomas

On 08.02.2013 23:54, Stig Venaas wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

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: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Feb 2013 11:45:00 -0800

Hi Stig,

thanks again for your comments and sorry for coming back late on this.

We adjusted the PIM phase transition details you pointed at in our 
recent post.

However - without questioning the judgement of the PIM co-chair ;) - 
there are a couple more involvements.

First, the moving source arrives at a different (tunnel) interface of 
the RP ... so PIM implementations need to being able to cope with this 
change ...

... second, the SPTs don't point directly to the MAGs, but to the LMA 
(-tunnel interface). In theory, this is a stability anchor which 
simplifies, but in practice an unmodified PIM-RP would not know and had 
to re-iterate phase transitions ... otherwise, if the stable LMA weren't 
in place, data streams would be lost.

Our update is just a quick sketch ... I guess, some editorial polishing 
is needed.

In addition, we moved the multiple upstream proxy to the appendix as 
desired in the Atlanta meeting.

Cheers,

Thomas

--

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Feb 2013 14:37:14 -0800

> the RP ... so PIM implementations need to being able to cope with this

Even though the source address is different, the RP isn't treating them
as arriving on different tunnel interfaces. But basically, as you can
see from 4601, the RP doesn't care at all who sent the register (apart
from where to send a register stop if needed). This means the behavior
when receiving registers is not really affected by the source moving.

> in place, data streams would be lost.

Since the RP doesn't take the source address of the register into
account, there are no transitions on the RP due to the source
mobility. When it gets a data register from the new DR, it will
behave the same as if it got a data register from the old DR.

It may be easiest for me to explain this face to face...

Stig