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

peter van der Stok <> Tue, 23 December 2014 08:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 18FFC1ACDA6 for <>; Tue, 23 Dec 2014 00:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J2gwEyAzspx8 for <>; Tue, 23 Dec 2014 00:52:40 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36D661ACDA8 for <>; Tue, 23 Dec 2014 00:52:39 -0800 (PST)
Received: from ([]) by with ESMTP id WwsX1p00R4VN29601wsXRD; Tue, 23 Dec 2014 09:52:34 +0100
Received: from [2001:983:a264:1:c11c:e2db:8463:91a9] by with HTTP (HTTP/1.1 POST); Tue, 23 Dec 2014 09:52:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Dec 2014 09:52:31 +0100
From: peter van der Stok <>
To: "Joel M. Halpern" <>,
Organization: vanderstok consultancy
In-Reply-To: <>
References: <> <>
Message-ID: <>
X-Sender: (JsxvhfXzGNBa6CmeHXCVt182bbYfbVcO)
User-Agent: XS4ALL Webmail
Subject: Re: [Roll] Fwd: Re: [roll] #167 (admin-local-policy): Not match the requirement for administrative configuration of the admin-local scope
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To:, Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Dec 2014 08:52:43 -0000

Hi Joel,

There has been a lot of discussion on the roll mailing list of what 
administratively configured means.
A message on the roll mailing list from Michael Richardson summarizes a 
meeting we had on the subject, and probably cuts to the core of your 
argument as well.

In particular:
The origin of the second mis-understanding was that the text in
multicast-scopes (and rfc 4291) says:

          Admin-Local scope is the smallest scope that must be
          administratively configured, i.e., not automatically derived

The understanding of "administratively configured" for many people
implies truck rolls, or ssh logins or router CLI commands.  It was
only when this assumption was clearly articulated that the origin of the
conflict became clear to all parties.

The new understanding is that "administratively configured" is not
limited to the things that a human did it, but rather includes any
processes or operations that a human (including an IETF document) might
cause.   The intent of multicast-scopes is not to limit ways that
scopes 4+ can be determined, but to clarify that scopes <=3 are *not*
intended to be defined by a physical (or physical-like) topologies.

Does this indeed address your issue?
And, do you want me to site the explanation of administratively 
configured in the draft?
accompanied by text that the proposed policy is a default policy.



Joel M. Halpern schreef op 2014-12-22 16:05:
> There are two issues intertwined here.
> First, the spec you point to says that the behavior shall be
> administratively configured.  So we need to recognize the conflict
> between that assertion and the effort to define an automated policy.
> What I had thought on my previous reading was that you were resolving
> the conflict by having a small number of knobs which guided an
> automated behavior.
> If I am reading your comments properly, what you are doing is defining
> a default policy, without any administrative configuration.  If so,
> you need to do two things:
> 1) You need to identify that you are violating the underlying RFC in
> order to simplify operations.  At that point, it would be up to the
> community to decide if that is acceptable.  I would expect such a
> decision to be clearly identified in the last call.
> 2) You need to describe the policy you want to implement as the default 
> policy.
> With regard to item 2, the policy in the document or the policy you
> propose here are both defensible.  The question would be what policy
> the working group wants to enforce.
> Yours,
> Joel
> On 12/22/14 2:21 AM, peter van der Stok wrote:
>> 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 D.
>> 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 <>
>>>  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