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

"Joel M. Halpern" <> Tue, 23 December 2014 16:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8C951A9106 for <>; Tue, 23 Dec 2014 08:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nxtq_T826ALG for <>; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C43B91A1A00 for <>; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 907161BC1A7F; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 738391BC1A65; Tue, 23 Dec 2014 08:19:20 -0800 (PST)
Message-ID: <>
Date: Tue, 23 Dec 2014 11:19:17 -0500
From: "Joel M. Halpern" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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 16:19:24 -0000

Looking at that quote, I can not see how a behavior that the device 
exhibits without any human intervention can possibly be 
"administratively configured, i.e., not automatically derived" since 
what you are defining is an automatic derivation process.

I Suppose if you had a knob with two settings, one of which was 
"admin-local <== realm" and one of which was "admin-local <== this 
procedure" you would meet the minimum requirement of the text you quote. 
  That at least would have a human cause something.  In the document as 
written, I do not see a human agent.


On 12/23/14 3:52 AM, peter van der Stok wrote:
> 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.
> See:
> In particular:
> <quote>
> 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.
> </quote>
> 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.
> Greetings,
> Peter
> 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