Re: 4941bis and multicast & QOS

Fernando Gont <> Sat, 15 February 2020 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0909B12008A for <>; Sat, 15 Feb 2020 10:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O9-Xc40ldHvZ for <>; Sat, 15 Feb 2020 10:10:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69EB5120058 for <>; Sat, 15 Feb 2020 10:10:26 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F071C86B51; Sat, 15 Feb 2020 19:10:21 +0100 (CET)
Subject: Re: 4941bis and multicast & QOS
To: Gyan Mishra <>, "Manfredi (US), Albert E" <>
Cc: 6MAN <>
References: <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Sat, 15 Feb 2020 14:20:35 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Feb 2020 18:10:30 -0000

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 
> < <>> wrote:
>     From: ipv6 < <>> 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.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492