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

Robert Cragie <> Wed, 07 January 2015 12:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3DED1A6FD5 for <>; Wed, 7 Jan 2015 04:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lKMMKRStuXnq for <>; Wed, 7 Jan 2015 04:00:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2015E1A0071 for <>; Wed, 7 Jan 2015 04:00:41 -0800 (PST)
Received: from mailscanlb0.hi.local ([] by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from <>) id 1Y8pHx-0004U0-VM; Wed, 07 Jan 2015 12:00:37 +0000
Received: from mailscanlb0.hi.local ([] by with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <>) id 1Y8pHv-0000SB-Tl; Wed, 07 Jan 2015 12:00:37 +0000
Received: from ([] helo=[]) by with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Y8pHt-0007GN-AX; Wed, 07 Jan 2015 12:00:33 +0000
Message-ID: <>
Date: Wed, 07 Jan 2015 12:00:26 +0000
From: Robert Cragie <>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To:, Routing Over Low power and Lossy networks <>, "'Joel M. Halpern'" <>,
References: <> <> <> <> <013101d0227d$c9f04ed0$5dd0ec70$>
In-Reply-To: <013101d0227d$c9f04ed0$5dd0ec70$>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080804040200040909000902"
X-Extend-Src: mailout
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: Wed, 07 Jan 2015 12:00:51 -0000

I agree with Adrian's assessment. "Administratively configured" is 
loosely defined and it is not a black and white case. With regard to the 
draft, the configuration (i.e. presence/absence) of MPL interfaces in 
the node implies the scope and thus can be considered "administratively 
configured" in that it is not automatically derived but implies by a 
manual configuration. I agree it does need some clarifying text though.


On 28/12/2014 09:08, Adrian Farrel wrote:
> To reduce this to the most trivial (and put it in IPv4 terms)...
> Is the configuration of "administratively configured" as the loopback
> address?
> Clearly no human intervention is needed to make it happen, yet there is no
> "process" that is run.
> I think the 4291 quote is not very helpful since it defines "administratively
> configured" as "not automatically derived." In particular, an NMS might be
> unsupervised and include software that issues addresses as if it were a human
> making configuration choices. That is clearly "automatic" yet still qualifies as
> "administratively configured" in my mind.
> This document is trying to use a different definition of "administratively
> configured" as Peter has stated. I don't believe this has to be derived from
> 4291, but perhaps it should be clearly stated in this document as he has
> offered.
> Peter/authors: you have some minor edits to do, and perhaps you can work up a
> clear definition and include it early in the document with a statement like "In
> this document, the term administratively configured is used to mean..."
> Cheers,
> Adrian
>> -----Original Message-----
>> From: Joel M. Halpern []
>> Sent: 23 December 2014 16:19
>> To:;
>> Cc: Adrian Farrel
>> Subject: Re: Fwd: Re: [roll] #167 (admin-local-policy): Not match the
> requirement
>> for administrative configuration of the admin-local scope
>> 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.
>> Yours,
>> Joel
>> 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
> _______________________________________________
> Roll mailing list