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

Michael Richardson <> Wed, 02 August 2017 07:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EC19131D24 for <>; Wed, 2 Aug 2017 00:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PJINgI1zYGnA for <>; Wed, 2 Aug 2017 00:18:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 679F9131D19 for <>; Wed, 2 Aug 2017 00:18:32 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 035F92009E for <>; Wed, 2 Aug 2017 03:20:22 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 660028076D for <>; Wed, 2 Aug 2017 03:18:31 -0400 (EDT)
From: Michael Richardson <>
In-Reply-To: <>
References: <> <> <>
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
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 02 Aug 2017 03:18:31 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [Anima] VLANs and draft-ietf-anima-autonomic-control-plane-08.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Aug 2017 07:18:34 -0000

Michael Richardson <> wrote:
    > 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

Now, let's look at the question from the point of view of the the LAN
EXTENSION provider.  Of course they are also using autonomic switches, and
they'd like to be able to plug stuff together randomly and have their ACPs
formed so that they can maintain service.

The LAN EXTENSION provider also may have a drop-ship device to the customer
premises (which, using the previous example, is both the "DC" and the "CP"
ends, because both ends are their customer, being the L3-ISP that bought the
L2 transport).   The LAN EXTENSION customer doesn't always know if the fiber
will plug directly into the customer's equipment, or if some kind of media
converter from copper to fiber will be used.  The straight media converters
are remarkably unreliable because they attempt by fail to pass MII across and
fail, and you have to lock ports to HD, etc.  Meanwhile multiport switches
with SFP ports are common, and sometimes one winds up serving multiple
customers from the same demark...

So that means that the tagged side of the circuit, which is at the DC,
probably has AN_ACP messages coming out *untagged* from the L2-provider.
The L3-ISP's device is going to see them, but of course the ACP connection
ought to fail. (baring some kind of out of band arrangement, which is out of
scope here)

At the previously mentioned "CP" side of things, despite the media converters
*trying* to be stupid optical to electrical converts, it turns out that they
often have a management VLAN on the optical side, and if an AN_ACP packet
were to arrive with that preconfigured VLAN ID, it would be accepted.  The
customer's traffic actually might also arrive in another VLAN tag, and that
media-converter device would be charged with removing the tag.  Or, everyone
might agree that the extra device is stupid, and plug things directly into
the real CPE.

Once the LAN EXTENSION provider has their ACP up to the demark devices, the
sensible thing for them to do is to disable ACP messages on their "access"
ports.  Sensible, but maybe not reliable... I think that a device that loses
all ACP connectivity *SHOULD* disable that disabling, and starting sending
some AN_ACP messages on all ports....

I should say that I assumed a flat ethernet on the fiber side of things, but
it could also be a wide variety of metro-ethernet-ring technologies... PBB,
TRILL, and six or so other 802.FOO things.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-