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

[peter van der Stok <[e-mail]>]

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