IETF Logo Mail Archive

Re: [MBONED] Genart last call review of draft-ietf-mboned-deprecate-interdomain-asm-05

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Sun, 29 December 2019 20:23 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC60120091; Sun, 29 Dec 2019 12:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=boeing.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 D9vXPUqNkagK; Sun, 29 Dec 2019 12:23:13 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1ED512007A; Sun, 29 Dec 2019 12:23:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id xBTKNBfQ031452; Sun, 29 Dec 2019 15:23:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1577650992; bh=n1luP7HRBmaeQNkcHz/HGz6rk5jF6i5+evG5vvCHS2A=; h=From:To:Subject:Date:References:In-Reply-To:From; b=GE0eec7x0GLApoE2kQiew8oD4DzQL5vJx1yjA722pPAKZcXo2R7Z8C5z4Vj+s8YK7 kFlMT8JFpI6zhsd1ZOfnQkwupmYcOaVC0+2losjGkiPZQhuxmcMv9MvUcmechHwAug m5l0pMMjE0fdzO9kyV8dw5hRasQRuU1zf2M2LsRnLTNzQpzfg+09/6vm7d/M2QTlIh uKWQxBX3JLvQm6T4JJHXNv7D8m06iun/ucU9cwveYfRg6+gHIKtGkl4uBGbUOR60UC PKFZ4yaVqanI+zTMDs8NV3LELCa6XQbG3PdiXk2elX3b2Y0aksZw1Yp08R/dvqyAfD 9tnI6nSQecWYQ==
Received: from XCH16-01-11.nos.boeing.com (xch16-01-11.nos.boeing.com [144.115.66.39]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id xBTKN7JS031007 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 29 Dec 2019 15:23:08 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-11.nos.boeing.com (144.115.66.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1779.2; Sun, 29 Dec 2019 12:23:06 -0800
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1779.002; Sun, 29 Dec 2019 12:23:06 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: "James A. (Jim) Stevens" <james.a.stevens=40collins.com@dmarc.ietf.org>, "mboned@ietf.org" <mboned@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-mboned-deprecate-interdomain-asm.all@ietf.org" <draft-ietf-mboned-deprecate-interdomain-asm.all@ietf.org>
Thread-Topic: [MBONED] Genart last call review of draft-ietf-mboned-deprecate-interdomain-asm-05
Thread-Index: AQHVvUEhg6+dhni5s0+39U79hrUNmqfRjVGw
Date: Sun, 29 Dec 2019 20:23:06 +0000
Message-ID: <1880af9b76e44208aa50459ba4a3cc30@boeing.com>
References: <CAH8Jh6CTyfHz050+WCb=S6cfp=UfUQ9Z0sMAcYZnJWZSoGthzQ@mail.gmail.com>
In-Reply-To: <CAH8Jh6CTyfHz050+WCb=S6cfp=UfUQ9Z0sMAcYZnJWZSoGthzQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 83628DCCF9845EFE9E0DAD56D8EEBC87D7B218322D0F637FC0A448353B54A26D2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/3m3W3pTNIGCxzgym9q1Kr3FkKok>
Subject: Re: [MBONED] Genart last call review of draft-ietf-mboned-deprecate-interdomain-asm-05
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Dec 2019 20:23:16 -0000

From: MBONED <mboned-bounces@ietf.org> On Behalf Of James A. (Jim) Stevens

> Some background to Tim Chown's comment about "pushback in earlier discussions"
> Section 4.4 is on Developing application guidance: SSM, ASM, service discovery
> Section 4.5 is on Preferring SSM applications intradomain
>
> We have intradomain applications with up to hundreds of nodes doing many to many multicast IP packet exchanges where the nodes can dynamically come and go.  (Although most networks only contain 20 to 100 nodes, I believe the largest such network had >250 nodes doing many to many multicast.
>
> SSM is not feasible (and neither is ASM with PIM-SM due to the high overhead and dynamics as nodes come and go).  So our applications use ASM with BIDIR-PIM.  
>
> We want to ensure that operating system and router developers continue to support ASM and BIDIR-PIM over the long term for our intradomain applications. I.e., we do NOT want to deprecate intradomain use of ASM.
>
> Thus, we pushed back against the recommendation in 4.4 to develop new applications using SSM and in 4.5 to prefer SSM for future intradomain applications.  In response, the draft-ietf-mboned-deprecate-interdomain-asm document was updated to put in the phrase "if feasible" in sections 4.4. and 4.5 so that SSM is not recommended if not feasible.
>
> Note that we do not object to deprecating interdomain use of ASM.

I would like to emphatically post a +1 here. On all points, except perhaps the use of PIM (for security reasons primarily).

As long as we're talking interdomain, no objections. But intradomain, the fact that the source of a given multicast might vary, without mandating that each destination join all possible source-specific multicasts individually, is a "feature" that we exploit.

The model is much the same as telephone conference calls. You send out the conference call number to all possible participants, but then you want to avoid the extra complication of requiring each one dialing in having to dial the number of each participant. That would be quite laborious and unnecessary.

Bert

v2.23.0 | Report a Bug | By Email