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

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-