Re: [Roll] [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope

peter van der Stok <stokcons@xs4all.nl> Fri, 19 December 2014 15:12 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66D91A88D3 for <roll@ietfa.amsl.com>; Fri, 19 Dec 2014 07:12:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 Bby_lPTe_oDz for <roll@ietfa.amsl.com>; Fri, 19 Dec 2014 07:12:34 -0800 (PST)
Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B58A1A89A9 for <roll@ietf.org>; Fri, 19 Dec 2014 07:12:25 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id VTCP1p0064K0fSy01TCPF2; Fri, 19 Dec 2014 16:12:23 +0100
Received: from [2001:983:a264:1:fc06:6827:b427:cb66] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 19 Dec 2014 16:12:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 19 Dec 2014 16:12:23 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: roll@ietf.org
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org>
References: <067.22bdea82d68842ae5ee21d726a5c1591@trac.tools.ietf.org>
Message-ID: <208b67fefd88553f27c1ce6d7902e84d@xs4all.nl>
X-Sender: stokcons@xs4all.nl (SWIdeaQncSUwhf/zIsiW6vn4o3KPFUYz)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/y5Kx_pHVN5E29IS8YPPn01WEi-E
Subject: Re: [Roll] [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Dec 2014 15:12:37 -0000

Hi Joel,

Thanks for pointing this out.
After some thought, the best solution seems to embed the MPL admin local 
scope within the zone concept.
I propose the following addition:

MPL4 messages remain bounded within a zone. Consequently, MPL4 messages 
cannot be routed between interfaces belonging to different zones.
For example, consider a router with 5 interfaces where interfaces A and 
B beloing to zone 1 and interfaces C,D, and E belong to zone 2.
Mpl4 messages can be routed freely between interfaces A and B, and 
freely between C,D, and E. However, a MPL4 message MUST NOT be routed 
from Interface A to interface B.

When the concept of zone is unknown or disabled in a router, all 
interfaces belong to the same zone.

This means adding the zone concept to rules of section 4.2, and text to 
relate zone better to MPL4 zone.

Does this address your issue?

If yes, I will make a new draft along these lines beginning January 
2015.

Greetings,

Peter

roll issue tracker schreef op 2014-12-16 00:19:
> #167: Not match the requirement for administrative configuration of the 
> admin-
> local scope
> 
>  From: Joel M. Halpern <jmh@joelhalpern.com>
>  Date: 2014-12-16 0:59 GMT+02:00
> 
>  Major issues:
>      There seems to be a disconnect between the notion of 
> administratively
>  configured and the behavior described in this draft for admin-local
>  multicast scope.  As far as I can tell, the forwarding behavior 
> described
>  here has no mechanism for administratively configuring the 
> administrative
>  boundary.  The only knob that is used is PROACTIVE_FORWARDING, which 
> is
>  used for intra-realm multicast forwarding.  Thus, if you have a roll
>  multicast router with two interfaces in one realm and two interfaces 
> in
>  another realm, in order to provide realm multicast services for each
>  realm, this router according to this draft will always forward 
> admin-local
>  multicast messages between the two realms.  That does not seem to me 
> to
>  match the requirement for administrative configuration of the 
> admin-local
>  scope