Re: [MBONED] feedback for draft-acg-mboned-deprecate-interdomain-asm
"James A. (Jim) Stevens" <james.a.stevens@rockwellcollins.com> Wed, 01 August 2018 00:06 UTC
Return-Path: <james.a.stevens@rockwellcollins.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 76F1B130EA5 for <mboned@ietfa.amsl.com>; Tue, 31 Jul 2018 17:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZWQXGYykp2dL for <mboned@ietfa.amsl.com>; Tue, 31 Jul 2018 17:06:47 -0700 (PDT)
Received: from ch3vs03.rockwellcollins.com (ch3vs03.rockwellcollins.com [205.175.226.47]) (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 865B5130EA8 for <mboned@ietf.org>; Tue, 31 Jul 2018 17:06:39 -0700 (PDT)
X-RC-All-From: , 205.175.226.20, No hostname, james.a.stevens@rockwellcollins.com, "James A. (Jim) Stevens" <james.a.stevens@rockwellcollins.com>, ,
X-RC-Attachments: , ,
X-RC-RemoteIP: 205.175.226.20
X-RC-RemoteHost: No hostname
X-RC-IP-Hostname: ch3ip03.rockwellcollins.com
X-RC-IP-MID: 7665801
X-RC-IP-Group: GOOGLE_RELAYED
X-RC-IP-Policy: $GOOGLE_RELAYED
X-RC-IP-SBRS: None
Received: from unknown (HELO mail-wr1-f69.google.com) ([205.175.226.20]) by ch3vs03.rockwellcollins.com with ESMTP/TLS/AES128-GCM-SHA256; 31 Jul 2018 19:06:37 -0500
Received: by mail-wr1-f69.google.com with SMTP id j6-v6so6379058wrr.15 for <mboned@ietf.org>; Tue, 31 Jul 2018 17:06:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9alhJtFa1IxzB1qL+KvHY3m6d8rFpnEojVfZCGZ8Cvc=; b=KKaGQy7BfjtWWMUjhnm3VD+0GAiTe+ReL1uVltbkGF1jneUCDaIjkTUaw18tFkVJGr 8pGWzW4Q9Cd46RLFZFn9Hlr9RASOoimeq3cQa4e4R3y/VpBzjfvbugaseUS76xZutWCG O84M+dnaHWA6Rx7FZNTihEfuLSChRfflb0Iwwevan9TjBpwRk2AykK+2xZFpAlkLk691 dWQwJcEItxGUUplT1qhs0S7UDhA23H7LaGgjFQjOhOQT0uCL08ArAY2Y6Ba+xt5MsRkP MiRwg1C/rrAOuxmzErdyhXid/dzlGCq8HdF+yp2ViI107tsZVC2zjGMWl7Qyj4ZuYlL0 4ndw==
X-Gm-Message-State: AOUpUlHkZZkSOi4To7zPEVBAe308ZlOousva3YQwkkG7FEdD8Tx72m+p pSodE+B4B80WfjPRczyyaVoMVOFodwH6lpZA1Ja5LX0uPASd9bHRwNXw2lcNziVS7QnRtrjywcv IUWPGRJ7gWl78ZR2bV3fgbD9ENkn1g/Ovmcwil2KygA==
X-Received: by 2002:a1c:a8d6:: with SMTP id r205-v6mr1094936wme.6.1533081996627; Tue, 31 Jul 2018 17:06:36 -0700 (PDT)
X-Google-Smtp-Source: AAOMgpdDJU805EO+wgh8C37eV58JkVsgzYMuJP5ddEBj4b8iYwhf26Ss0yJR5wneBp8sLjTJW4KIpix9WGStJ5hSk7U=
X-Received: by 2002:a1c:a8d6:: with SMTP id r205-v6mr1094928wme.6.1533081996324; Tue, 31 Jul 2018 17:06:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1c:9f42:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 17:06:35 -0700 (PDT)
In-Reply-To: <20180731222946.2svn45gqqhxlw7os@faui48f.informatik.uni-erlangen.de>
References: <mailman.1.1530990002.7416.mboned@ietf.org> <CAH8Jh6BmYFnor7h1DAS_0VvG3VHBHrVm=iFFe=_vAyj+0QvX9w@mail.gmail.com> <20180731222946.2svn45gqqhxlw7os@faui48f.informatik.uni-erlangen.de>
From: "James A. (Jim) Stevens" <james.a.stevens@rockwellcollins.com>
Date: Tue, 31 Jul 2018 19:06:35 -0500
Message-ID: <CAH8Jh6A0qi68uBfs=+wNxPJfUMLxvmUQ_QH15kc6amX=w1z_Sw@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: mboned@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cda6d005725477b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/wDa9_p0KfC78k5k2qodSqtglxM4>
Subject: Re: [MBONED] feedback for draft-acg-mboned-deprecate-interdomain-asm
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 01 Aug 2018 00:06:55 -0000
Toerless, thanks for your consideration of my suggestions. My response to your responses are inline below Cheers, Jim Stevens On Tue, Jul 31, 2018 at 5:29 PM, Toerless Eckert <tte@cs.fau.de> wrote: > Sorry for the delau > > Thanks a lot James for the input, > > before whipping up a rev with fixes, let me run what i think > would be appropriate fixes by you. > > On Sat, Jul 07, 2018 at 10:06:08PM -0500, James A. (Jim) Stevens wrote: > > In response to Leonard Giuliano's > > Fri, 6 Jul 2018 13:53:11 -0700 [MBONED] call for adoption of > > draft-acg-mboned-deprecate-interdomain-asm > > > > I still support the purpose of the draft ""Deprecating ASM for > Interdomain > > Multicast" , but recommend the following changes: > > > > 1. With respect to the following sentence in the last paragraph of > section > > 1: "Therefore, this document recommends making applications support SSM, > > even when they are initially meant to be just used intradomain." Please > > deleted the work "making" since SSM is not appropriate for some > intradomain > > many-to-many multicast applications and it would be inappropriate to make > > such an application use SSM.. > > Right. So, what i had in mind was the type of applications that already has > static or dynamic signalling of multicast groups to receivers and senders > that > can be well-known. In that case it would be often quite easy to add the > source address(es) of the senders to the signaling to the receivers. FOr > example, this has been done often in SDP in SIP or the like. > > Unfortunately, its hard to write this down well, so i was hoping that > a term like "if applicable and feasible to the application developer" > would be sufficient. And then i'd like to detail the idea above in a > separate > indepednent draft we suggested (when/how to write apps for SSM). We could > even add that as an upcoming draft and non-normative point to it from the > above text to at least put a stake in the ground that we need that. > > Any better text suggestions of course welcome. > I understand the difficulty; I think your suggested wording of "if applicable and feasible to the application developer" is sufficient. > > > Also, this is consistent with the last > > sentence of the previous paragraph "Indeed, there are application > contexts > > for which ASM is currently still widely considered well-suited within a > > single domain." > > Right. > > > 2. We use Bidrectional PIM (BIDIR-PIM) [RFC 5015], instead of PIM-SM for > > our many-to-many ASM multicast because it scales to hundreds or even > > thousands of sources and destinations coming and going > > Definitely. > > > in MANET networks without the significant overhead of PIM-SM. > > Hah! So how do you set up Bidir-PIM RP in MANET environments if i may ask > (we designed/brainstormed a lot of options, but i think three was never > an IETF recommendation). > > I need to check to see if I can provide our MANET Bidir-PIM RP setup details to the ietf mboned exploder list. > > Thus I think that the first > > sentence of Section 3.2, "A significant benefit of SSM is its reduced > > complexity through eliminating the network-based source discovery > required > > in ASM." is incorrect. I recommend that the sentence be edited to ".... > > required in ASM using PIM-SM." > > That is definitely true, and we should add the notion that this does > not apply to Bidir-PI because it does not have any signaling or state > chances > for source discovery. (WHich actually is not true if you look into bad > vendor implementations, but it is true for our IETF Bidir-PIM RFC. Hope > that's > enough). > I think that that adding the phrase "using PIM-SM" to the end of the sentence is sufficient. > > 3. Section 4.1 states that the recommendation to deprecate use of ASM for > > interdomain multicast ".... applies to the use of ASM between domains > > where either > > MSDP (IPv4) or Embedded-RP (IPv6) is used for sharing knowledge of remote > > sources (MSDP) or RPs (Embedded-RP)." Does this mean that the > > recommendation does not apply to the use of ASM between domains using > > BIDIR-PIM? > > I specifically didn't add Bidir-PIM because i thought it would not make > sense to argue this point without any more persons (beside me) knowing > and having opinions about Bidir-PIM. > > yes, unless you object, i would suggest to add Bidir-PIM to this > suggestion. > A lot of initial SP PIM-SM offering provided PIM-SM RPs to their IP > multicast > Internet and/or L3VPN customers. But its really a nightmare to > troubleshoot PIM-SM into another domain because you don't own the RP > but its in another domain. > > For Bidir-PIM the tree building troubleshooting is less an issue than the > third party dependency problems. Domain 1 and 2 want to share a > Bidir-Group, > but RP is in domain 3 and thats dead. And setting up interdomain > prioritycast-RP > policies... I just have not seen actual deployment cases operationally > happy with that approach so we could recommend it from IETF. > > There is IMHO actually a pretty good interdomain Bidir-PIM solution, > which happens to be just extending Bidir-PIM in multiple domains > via SSM across the Internet between the RPs, so if Interdomain Bidir-PIM > ASM > is of interest, thats what i would suggest to put into a protocol standard. > There's a patent on it though: > > https://patents.google.com/patent/US7936702 > > Currently, our users are within a single domain or single over-arching domain even when they have multiple subdomains, so has not been a problem for us. I don't have strong objections to adding Birdir-PIM to this list - especially if some solution could be added in future - or I'm okay with leaving the wording as is without Birdir-PIM > > 4. Section 4.3 states "There is a wide range of applications today that > > only support ASM (mostly for historic reasons), ..." Since there are > some > > many-to-many multicast applications that cannot efficiently run SSM (as > > discussed in Section 1), I recommend either (a) changing the test to "... > > (mostly for historic reasons but some for many-to-many scalability > reasons) > > ...." or else (b) delete the parenthetical comment. > > Ack. > > > 5. The second paragaph of section 4.3 states > "The recommendation to use > > SSM for interdomain multicast means that applications should use SSM, and > > operate correctly in an SSM environment, triggering IGMPv3/MLDv2 > messages > > to signal use of SSM." How about something like the following instead? > ' The > > recommendation to use SSM for interdomain multicast means that > applications > > should,* if possible*, use SSM, and operate correctly in an SSM > environment, > > triggering IGMPv3/MLDv2 messages to signal use of SSM. > > > *In addition > > applications that use ASM instead should use IGMPv3/MLDv2 triggering > > messages to signal use of ASM to ensure that a routers on a link do not > > have to fall back to IGMPv2 (or even IGMPv1) and thus become unable to > > support SSM.*' Note that the topic of raising standards track level of > > IGMPv3/MLDv2 looks like it is on the agenda for the upcoming MBONED > agenda > > in Montreal. > > Right. So this additional text you're suggesting is one that i very much > support, i just don't think it does not belong into this document - we're > already > stretching the documents payload by discussing intradomain SSM, but we can > argue > that i think well. > > So a sentence like you propose would get into an informational mboned doc > in conjunction with fixing up the standard track levels of IGMP/MLD > (IGMPv2//MLDv1 downgrade/obsolete), IGMPv3/MLDv2 upgrade or create revision > and upgrade (full standard). > > Given how fast IETF is this will take a while, so lets hopefully first > finish up > this hopefully simple recommendation re. interdomain to help SPs. > > I'm okay with leaving this topic of IGMPv3 versus IGMPv2 and ASM using IGMPv3 out of this document and discussing in a future document. > Cheers > Toerless >
- Re: [MBONED] feedback for draft-acg-mboned-deprec… Toerless Eckert
- Re: [MBONED] feedback for draft-acg-mboned-deprec… James A. (Jim) Stevens
- Re: [MBONED] MBONED Digest, Vol 138, Issue 3 James A. (Jim) Stevens