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

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail]>
>>>>  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