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

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

Return-Path: <jmh@joelhalpern.com>
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 C8C951A9106 for <roll@ietfa.amsl.com>; Tue, 23 Dec 2014 08:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxtq_T826ALG for <roll@ietfa.amsl.com>; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43B91A1A00 for <roll@ietf.org>; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 907161BC1A7F; Tue, 23 Dec 2014 08:19:21 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-121.clppva.east.verizon.net [70.106.135.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 738391BC1A65; Tue, 23 Dec 2014 08:19:20 -0800 (PST)
Message-ID: <54999605.1010402@joelhalpern.com>
Date: Tue, 23 Dec 2014 11:19:17 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
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
To: consultancy@vanderstok.org, roll@ietf.org
References: <2cae0814be28bb83918ebd2d89d86182@xs4all.nl> <5498334B.5010205@joelhalpern.com> <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl>
In-Reply-To: <0fab60ad65358f6d52d58a2ac9ba3cc5@xs4all.nl>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2CCNYmbJJzXhggyhzUI-UTHWIaw
Subject: Re: [Roll] Fwd: Re: [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: 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: 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.

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:
> http://www.ietf.org/mail-archive/web/roll/current/msg08335.html
>
> 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 <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