IETF Logo Mail Archive

Re: [MBONED] call for MBONED agenda items in Montreal

Toerless Eckert <tte@cs.fau.de> Mon, 02 July 2018 22:19 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 0640E131228 for <mboned@ietfa.amsl.com>; Mon, 2 Jul 2018 15:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 oOnCOwCiQQs6 for <mboned@ietfa.amsl.com>; Mon, 2 Jul 2018 15:19:35 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7ACA13134C for <mboned@ietf.org>; Mon, 2 Jul 2018 15:19:34 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9F35058C4AE; Tue, 3 Jul 2018 00:19:30 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8FBC44401A4; Tue, 3 Jul 2018 00:19:30 +0200 (CEST)
Date: Tue, 03 Jul 2018 00:19:30 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Leonard Giuliano <lenny@juniper.net>
Cc: MBONED WG <mboned@ietf.org>
Message-ID: <20180702221930.x2svc7a7wmlitkj2@faui48f.informatik.uni-erlangen.de>
References: <alpine.DEB.2.02.1806262346460.16447@svl-jtac-lnx02.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1806262346460.16447@svl-jtac-lnx02.juniper.net>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/2QoDMAX83BP0Z829aq2vApuQuSA>
Subject: Re: [MBONED] call for MBONED agenda items in Montreal
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 22:19:37 -0000

WOuld like to ask for a "new new draft currently" to discuss                                                       
interest and process to evolve standards status of IGMP/MLD                                                        

10 min slot ?! "Standards evolution for IGMP and MLD".

The following was sent to PIM as the goals, given how PIM happens
after MBoned at 101 it would be great if we could have in MBoned just
a discussion slot about the operational requirements/issues
(i've identified some below, but may miss others). Later in PIM
we can then determine if any PIM work can capture all the operational
implications, and if not we'll do the rest in MBoned.

Thanks
    Toerless
                                                                                                                   
   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.                                                           

On Tue, Jun 26, 2018 at 11:51:55PM -0700, Leonard Giuliano wrote:
> 
> We are currently scheduled for MBONED for 1:30PM on Tues.  Since we ran out
> of time in our last joint meeting with PIM, we will not be meeting jointly
> this time, however, we will be going back-to-back with PIM following right
> after MBONED in the same room.
> 
> Anyway, if you have something you'd like to present, please let the chairs
> know what the draft name is and how much time you would like.
> 
> 
> -Lenny and Greg
> 
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
tte@cs.fau.de

v2.23.0 | Report a Bug | By Email