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

["Adrian Farrel" <[e-mail]>]

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:[e-mail]]
> Sent: 23 December 2014 16:19
> To: [e-mail]; [e-mail]
> 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 <[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