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
- 4941bis and multicast & QOS Gyan Mishra
- RE: 4941bis and multicast & QOS Manfredi (US), Albert E
- Re: 4941bis and multicast & QOS Gyan Mishra
- Re: 4941bis and multicast & QOS Mark Smith
- Re: 4941bis and multicast & QOS Gyan Mishra
- Re: 4941bis and multicast & QOS Mark Smith
- Re: 4941bis and multicast & QOS Gyan Mishra
- Re: 4941bis and multicast & QOS Fernando Gont
- Re: 4941bis and multicast & QOS Gyan Mishra
- Re: 4941bis and multicast & QOS Gyan Mishra