Re: [6tsch] architecture with remote BBR

Pascal Thubert <pascal.thubert@gmail.com> Tue, 18 June 2013 17:08 UTC

Return-Path: <pascal.thubert@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155AD11E80F1 for <6tsch@ietfa.amsl.com>; Tue, 18 Jun 2013 10:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxZoBQkVvo9M for <6tsch@ietfa.amsl.com>; Tue, 18 Jun 2013 10:08:31 -0700 (PDT)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0B921F9B64 for <6tsch@ietf.org>; Tue, 18 Jun 2013 10:08:30 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id y6so3763428lbh.23 for <6tsch@ietf.org>; Tue, 18 Jun 2013 10:08:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KGbqwnFEymRDPXRSSd4FsO440FAAlSYfSQJ8np03Wo4=; b=ZOUC4BRJwlpo28POKtxoTOGqhVvV14qOsuyzVHjkJSHTWHogshyl9QoAcsiVUd/0VI zkwbqI+kjYPGpkruyco7QFxSQTnVORtnBgCedvcmljjvdmKEaDchYf5acg0U68LQmACI SFmDCc7NFjsytu64Sq7Tt2KqciLgenG+XO4brQYZQCzsVq04yXGCPCkSz3bbX3/WZhkj A+WR4SQk1JvPXWg5jtwauZzmOAXi967m7jcMijN6ZA2Jyw6eL/GEKJYAISk9EfBKdpl9 dgHgRsqZGqzZD6trqTpwsymA0rhCjH8HXYlt5p9r6as6l+dwD7R/TW1scjg9uTuoOEjF 931g==
MIME-Version: 1.0
X-Received: by 10.112.154.170 with SMTP id vp10mr1524428lbb.11.1371575309923; Tue, 18 Jun 2013 10:08:29 -0700 (PDT)
Received: by 10.112.34.47 with HTTP; Tue, 18 Jun 2013 10:08:29 -0700 (PDT)
In-Reply-To: <CADJ9OA9+YOitYz+=___Bg_nBqyn2NfWcWiALORJ4aLXPoUU-pw@mail.gmail.com>
References: <CADJ9OA9+YOitYz+=___Bg_nBqyn2NfWcWiALORJ4aLXPoUU-pw@mail.gmail.com>
Date: Tue, 18 Jun 2013 19:08:29 +0200
Message-ID: <CADPqcJJfiO0Va7mvHAFTEH5yRWiCD3LYf5Ajh-fXcugNgzbgYQ@mail.gmail.com>
From: Pascal Thubert <pascal.thubert@gmail.com>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary="089e01161a44217a3a04df70c3e0"
Cc: 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] architecture with remote BBR
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 17:08:36 -0000

Hello Thomas:

And then we need to add the case of the backhaul that looks like your case
1 but has applications on the other side of the VPN as opposed to another
wlan.
This is actually being studied at ISA100.15 ...

For your option 1, is it often (/ sometimes?) mandatory that the 2 LLNs
share a same L2 domain ( / IPv6 subnet) ? When they do not, we are back in
classical routing, with VPN iff crossing an untrusted area ( ; eg the IT
network from an OT perspective ; )
The case of a single subnet crossing layer 3 boundaries is very classical
in datacenters. We use overlays to solve the issue; e.g. cisco OTV, but
also LISP, L2TP, and pseudowires in general.
We should probably describe the case in the architecture and explain how
this can be achieved with the above technologies; and that probably 6TSCH
does not need to add anything new. Or does it?
About option 2, I see the links to the PCE as either a single vlan or a mix
of vlan and vpn, depending on which domain must be crossed. The structure
has its benefits, but we probably need to come up with the same model and
multiple disjoint paths via multiple PCEs for high availability and load
balancing.

what do you think?

Pascal


2013/6/17 Thomas Watteyne <watteyne@eecs.berkeley.edu>

> All,
>
> There is a case I believe we are not covering explicitly in the
> architecture.
>
> The architecture draft now considers the following topology:
>
>                ---+------------------------
>                   |      External Network
>                   |
>                +-----+                  +-----+
>                |     | Router           |     | PCE
>                |     |                  |     |
>                +-----+                  +-----+
>                   |                        |
>                   |     Subnet Backbone    |
>             +--------------------+------------------+
>             |                    |                  |
>          +-----+             +-----+             +-----+
>          |     | Backbone    |     | Backbone    |     | Backbone
>     o    |     | router      |     | router      |     | router
>          +-----+             +-----+             +-----+
>     o                  o                   o                 o   o
>         o    o   o         o   o  o   o         o  o   o    o
>    o             o        o  LLN      o      o         o      o
>       o   o    o      o      o o     o  o   o    o    o     o
>
>
>
> The backbone needs to be one broadcast domain for the ND proxy operations
> defines in draft-thubert-6lowpan-backbone-router-03 to work.
>
> Now, let's consider a campus-wide deployment, where the requirements is
> that (1) all the nodes use the same IPv6 prefix, and (2) all are managed by
> the same PCE. Since BBRs are "far apart", they will not all live on the
> same (broadcast) backbone.
>
> This is a very realistic scenario that I have come across multiple times,
> and which I believe 6TSCH group could/should address.
>
> I can see the following options:
>
> *Option 1*: "under-the-hood" tunneling
>
> When installing the network, network administrators interconnect the
> different pieces of the BB using some VLAN solution, essentially recreating
> a broadcast domain.
>
> pros:
> - This option does not require any change the ND operation.
> cons:
> - IMO, in most multi-BBR deployments, the remote BBR case is the rule
> rather than the exception. Using tunnels looks more like a "patch" which
> might be seen as overly complex if it needs to be applied all the time.
>
>
>                ---+------------------------
>                   |      External Network
>                   |
>                +-----+                  +-----+
>                |     | Router           |     | PCE
>                |     |                  |     |
>                +-----+                  +-----+
>                   |                        |
>                   |     Subnet Backbone    |    *==========*
>             +--------------------+--------------  *TUNNEL*  ----+
>             |                    |              *==========*    |
>          +-----+             +-----+                       +-----+ (*remote*)
>          |     | Backbone    |     | Backbone              |     | *Backbone*
>     o    |     | router      |     | router                |     | *router*
>          +-----+             +-----+                       +-----+
>     o                  o                   o                 o   o
>         o    o   o         o   o  o   o                  o  o   o    o
>    o             o        o  LLN      o      o             o      o
>       o   o    o      o      o o     o  o   o             o    o     o
>
>
> *
> *
> *Option 2*: PCE responsible for forwarding to correct BBR
>
> Each BBR establishes an explicit (and secure) connection to the PCE. Since
> the PCE is aware of the nodes connected through each BBR, it can forward
> some inbound packet to the appropriate BBR.
>
> The functionality of the PCE and Router can be merged. The PCE/Router gets
> a packet for a particular node, and forwards it to the appropriate BBR over
> the explicit connection to that BBR.
>
>
>                 --------------+-------------------
>                               |  External Network
>                               |
>                            +-----+
>                            |     | PCE/Router
>                            |     |
>                            +-----+
>                             ^ ^ ^
>
>                             | | |
>
>             +---------------+ | +----------------+
>             |                 |                  |
>             v                 v                  v
>
>          +-----+           +-----+            +-----+
>          |     | Backbone  |     | Backbone   |     | Backbone
>     o    |     | router    |     | router     |     | router
>          +-----+           +-----+            +-----+
>     o                  o                   o                 o   o
>         o    o   o         o   o  o   o         o  o   o    o
>    o             o        o  LLN      o      o         o      o
>       o   o    o      o      o o     o  o   o    o    o     o
>
>
>
> *Option 3*: hybrid
>
>
> This is the same as option 2, but the router and the PCE as separate. The PCE acts as the ND proxy for all the nodes attached to all the BBRs it is managing. The router is a regular router.
>
>
>   ---+-----------------------
>
>      |   External Network
>      |
>   +-----+                  +-----+
>   |     | Router           |     | PCE
>   |     |               +--|     |
>   +-----+               |  +-----+
>
> | | ^ ^ ^
>
>      |                  |   | | |
>
>   ------------------------  | | |
>                             | | |
>
>                             | | |
>
>             +---------------+ | +----------------+
>             |                 |                  |
>             v                 v                  v
>
>          +-----+           +-----+            +-----+
>          |     | Backbone  |     | Backbone   |     | Backbone
>     o    |     | router    |     | router     |     | router
>          +-----+           +-----+            +-----+
>     o                  o                   o                 o   o
>         o    o   o         o   o  o   o         o  o   o    o
>    o             o        o  LLN      o      o         o      o
>       o   o    o      o      o o     o  o   o    o    o     o
>
>
>
>
> Thoughts?
>
>
> Thomas
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>


-- 
Pascal