Re: 4941bis and multicast & QOS

Gyan Mishra <hayabusagsm@gmail.com> Sat, 15 February 2020 20:33 UTC

Return-Path: <hayabusagsm@gmail.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 1ED441200E3 for <ipv6@ietfa.amsl.com>; Sat, 15 Feb 2020 12:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 t2NvUOLyfodY for <ipv6@ietfa.amsl.com>; Sat, 15 Feb 2020 12:33:09 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6881200D7 for <6man@ietf.org>; Sat, 15 Feb 2020 12:33:08 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id p8so11002792iln.12 for <6man@ietf.org>; Sat, 15 Feb 2020 12:33:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Icfq1eeiRk4OTSfDKlkzZprO4IhmLbyxOh5H8ArB5pA=; b=oD8qc5OwciZplcFmFh1/zIYQSFJsrcavLx4+P0IbWNpF3sP8f6Kur9aLKFk7uiN1lR gty6xSDgUeElU4KyAjhO8l7xUVLPhJ5X77l42kZ/r57ENTt3uZxjxmsFqaY+DBhnirXg tNsj0WSnR17JWlkwHFoSrKyNYfgR68JrcJsvzpBNUiJL9ZJ08aS6u0Xm6kFSEQo3xvLU U5O8fZ7unCZIiQeuiHO8TNEupVu7FbVn01UsnJ7SFyaVq8w+FVv+mhyW4TqEhBOx9xGQ dsh5qPyRe0H6owPaD5Sqo0/PI82G2FPal9b/I/pGMsE52tJ6HEd26tHdjPzt9xPD/AEe 9zrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Icfq1eeiRk4OTSfDKlkzZprO4IhmLbyxOh5H8ArB5pA=; b=HSTKz9aZX9i4YN4LmUHKrA3GvtrIJeI7D66/8Zja5xzURqLAL5Bojsl5H6j5ln+GXT ud1/rhd12YoTzLhKObWACQ5jp0EtChP3SQcw2Eb3Q0rCQv7KvqnhMs6Nwqs8qG5ITBDf Q5XvOEerYb4WG0EDRnQiAZ1xg8sE7Wu6tbayczKw6lJlY5w+7I1z2dDrRivsGbm+7eZG OyKDx1Te9f4ZroJRvCeu7/LTv1pIF3Bq9rCRCvF9f5zh/YgsKQD8Xm3kRzlQ4W2LiyUv vwld76sptcyseSzG/GLOU0v9vEWbI0PWId25/sJJPVyVqHjRg6/5bvaZhYc0CSgiJItt 1SDg==
X-Gm-Message-State: APjAAAU/R0u5C18svExRBIisRYGyh7MHAQxk/3o7nrImeEGrxwxwAZHq zz0CXCiLQRXuVf2OfRy01rwtwfQPKHM93esHysg=
X-Google-Smtp-Source: APXvYqxY1J5Jc8g1XQmtB8qgq1+RzvjBN9dP4Tl2Gm+Nkeh7ozLZ7oC5qtdg/K205nQj2lFLS8ZVZmlER0pVcyjfHA0=
X-Received: by 2002:a92:af44:: with SMTP id n65mr8269415ili.158.1581798788204; Sat, 15 Feb 2020 12:33:08 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV0AHFmq9QcTwhgUWmaahaXvGW95abg+s8Uf7NQ2KHhhKw@mail.gmail.com> <4b6225b43a12499caa9dfe99200e74e3@boeing.com> <CABNhwV2q3_hCpU5gQYVT6mnZfu8ac1vyE6Mon_-6qCsdptRq-Q@mail.gmail.com> <2c566615-72ab-2fe0-e0b5-aefa570149bb@si6networks.com>
In-Reply-To: <2c566615-72ab-2fe0-e0b5-aefa570149bb@si6networks.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 15 Feb 2020 15:32:30 -0500
Message-ID: <CABNhwV2BGYJR6Z2oacNWHzbvNUHRnMqbdy3efHKamGFAs_-qvw@mail.gmail.com>
Subject: Re: 4941bis and multicast & QOS
To: Fernando Gont <fgont@si6networks.com>
Cc: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e08da5059ea33a5a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_n-zunRCH6wrisibCPKnQjPztjQ>
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 20:33:11 -0000

Thanks Fernando for that necessary clarification.

In the update is it possible to make the verbiage more clear in that regard.

5.  Significant Changes from RFC4941

   This section summarizes the changes in this document relative to RFC
   4941 that an implementer of RFC 4941 should be aware of.

   Broadly speaking, this document introduces the following changes:

   o  Addresses a number of flaws in the algorithm for generating
      temporary addresses (see [RAID2015] and [RFC7721]).

   o  Allows hosts to employ only temporary addresses (i.e.
      configuration of stable addresses is no longer implied or
      required).==================================================>
The way this is written would it cause OS vendors to drop the stable
address in their updated bis implementation

   o  Suggests that temporary addresses be enabled by default (in line
      with [RFC7258]).

   o  Addresses all errata submitted for [RFC4941].



On Sat, Feb 15, 2020 at 1:10 PM Fernando Gont <fgont@si6networks.com> wrote:

> 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
>
>
>
>
>

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com