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

From: Robert Cragie <[email-masked]>
Date: Wed, 07 Jan 2015 12:00:26 +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.

Robert

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 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
>>
>> 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 <[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
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>