[Anima] VLANs and draft-ietf-anima-autonomic-control-plane-08.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 August 2017 06:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 26CC9131C4F for <anima@ietfa.amsl.com>; Tue, 1 Aug 2017 23:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id B4SrKZPT-KNh for <anima@ietfa.amsl.com>; Tue, 1 Aug 2017 23:57:44 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8A3124C27 for <anima@ietf.org>; Tue, 1 Aug 2017 23:57:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 98CBD2009E for <anima@ietf.org>; Wed, 2 Aug 2017 02:59:34 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16E408076D for <anima@ietf.org>; Wed, 2 Aug 2017 02:57:44 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
In-Reply-To: <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com>
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 02 Aug 2017 02:57:44 -0400
Message-ID: <31582.1501657064@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/_G_grj7_QwJzjsQpkNHb-l4smLg>
Subject: [Anima] VLANs and draft-ietf-anima-autonomic-control-plane-08.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 06:57:46 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    > Although I think it would be simpler to do this:

>           48        2   1     13                    63             1
> +----------------+----+---+---------+-----------------------------+---+
> | ULA prefix     |Type| Z | Zone-ID |         Device-ID           | V |
> |                | 00 |   |         | Registrar-ID | Device-Number|   |
> +----------------+----+---+---------+--------------+--------------+---+
>                                             48           15

I like this much better.

    > A general remark: when a wider audience looks at this, there will
    > be complaints that we are re-creating classful addressing. I suggest
    > adding some text about this. (Along the lines of: it's true, and
    > here is why it doesn't matter.)

Agreed. But they are assignment classes, not routing classes.

    > Clarify that ACP (and GRASP) capable devices do
    > not need to depend on MLD snooping, since they
    > catch LL multicasts directly per port. But non-ACP
    > switches MUST either support MLDv2 snooping or
    > operate as pure L2 bridges for all multicast
    > packets.

    > Also, is there anything to say here about VLANs?

There are some chicken and egg problems here.

On the one hand (other hand in next email), there may be a variety of L2
technologies ("LAN EXTENSION") which may be provided by other providers which
the ACP should "bridge" across as if it was just a wire.   A configuration
which is not-uncommon (but seemed to surprise more than multiple sales
engineers from more than three major companies) is for an (incumbent) telco
to offer a service that connects one location (the datacenter, DC) to many
locations.  The central location has a VLAN tag that leads to each other
locations, and at that other location (customer premises, CP), the VLAN tag
does not appear.

Now, hook things up and do not tell the devices at either end about this
scenario ("remote hands" have just unpacked the drop-shipped equipment).

This is a *PRIME* use for autonomic networking.  (I actually tried to do this
all with DHCP/TFTP for unconfigured devices, btw, with some success, but then
the manufacturer of the high-quality $300 CPE device screwed up their
platform OS making it a low-quality $300 device)

On the CP side it's all good, because the freshly unpacked equipment would
see the GRASP M_FLOODs (whether proxy announcements for an unimprinted
device, or AN_ACP announcements for an imprinted device) without a VLAN tag.

But, the DC device has a problem.  All it knows about is a fiber of 1GbE or 10GbE
Ethernet here.  Any untagged packets it sent will be dropped.

If the CP device would send some kind of traffic, then the DC device would
see it, with the VLAN tag, and could autonomically configure a VLAN interface
for it, and begin to talk to it.   That would be great.

If the CP device is imprinted, the AN_ACPs would just go out, and it would be
all well.  But, in the bootstrapping case, we've said that the pledge should
remain quiet...  so maybe we want to revise that?  On the other hand, the
pledge actually won't be completely quiet.  It will send out DADs for any LL
addresses it might have configured.
(Today, we wrote that Pledges should configure fresh RFC4941 temporary
addresses for use in enrollment.  And that they should try new addresses
whenever all of their prospects fail, in case some of the problems are
related in some way to their choices of address)

So, perhaps we should write is that, on an unconfigured interface, if one
sees VLAN encapsulated traffic on an interface on which, and one *would* send
out the AN_ACP/AN_Proxy messages, that one should start sending some M_FLOODs
for awhile on that VLAN interface.

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-