Re: 4941bis and multicast & QOS

Fernando Gont <fgont@si6networks.com> Sat, 15 February 2020 18:10 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0909B12008A for <ipv6@ietfa.amsl.com>; Sat, 15 Feb 2020 10:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9-Xc40ldHvZ for <ipv6@ietfa.amsl.com>; Sat, 15 Feb 2020 10:10:27 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EB5120058 for <6man@ietf.org>; Sat, 15 Feb 2020 10:10:26 -0800 (PST)
Received: from [192.168.100.107] (unknown [186.183.49.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F071C86B51; Sat, 15 Feb 2020 19:10:21 +0100 (CET)
Subject: Re: 4941bis and multicast & QOS
To: Gyan Mishra <hayabusagsm@gmail.com>, "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: 6MAN <6man@ietf.org>
References: <CABNhwV0AHFmq9QcTwhgUWmaahaXvGW95abg+s8Uf7NQ2KHhhKw@mail.gmail.com> <4b6225b43a12499caa9dfe99200e74e3@boeing.com> <CABNhwV2q3_hCpU5gQYVT6mnZfu8ac1vyE6Mon_-6qCsdptRq-Q@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <2c566615-72ab-2fe0-e0b5-aefa570149bb@si6networks.com>
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: <CABNhwV2q3_hCpU5gQYVT6mnZfu8ac1vyE6Mon_-6qCsdptRq-Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kx3xyVDnrbgvamNaxhFSWcKJfzA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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 
> <albert.e.manfredi@boeing.com <mailto:albert.e.manfredi@boeing.com>> wrote:
> 
>     From: ipv6 <ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>> 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: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492