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

From: "roll issue tracker" <[email-masked]>
Date: Mon, 15 Dec 2014 23:19:07 -0000

#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

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-roll-admin-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  admin-local-policy       |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/167>
roll <http://tools.ietf.org/wg/roll/>

---

From: peter van der Stok <[email-masked]>
Date: Fri, 19 Dec 2014 16:12:23 +0100

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 B.

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