[Roll-bier-dt] TRANSPORT vs TUNNEL mode

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 07 September 2018 07:59 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll-bier-dt@ietfa.amsl.com
Delivered-To: roll-bier-dt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E3BE3130DC4 for <roll-bier-dt@ietfa.amsl.com>; Fri, 7 Sep 2018 00:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LJ8tY1ESUiRn for <roll-bier-dt@ietfa.amsl.com>; Fri, 7 Sep 2018 00:59:26 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7089612426A for <roll-bier-dt@ietf.org>; Fri, 7 Sep 2018 00:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21299; q=dns/txt; s=iport; t=1536307166; x=1537516766; h=from:to:subject:date:message-id:mime-version; bh=mzsNbRFx0vZ1cd1yZc91Awbi0VsbMVJ8uzon8cGdcmo=; b=AXy+FcW58SLvi2qO8krx+wdY6MBQysflNSYrzhPDhVFyi9bSBuPA5BHF sBPSQtqO5xjklOzIC1iXdFohDc48uw3c+ME1o66a0XhnnIeDQI6erSScX d66v/fo64CyMP1AmfipGmvlp5HtW/rakK8F7ZNzdDZiowS2Wg9or7dlQk Y=;
X-Files: image001.jpg, image002.gif : 2607, 87
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.53,341,1531785600"; d="gif'147?jpg'147,145?scan'147,145,208,217,147,145";a="448952773"
Received: from alln-core-4.cisco.com ([]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2018 07:59:25 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com []) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w877xOjD010031 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll-bier-dt@ietf.org>; Fri, 7 Sep 2018 07:59:24 GMT
Received: from xch-rcd-001.cisco.com ( by XCH-ALN-002.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 7 Sep 2018 02:59:24 -0500
Received: from xch-rcd-001.cisco.com ([]) by XCH-RCD-001.cisco.com ([]) with mapi id 15.00.1367.000; Fri, 7 Sep 2018 02:59:24 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "roll-bier-dt@ietf.org" <roll-bier-dt@ietf.org>
Thread-Topic: TRANSPORT vs TUNNEL mode
Thread-Index: AdRGfW+sV1Hu92fiTP+49oqoyylXow==
Date: Fri, 7 Sep 2018 07:59:21 +0000
Deferred-Delivery: Fri, 7 Sep 2018 07:59:12 +0000
Message-ID: <6d9a400582d44773891e52fbe6888444@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/related; boundary="_005_6d9a400582d44773891e52fbe6888444XCHRCD001ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Outbound-SMTP-Client:, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll-bier-dt/m-1Mq0sFhenRD_f96AU4jjWJhN0>
Subject: [Roll-bier-dt] TRANSPORT vs TUNNEL mode
X-BeenThere: roll-bier-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "ROLL WG Design Team for bitstring addressing. See https://trac.ietf.org/trac/roll/wiki/roll-bier-dt" <roll-bier-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll-bier-dt>, <mailto:roll-bier-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll-bier-dt/>
List-Post: <mailto:roll-bier-dt@ietf.org>
List-Help: <mailto:roll-bier-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll-bier-dt>, <mailto:roll-bier-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2018 07:59:29 -0000

Dear all

At the last call we made that important distinction, tunnel vs transport, that creates a new dimension to our matrix, which was so far (BIER, BIER-TE) * (Bitwise BIER, Bloom).

-          Transport would be when the bitmap indicates one or more final destination. In that case, there is no IP address in the packet. The RPL-BIER termination needs to rebuild individual packets from the bits, and forward the packets individually in a 6LoWPAN form or in an incompressed form. One way of presenting it is that BIER becomes a new more of 6LoWPAN stateful compression. Transport mode enables to distribute a copy of a packet to one or more distinct destination 6LNs attached to one or more 6LRs.

-          Tunnel could be when the bits indicate the terminating RPL-BIER routers. Those routers decapsulate the BIER and forward the inner packet. This model can be seen as an overlay to a RPL-BIER network, whereby only the en/decapsulators can forward the inner packets, but the RPL infra is not aware of those addresses. One way of presenting this is that BIER becomes a way to compress the amount of routing state in the RPL fabric. Tunnel mode allows to distribute one unicast packet to one 6LR or one multicast packet to one or more 6LRs.

We discussed how this maps to MLD/IGMP. My view is that a different draft should enable the 6LR (== RPL-BIER termination router, or RPL leaf) to proxy MLD to the 6LBR (== root). When  a 6LN node registers to the 6LR using MLD, the 6LR relays that to the 6LBR, and the 6LBR adds the bit of the 6LR in the bitmap for that multicast address. When a packet is intended for the mcast group, the route encapsulates the packet to the collection of 6LRs that got MLD registrations in tunnel mode, which decapsulate and do normal multicast distribution on the last hop.

Note that in transport mode,  each copy is a distinct packet with a different destination address. The result is that the UDP checksum is different and has to be regenerated by the endpoints (6LoWPAN allows for that since the checksum can be compressed under some conditions of equivalent protection in the framing). This means that false positives can not be filtered out by the UDP checksum. This means that unless the application is protected against misdistribution (eg app level session / security), false positive are not acceptable. IOW, transport mode is compatible with bitwise BIER but not with Bloom.

Do I make sense?



Pascal Thubert
Principal Engineer
Chief Technology & Architecture Office

Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco Systems
Building D (Regus)
45 Allee des Ormes - BP1200
06254 MOUGINS cedex

[Description: Think before you print.]Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.