Re: 4941bis and multicast & QOS

[Fernando Gont <[e-mail]>]

On 13/2/20 21:52, Gyan Mishra wrote:
> 
> Sorry Bert I missed your reply - responding now
> 
> On Sun, Feb 2, 2020 at 3:36 PM Manfredi (US), Albert E 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     From: ipv6 <[e-mail] <mailto:[e-mail]>> On
>     Behalf Of Gyan Mishra
> 
>      > How would multicast ASM or SSM work with the privacy extension
>     temporary address enabled.  With the privacy temporary address
>     enabled the IGMP Join would go out the temporary addresses, just as
>     would normal unicast traffic.
> 
>     That's a good question, although only SSM would be a problem. In
>     ASM, the IGMP/MLD join reports always go to the group multicast
>     address anyway, and presumably, that won’t change. The unique source
>     address of the client joining, or of the multicast source, should
>     not matter. When responding to a new IGMP query, a new source
>     address could be used in the report, still indicating to the router
>     that membership exists. I would think, no problem.
> 
> 
>     You make a good point as to where the problem may fall.  So with ASM 
> model the receiver is not source aware and so sends a IGMP join via 
> temporary address RPF interface for outgoing “client like” unicast 
> connections.  The LHR DR on the subnet creates MRIB state and forwards 
> *,G shared tree join along RPF path to the Anycast RP /MSDP - which has 
> active SA cache entry for the Source within the multicast routing 
> domain.  The LHR now learns the SA for the group and initiates SPT 
> switchover to the SPT tree and builds a tree directly to the source.
> 
> With SSM the receiver is source aware via MLDv2, which now has source 
> field in the packet for the SSM channel - along with well know default 
> SSM group 232/8 - receiver is able to send via temporary address S,G 
> join and to its LHR DR router on the subnet - which now builds SPT tree 
> directly to the source.
> 
> So this all works well in a client / server multicast model with pim 
> sparse-mode where the clients are receiver only and the server is source 
> only.
> 
> In a peer2peer multicast model where the source acts as both receiver 
> and source and the receiver acts as both receiver and source is the 
> “bi-dir PIM” model -  this is the MPLS MVPN world translates into MP2MP 
> LMDT instantiated via mLDP.
> 
> Multicast is predominately used in enterprises.  The internet MBONE 
> never really took off due to multicast use of UDP RTP  transport for 
> streaming and thus a requirement for end to end QOS for reliability.
> 
> So in the enterprise bi-dir pim model application requiring peer2peer 
> multicast is the only scenario where you would run into issues with the 
> privacy temporary address changing and becoming invalid resulting in 
> session reset.  The app based source discovery would have to trigger 
> changing of SSM channel when the source becomes invalid so the session 
> would not reset.
> 
> I think for this peer2peer model to work you really need a stable 
> address on the host.
> 
> This could be one use case where RFC 4941bis would fail - with removing 
> the stable address as it’s currently written.

rfc4941bis doesn't remove the stable address. It removes the 
*requirement* to configure one. Based on a number of factors (OS type, 
applications, type of network you're attaching to) an OS may want to do 
temp-only, or stable-temporary.

I would except that, by default, nodes do stable+temporary, and only 
resort to temp-only when they know better.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492