Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

"Jonathan Hui (johui)" <johui@cisco.com> Thu, 01 November 2012 03:54 UTC

Return-Path: <johui@cisco.com>
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 ADE8621F85E6 for <roll@ietfa.amsl.com>; Wed, 31 Oct 2012 20:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 n7KMBRPxMpQq for <roll@ietfa.amsl.com>; Wed, 31 Oct 2012 20:54:51 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3921F85BC for <roll@ietf.org>; Wed, 31 Oct 2012 20:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19139; q=dns/txt; s=iport; t=1351742091; x=1352951691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9H1Ae1w7HHiUpKf8TxEx5TT/Fa1MMicF5lUUIkHI65E=; b=QGCSWofNjRt+xvcCZc1JOLe5WdAe29RrgjLI0yUNtNxvlauV/DIxxRoS CdjwucercQZJ6SU/g98JxFrr1PgVyOfFaouYE07+cS26/e4FiWjYru3yV qIg7RYOH9IeXGz0E2Nu7NwjQCHKCRsVOxCado4lNNHZ6HAD7yOY3YIicO E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACLykVCtJV2Y/2dsb2JhbAA6CsNkgQiCHwEBBAEBAQ8BWwsQAgEIDhQdBycLFBECBA4FCBMHh1IDDwubCpZEBYlYBIt7EAWFRWEDiCWKIJIJgWuCb4FcCBce
X-IronPort-AV: E=Sophos; i="4.80,691,1344211200"; d="scan'208,217"; a="137595257"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2012 03:54:50 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA13sohL011476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 03:54:50 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 22:54:49 -0500
From: "Jonathan Hui (johui)" <johui@cisco.com>
To: Dario Tedeschi <dat@exegin.com>
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
Thread-Index: AQHNt+Sjjd3eM9iNy0mrVYgwyyr3Lg==
Date: Thu, 01 Nov 2012 03:54:48 +0000
Message-ID: <B50D0F163D52B74DA572DD345D5044AF0F6ECE93@xmb-rcd-x04.cisco.com>
References: <CCB50B52.1B637%d.sturek@att.net> <B50D0F163D52B74DA572DD345D5044AF0F6E519E@xmb-rcd-x04.cisco.com> <b4475c01a2da3a733b3fae9fccab42a7@xs4all.nl> <B50D0F163D52B74DA572DD345D5044AF0F6E9646@xmb-rcd-x04.cisco.com> <5091B2A3.1090205@exegin.com>
In-Reply-To: <5091B2A3.1090205@exegin.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.91.87]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--37.994300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B50D0F163D52B74DA572DD345D5044AF0F6ECE93xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "roll@ietf.org WG" <roll@ietf.org>
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
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: Thu, 01 Nov 2012 03:54:52 -0000

Hi Dario,

You've made good points on why restricting to link-local scope would be simpler overall.  Except for point 2, non-MPL aware routers will not simply forward encapsulated multicast datagrams as long as the MPL Option type has the highest order bits set to indicate that the processing node discard the packet if it does not recognize the option.

However, restricting to link-local scope does not solve Peter's use case of limiting the multicast dissemination to a subset of devices.  Having a non-link-local MPL scope is one method to solve his problem.  Granted, the devices within each MPL scope zone needs to be configured with an MPL multicast address that identifies the MPL multicast scope zone.  One way forward is to have the draft explicitly indicate that is a necessary configuration, and leave the actual configuration method out of scope.  Of course, there are many ways one could configure an interface (including manual configuration), so that is one argument for leaving it out of scope.

Another possible solution is to include an "MPL domain" identifier within the Hop-by-Hop Option itself rather than using the IPv6 Destination Address.  Still requires some way to configure devices with an MPL domain.

Yet another solution that was discussed is to include some kind of Hop Limit field in the Hop-by-Hop Option.  But that brought up complications with what happens with a devices first receives a messages with different Hop Limit values.

One final point, if we restrict MPL scope to link-local, then we could use a Destination Option instead of a Hop-by-Hop Option.  Alternatively, we could even encapsulate using UDP.

Thoughts (from Dario, Peter, and the rest of the WG)?

--
Jonathan Hui

On Oct 31, 2012, at 4:22 PM, Dario Tedeschi <dat@exegin.com<mailto:dat@exegin.com>> wrote:

Yes, I'd like to try clarify why link-local scope was suggested for the *outer* header. The reasons were:

  1.  Link-local scope is the only scope where the boundaries are well defined (i.e. on the link). Higher scopes are not well-defined and can cover wide domains depending on network configuration and administration.
  2.  With a higher scope, there is a chance that non-MPL aware routers may simply forward encapsulated multicast datagrams (MPL HbH option and all). We wouldn't want MPL datagrams to leak outside of an MPL domain.
  3.  A higher scope complicates the forwarding logic that needs to be implemented in an MPL router. The complication comes when a router receives an MPL datagram and needs to figure out whether to decapsulate or not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local scope would make the decision to decapsulate very obvious and simple.
  4.  In conjunction with 3. Link-local scope also makes it easier for an MPL router to determine if the inner multicast address is one that a higher layer (or an app) may be interested in.

Hopefully I haven't made things more confusing.

- Dario

On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote:

Hi Peter,

The current draft does not place any restrictions on the MPL multicast scope.

If the LLN border router is an MPL forwarder, it can forward MPL multicast packets between different MPL multicast scope zones.  To be explicit, if the original multicast packet's destination address has link-local scope, the MPL forwarder should not forward the packet again.  If the original multicast packet's destination has a scope larger than the MPL multicast scope, then the MPL forwarder needs to forward the packet to other MPL multicast scope zones (which may or may not involve different interfaces).

Does that address your question?

--
Jonathan Hui

On Oct 31, 2012, at 3:54 AM, peter van der Stok <stokcons@xs4all.nl><mailto:stokcons@xs4all.nl> wrote:



Hi Jonathan,

To be absolutely sure: the MPL multicast scope can be link-local, ULA or site-local? meaning the LLN border router can be a MPL forwarder?
In the latter case the LLN border router can forward link-local multicast from one interface to another?

Greetings,

peter

Jonathan Hui (johui) schreef op 2012-10-30 18:27:


Yes, a goal of the current draft is to support both cases (use of
IPv6-in-IPv6 encapsulation or not).

The intent is as follows:
1) If the source of the multicast packet is within the MPL forwarding
domain and the destination has a scope equal to or smaller than the
MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.
2) If the source of the multicast packet is outside the MPL
forwarding domain or the destination has scope greater than the MPL
multicast scope, then IPv6-in-IPv6 encapsulation is required.  When
using IPv6-in-IPv6 encapsulation, then the all MPL forwarders
multicast address with scope = MPL multicast scope is used as the
destination address in the outer header.

As mentioned in my other email, IPv6-in-IPv6 encapsulation is
required if you want to use the IPv6 Destination Address to identify
MPL forwarding scope zones.

Of course, this brings up Dario's practical point of how to configure
the MPL multicast scope if we allow that to dynamically change.  He
proposes a simplifying suggestion of requiring IPv6-in-IPv6
encapsulation for all non-link-local multicasts.  In other words,
setting the MPL multicast scope to link-local.

Thoughts?

--
Jonathan Hui

On Oct 30, 2012, at 4:46 AM, Don Sturek <d.sturek@att.net><mailto:d.sturek@att.net> wrote:



Hi Peter,

I still need to read the latest draft so take what I say here with that in
mind......

I was hoping that we could support not using IP in IP tunneling if the
scope of the multicast transmission was only within the multi-link subnet
managed by the border router.   I was hoping that only transmission
emanating from outside the multi-link subnet, received at the border
router, with scope that includes the devices in the multi-link subnet
would require IP in IP tunneling (and vice versa in terms of multicasts
generated in the multi-link subnet with scope outside).  I haven't yet
read the draft carefully to know if this is possible.

Don


On 10/30/12 1:34 AM, "peter van der Stok" <stokcons@xs4all.nl><mailto:stokcons@xs4all.nl> wrote:



Hi Don,

and more specifically under which conditions. That gives the
possibility to choose the conditions such that the encapsulation is not
needed.

Don Sturek schreef op 2012-10-29 16:56:


Hi Peter,

I think your suggested changes to the Trickle Multicast draft point
out
why IP in IP tunneling is needed.

Don



On 10/29/12 3:44 AM, "peter van der Stok" <stokcons@xs4all.nl><mailto:stokcons@xs4all.nl> wrote:



Dear WG,


Attached my suggestions for text modifications including some nits. I
used the facilities of word to edit and comment text with traces.

When writing text about MC scope and MC domain, I was puzzled by the
all MPL forwarders multicast address which removes the possibility to
address a given multicast group. We expect multiple (possibly
disjunct)
MC groups in our wireless networks.
Also I failed to understand why encapsulation was necessary once the
message was received by the seed.
To make it possible to configure the interface with one MC scope I
added the possibility to use Unicast-Prefix-based IPv6 Multicast
Addresses (RFC 3306).


Probably, I overlooked many aspects which make the suggestions
impractical, but I hope that the intention is clear.

Peter van der Stok

Michael Richardson schreef op 2012-10-25 23:30:


I suggest that you propose specific text to the list to modify the
document.


_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll



_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll