Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Sat, 03 November 2012 02:09 UTC
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455A21F0C9D for <roll@ietfa.amsl.com>; Fri, 2 Nov 2012 19:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XELGpldEth4L for <roll@ietfa.amsl.com>; Fri, 2 Nov 2012 19:08:59 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6184F1F0C9C for <roll@ietf.org>; Fri, 2 Nov 2012 19:08:59 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qA328q6O016536; Sat, 3 Nov 2012 11:08:52 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id qA328q8g028182; Sat, 3 Nov 2012 11:08:52 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id MAA28181; Sat, 3 Nov 2012 11:08:52 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qA328qc6016707; Sat, 3 Nov 2012 11:08:52 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qA328q7Y010995; Sat, 3 Nov 2012 11:08:52 +0900 (JST)
Received: from [133.199.16.111] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCW00FXJ3AFYV20@mail.po.toshiba.co.jp>; Sat, 03 Nov 2012 11:08:52 +0900 (JST)
Date: Sat, 03 Nov 2012 11:08:43 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <5094014D.6070605@exegin.com>
To: Dario Tedeschi <dat@exegin.com>
Message-id: <50947CAB.2030809@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="windows-1252"; format="flowed"
Content-transfer-encoding: 8bit
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <B50D0F163D52B74DA572DD345D5044AF0F6EF7A3@xmb-rcd-x04.cisco.com> <50931AE9.9030800@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F22CD@xmb-rcd-x04.cisco.com> <5094014D.6070605@exegin.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
Cc: "roll@ietf.org WG" <roll@ietf.org>, "draft-ietf-roll-trickle-mcast@tools.ietf.org" <draft-ietf-roll-trickle-mcast@tools.ietf.org>, "mcr@sandelman.ca" <mcr@sandelman.ca>, "Jonathan Hui (johui)" <johui@cisco.com>
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2012 02:09:00 -0000
I don't see much benefit of dynamically allocating an MPL domain address and advertising it via a routing protocol, as each node can be pre-configured to a member of an MPL domain. Isn't it simpler if we can register a fixed MPL domain address with IANA (for each multicast scope that uses MPL)? Yoshihiro Ohba (2012/11/03 2:22), Dario Tedeschi wrote: > Ok, so an entire multicast address defines an MPL domain. Sending to a > multicast address, that does not match an MPL domain's address, > requires encapsulation. So if an MPL domain had been assigned an > address FF05::1234 and a device sends to FF05::1235 or FF04::1234, it > must encapsulate. > > This would work, but we've also added the need for devices in the > network to be told what addresses are MPL addresses (i.e. routing > information). In my example above, devices would have to be told that > FF05::1234 is an MPL domain adddress. If we take this approach, I > think we should also define how this information is disseminated. > > In one of my previous emails, I suggested adding a RIO to RPL DIO > advertisements. If we also allow prefix lengths less than 128, > multiple MPL addresses could be aggregated by one RIO. So instead of a > simple address match, a device would use longest-prefix match, just > like it would for unicast forwarding/sending. > > - Dario > > On 01/11/2012 6:13 PM, Jonathan Hui (johui) wrote: >> Hi Dario, >> >> Unicast-prefix-based multicast addresses also contain a scope >> identifier. So while the prefix does bound the scope, the scope of a >> prefix can contain multiple scopes. >> >> In any case, I don't think I properly articulated what I had in mind >> in my email below. It seems that we are converging on a definition >> where an MPL domain is defined by the IPv6 multicast address that >> interfaces subscribe to. In other words, an IPv6 multicast address >> identifies an MPL domain. All MPL multicast packets containing an >> MPL Option must have the IPv6 Destination Address set to the MPL >> domain that they are being transported in. If an MPL forwarder wants >> to forward a multicast packet within an MPL domain and that multicast >> packet does not have an IPv6 Destination Address corresponding to the >> domain's IPv6 multicast address, then the forwarder MUST encapsulate >> it. So now it becomes a simple address match rather whether an IPv6 >> address is within the scope zone. >> >> Does that solve the issue? >> >> -- >> Jonathan Hui >> >> On Nov 1, 2012, at 5:59 PM, Dario Tedeschi<dat@exegin.com> wrote: >> >>> I'm not so sure. What if, for example, I connected my BR to an >>> existing network that already had say scope 4 (admin-scope) >>> configured to cover a wider domain than just the PAN. I then could >>> not configure the BR to report 4 as the scope of the PAN (the "MPL >>> scope"). Yes, one could use scope 3, but it is currently reserved. >>> Besides, it wouldn't really solve the problem, if you consider that >>> scope 3 could quite easily also cover a wider domain than just the PAN. >>> >>> This is where unicast-prefix-based multicast addressing would become >>> useful. It would remove the need for an "MPL scope", since the MPL >>> domain would be defined by the PAN's prefix. >>> >>> - Dario >>> >>> >>> On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote: >>>> If the draft indicates that the MPL domain scope is a required >>>> configuration parameter, would that be sufficient? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> On Oct 31, 2012, at 7:37 AM, roll issue >>>> tracker<trac+roll@trac.tools.ietf.org> wrote: >>>> >>>>> #105: trickle-mcast: how to determine scope of MPL domain >>>>> >>>>> There's no explanation on how a node would determine what scope >>>>> corresponds >>>>> to a MPL domain. How would it do that without being given some >>>>> additional >>>>> information from the edge-router/s. I think what is needed, here, >>>>> is some >>>>> multicast routing information from the edge-router/s. >>>>> >>>>> -- >>>>> -----------------------------+--------------------------------------------- >>>>> >>>>> Reporter: mcr@… | Owner: >>>>> draft-ietf-roll-trickle-mcast@… >>>>> Type: defect | Status: new >>>>> Priority: major | Milestone: >>>>> Component: trickle-mcast | Version: >>>>> Severity: In WG Last Call | Keywords: >>>>> -----------------------------+--------------------------------------------- >>>>> >>>>> >>>>> Ticket URL:<http://trac.tools.ietf.org/wg/roll/trac/ticket/105> >>>>> roll<http://tools.ietf.org/wg/roll/> >>>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >
- [Roll] [roll] #105: trickle-mcast: how to determi… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Don Sturek
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Yoshihiro Ohba
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… peter van der Stok
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… peter van der Stok
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… peter van der Stok
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Don Sturek
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Don Sturek
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker