Re: [pim] agenda requests for Montreal
"Mankamana Mishra (mankamis)" <mankamis@cisco.com> Wed, 04 July 2018 12:56 UTC
Return-Path: <mankamis@cisco.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BA127332 for <pim@ietfa.amsl.com>; Wed, 4 Jul 2018 05:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 YQr1wsQochBh for <pim@ietfa.amsl.com>; Wed, 4 Jul 2018 05:56:22 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D33130E6E for <pim@ietf.org>; Wed, 4 Jul 2018 05:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19449; q=dns/txt; s=iport; t=1530708982; x=1531918582; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yR5NfzAtKwXVGjNuAZsjKcYRz098g+VkHG3Z16D//iM=; b=HCCAruHpju/7STdDsTQk37Ukfp0QGnmnYHa21vGeE3sSL7/dozyDkH8G bb5Ks58krq1PJv5ik8dz8srJvMm/UcIe63v3UuB/QB2QE7YYY6jlHo5aL aGOL1fgHGDo9/5gTq+HcwDJDcCFxPisXNnlQHMcabHcgTncLUcZ347iW7 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DpAADewjxb/5JdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYMfKmJ/KAqLdIw2ggeQH4UOFIFmCxgBCoRJAoIkITQYAQIBAQIBAQJtHAyFNwIBAwEBFlYLEAIBCC0SBycLFBECBA4FG4MFAYEbZA+qUIRbg3mBNQWIbYFWP4EPJ4FqfoMYAQGBGwkvQwmCc4IkAodFNYlth2UJAo0CghyBQIQMiAuRYgIREwGBJB04gVJwFTsqAYI+giQXegEJA4dShT5vAY8bgSyBGgEB
X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="scan'208,217";a="138795169"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 12:56:20 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w64CuKmD025992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2018 12:56:20 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Jul 2018 07:56:20 -0500
Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1320.000; Wed, 4 Jul 2018 07:56:20 -0500
From: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
To: Hitoshi Asaeda <asaeda@ieee.org>
CC: Stig Venaas <stig@venaas.com>, "pim@ietf.org" <pim@ietf.org>
Thread-Topic: [pim] agenda requests for Montreal
Thread-Index: AQHUEk9CMpRDnkEXRlCeFshPBNXshKR9VZmAgAC0oYCAAQ9gAIAAQmaA
Date: Wed, 04 Jul 2018 12:56:20 +0000
Message-ID: <C122B51A-4AAB-481E-8E1E-001A2ECBEEC1@cisco.com>
References: <20180702215432.5uqebchak5xvtuk4@faui48f.informatik.uni-erlangen.de> <1ED3D035-AD1E-4A18-83D8-DA48145BE4E8@ieee.org> <CAHANBt+twd9b-8XuhTXT9-7N1odZP0DnjiKVqrF28bSOzvoD+g@mail.gmail.com> <3EB74432-F398-40BE-945B-698386C8ED49@ieee.org>
In-Reply-To: <3EB74432-F398-40BE-945B-698386C8ED49@ieee.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.99.164]
Content-Type: multipart/alternative; boundary="_000_C122B51A4AAB481E8E1E001A2ECBEEC1ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/23Ww7RyOuzO5ft5L2ojiYoxUx6Q>
Subject: Re: [pim] agenda requests for Montreal
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 12:56:25 -0000
Hi Hitoshi , On Jul 4, 2018, at 1:58 AM, Hitoshi Asaeda <asaeda@ieee.org<mailto:asaeda@ieee.org>> wrote: Hi Stig, a) misunderstanding how IGMPv3/MLDv2 are fully backward compatible with IGMPv2 / MLDv1 functionality and also fully support ASM. IGMPv3/MLDv2 fully support ASM with an EXCLUDE (*,G) mode operation, no? This may not be the intended discussion, but the EXCLUDE mode operation is the concern. In IGMPv3/MLDv2, once a member subscribes a multicast channel with EXCLUDE mode, the upstream router's filter-mode for the group will be set to EXCLUDE, which requires switching to the shared tree. This means an EXCLUDE mode operation easily stops the SSM communication. Of course, EXCLUDE (*,G) join whose multicast addresses are within the SSM address range should be discarded by applications/kernels/routers. However, it is an operational solution. If applications use other multicast address range such as GLOP or something, the problem can appear again. (I don't remember what happens if a user invokes EXCLUDE (S,G) join whose multicast address is within the SSM address range..) It would be sufficient to configure the correct SSM range on the routers I believe (and potentially switches). You cannot configure overlapped address range, e.g., SSM range within administrative boundary. Conceptually (E)GLOP does not need to coexist with SSM, but it can't. It seems reasonable to ignore exclude (S,G) in the SSM range, but I haven't thought much about it and 4607 is not very clear. IGMPv3/MLDv2 specifications do not have text related to this. I guess we could discuss if they should. I agree. Moreover, the EXCLUDE mode operation is almost meaningless as practical applications do not use EXCLUDE mode to block sources very often; a user or application usually wants to specify desired source addresses, not undesired source addresses. Nevertheless, kernel implementations to support EXCLUDE filter-mode as well as INCLUDE filter-mode are complex enough. I don't know what direction this discussion will lead to, but if it aims to revisit IGMP/MLD protocol standardization, I support to get rid of EXCLUDE mode operations for the regular multicast *applications* (except for control messages invoking (*,G) such as ND and other discovery protocols on a LAN). RFC5790 (Lightweight-IGMPv3/MLDv2) would be a good start. b) Raising standards track level of IGMPv3/MLDv2/IGMP-MLD-lite I don't think this IGMP-MLD-lite means RFC5790, but is it almost same or very similar to LW-IGMPv3/LW-MLDv2? There are at least a few people using exclude filter mode, but it is certainly uncommon. I'm wondering what the WG thinks of supporting it when progressing them. Oh, I didn't know that exclude filter-mode is used in some situations. According to the current specifications, if exclude filter-mode must be supported in inter-domain multicast services, ASM must be also supported in inter-domains. We would at least require multiple interoperable implementations, which I think we have. As part of progressing them we would probably do a survey. The current backward compatibility is also a problem. For example, whenever an IGMPv2 General Query is received on an interface, the Host Compatibility Mode of that interface is set to IGMPv2 and its IGMPv2 Querier Present timer is set to Older Version Querier Present Timeout seconds. The router acts as IGMPv2 router for that interface until its timer expires. It's easy to stop SSM. But Do we not need to account the fact that network might really have IGMPv2 Querier present, and we need to act on it. So would it not be network admin to make sure Querier are configured with correct version if there is need to operate in SSM mode ? I'm hoping for a good discussion here on the list. This is also a great topic for our WG meeting. It would probably be good in mboned to discuss operational aspects like configuring the appropriate SSM range and the need for exclude filter mode support. Agreed. Regards, Hitoshi Stig Regards, Hitoshi On 2018/07/03, at 6:54, Toerless Eckert <tte@cs.fau.de<mailto:tte@cs.fau.de>> wrote: WOuld like to ask for a "new new draft currently" to discuss interest and process to evolve standards status of IGMP/MLD a) downgrade IGMPv1/IGMPv2/MLDv1 to something worse than IGMPv3/MLDv2/IGMP-MLD-lite - goal is to do everything we can do to discourage utilization of old protocols in new products. b) Raising standards track level of IGMPv3/MLDv2/IGMP-MLD-lite c) documenting/mitigating ? Risk in deployments upgrading. I for once have really no clue on what the process for a), b) is and what our options are, so i hope we'll have a friendly AD or more senior IETF pprocess aware folks who could help figuring ou the best option quickly. Wrt to c): After raising a) on the list i talkd to a customer who was worried about a) happening because of i think a range of issues: a) misunderstanding how IGMPv3/MLDv2 are fully backward compatible with IGMPv2 / MLDv1 functionality and also fully support ASM. b) In any text we may produce about downgrading older IGMP/MLD< it needs to be very clear that this implies NO change to the status of ASM (and the separate work we are doing to change the status of ASM will only downgrade interdomain ASM). c) In the specific deplyment, intradomain ASM is used wih Bidir-PIM, and to the best of my knowledge, the interaction between Bidir-PIM and IGMPv3/MLDv2 is not well specified, but IMHO its also not really well specified for PIM-SM. Let me know. 10 mins or so ? Cheers Toerless (*): If you prefer me to have slides highlighting In-Reply-To: <8CCB28152EA2E14A96BBEDC15823481A1CBEC069@sjceml521-mbs.china.huawei.com<mailto:8CCB28152EA2E14A96BBEDC15823481A1CBEC069@sjceml521-mbs.china.huawei.com>> On Fri, Jun 29, 2018 at 11:13:48PM +0000, Michael McBride wrote: If you haven't yet requested time to present in Montreal please do so. We are meeting back to back, same room, with mboned but not sharing the same timeslot since we were way to rushed last time. Grab a cookie then come to pim. Here are the time slots: TUESDAY, July 17, 2018 1330-1530 Afternoon Session I Notre Dame OPS mboned MBONE Deployment WG 1530-1550 Beverage and Snack Break - Convention Floor Foyer 1550-1820 Afternoon Session II Notre Dame RTG pim Protocols for IP Multicast WG We will send an agenda out in another week. Thanks, mike _______________________________________________ pim mailing list pim@ietf.org<mailto:pim@ietf.org> https://www.ietf.org/mailman/listinfo/pim -- --- tte@cs.fau.de<mailto:tte@cs.fau.de> _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org<mailto:pim@ietf.org> https://www.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org<mailto:pim@ietf.org> https://www.ietf.org/mailman/listinfo/pim
- Re: [pim] agenda requests for Montreal Greg Mirsky
- Re: [pim] agenda requests for Montreal Raunak Banthia (rbanthia)
- Re: [pim] agenda requests for Montreal Mankamana Mishra (mankamis)
- [pim] agenda requests for Montreal Michael McBride
- Re: [pim] agenda requests for Montreal Stig Venaas
- Re: [pim] agenda requests for Montreal Stig Venaas
- Re: [pim] agenda requests for Montreal Toerless Eckert
- Re: [pim] agenda requests for Montreal Toerless Eckert
- Re: [pim] agenda requests for Montreal Stig Venaas
- Re: [pim] agenda requests for Montreal Toerless Eckert
- Re: [pim] agenda requests for Montreal Hitoshi Asaeda
- Re: [pim] agenda requests for Montreal Stig Venaas
- Re: [pim] agenda requests for Montreal Hongji Zhao
- Re: [pim] agenda requests for Montreal Hitoshi Asaeda
- Re: [pim] agenda requests for Montreal Mankamana Mishra (mankamis)
- Re: [pim] agenda requests for Montreal Hitoshi Asaeda
- Re: [pim] agenda requests for Montreal Stig Venaas