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

From: peter van der Stok <[email-masked]>
Date: Tue, 23 Dec 2014 09:52:31 +0100

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 <[email-masked]>
>>>  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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Dec 2014 11:19:17 -0500

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:
>> 2) You need to describe the policy you want to implement as the
>> default policy.
>>
>>> After some thought, the best solution seems to embed the MPL admin local
>>> MPL4 messages remain bounded within a zone. Consequently, MPL4 messages
>>> For example, consider a router with 5 interfaces where interfaces A and
>>> This means adding the zone concept to rules of section 4.2, and text to
>>>>  boundary.  The only knob that is used is PROACTIVE_FORWARDING,
>>>> which is
>>>>  multicast router with two interfaces in one realm and two
>>>> interfaces in
>>>>  multicast messages between the two realms.  That does not seem to
>>>> me to

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Dec 2014 09:08:03 -0000

To reduce this to the most trivial (and put it in IPv4 terms)...
Is the configuration of 127.0.0.1 "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 [mailto:[email-masked]]
> Sent: 23 December 2014 16:19
> To: [email-masked]; [email-masked]
> Cc: Adrian Farrel
> Subject: Re: Fwd: Re: [roll] #167 (admin-local-policy): Not match the
requirement
> for administrative configuration of the admin-local scope
>