Re: [Anima] ANIMA when there is a system-wide issue

[Michael Richardson <[e-mail]>]

EXECSUM: we need IEEE802.1X political clue.

The WG should adopt my l2-friendly-acp document as a problem statement
document, and then we should propose a solution which can be discussed
outside of the IETF.

Toerless Eckert <[e-mail]> wrote:
    >> Toerless Eckert <[e-mail]> wrote: > draft-ACP section 7. explains
    >> how to implement ACP on any low-end > L2-only as well as L2/L3 devices
    >> so that the device can operate ACP as > if it was just an L3 device,
    >> while in parallel operating unchanged on > some or all ports as an L2
    >> switch with STB: ACP packets are software > routed and software IPsec
    >> en/decrypted.

} Predictable scaling requirements for ACP neighbors can most easily
} achieved if in topologies such as these, ACP capable L2 switches
} can ensure that discovery messages terminate on them so that
} neighboring ACP routers and switches will only find the physically
} connected ACP L2 switches as their candidate ACP neighbors.

    >> So, your solution is to have L2 switches not forward based upon L3
    >> multicast addresses.

    tte> I can not parse this. Can you rephrase ?

You are asking L2 switches, which don't speak any L3 protocols in their
forwarding engine, to do filtering on L3 things, namely L3 destination
multicast addresses.

    >> While this is deterministically mapped to a unique L2 multicast MAC,

    tte> What is "this" ? Sorry.... can not parse again.

The L3 multicast address is mapped on ethernet to a deterministic L2
multicast address.  So, an L2 switch could filter on that, but unless it then
examines the L3 address, it could catch future L3 multicasts that happen to
map to the same L2 multicast.  When we allocated the ACP l3 multicast
destination, we did not make any attempt to make it a unique L2 target.
Assuming that there are no existing conflicts, to avoid the above, we would
need to allocate all the other L3 multicast targets that map to the same L2
multicast target.

    tte> In my past implementation experience, the punt option that always
    tee> works is one where you punt a specific ethertype.
    >> Great, so one of the options I proposed is to have a new ethertype for
    >> IPv6-DULL messages, as you also say below.

    tte> My point was that its not only about the discovery packets. We also
    tte> want to make sure that the ACP secure channel packets could also go
    tte> across blocked ports.

Yes, that's a different problem, but I agree it is related.

For the L2 SDN that does not use STP because it does not want blocked ports,
but rather wants to use all the bandwidth, the problem is keep the ACP DULL
multicast from causing loops.

    mcr> I think that the IEEE/IETF liason can get us an ethertype, given an
    mcr> appropriate STD track draft. Tell me if that you think this is within
    mcr> the ANIMA WG's charter.

    tte> Different encap to make ANI more resilient. Sounds to me like
    tte> perfectly in scope of BRSKI/ACP extensions charter point.

Good, we agree.

    tte> I just think we shouldn't rush this but think it through well:

    tte> First of all, relying on a separate MAC address for ACP is the most
    tte> eay way out.  But its not clear to me if thi works on every
    tte> hardware. On the other hand, i can see how i would always have a
    tte> separate MAC address for ACP if for example i have classic PC
    tte> hardware and implement ACP on the BMC (e.g.: as extension to
    tte> OpenBMC). But many switches/routers also have a MAC address pool
    tte> they can use.

Having the ACP on the (Open)BMC is definitely a killer use, and I hope to get there soon.
One might still want the ACP running even if the context of a BMC user who
shoots eirself in the foot.
The Linux kernel gives one the "macvlan" which is effectively a kind of
bridge (actually mutually exclusive with being in the a bridge).
The macvlan gets a kernel allocated randomized mac address, and can be moved
into a network namespace and effectively hidden, however, there does not seem
to be a way to keep the physical interface from being marked down.

    tte> When it comes to encapsulating across new ethertype, we need to make
    tte> it extensible, thats IEEE requirement for such a scarce resource. So
    tte> we might even want to ask around IETF for similar use-cases to have
    tte> candidate other values for a selector field for example.

    tte> Need to read through EAP over Ethernet to check what we could
    tte> share. I forgot all about it.  But ultimatly, its going to be a
    tte> small "selector-header" on top of the new ethertype that we need to
    tte> define.

You want chapter 11 of 802.1X-2020.
Table 11-3 lists the 9 EAPOL types used.
No equivalent to IANA Consideratons exist, so I think that it would require a
revision by the IEEE to allocate a code.  That would really be enough.

    tte> I can see at least two selectors: ACP-secure-channel and Discovery
    tte> (DULL-GRASP).

Both are IPv6 with LL src/dst, different protocols, so as long as we can
carry IPv6, then we can do both.

    tte> I have not thought about use-cases for e.g.: just BRSKI without ACP.

BRSKI can use the DULL GRASP channel to get access to a Join Proxy.
If used without ACP, then the certificate enrollment could well lead to use
of EAP to connect.  That's an important connection.

    tte> If you read up on the public slides i did eternities ago for my
    tte> prior employer about that vendors (somewhat proprietary) ACP
    tte> implementation in the context of service provide ethernet services,
    tte> where a customer L2-ethernet service is multiplexed across a service
    tte> provider L2VPN service, then those type of service-edge nodes have
    tte> all type of pain for discovery protocols such as CDP/LLDP, e.g.: for
    tte> their own instance and for the customer instance. So LLDP has
    tte> explicit provisions for this, and i have to find time to swap in the
    tte> context of that stuff again. Much easier if we had in-person IETFs
    tte> and someone in the know like Norm Finn could remind me ;-))

Yes, I recognize that.  There is a table 11-1 in the 802.1X document that
deals with this.  It seems broken that an end system has to know whether it's
in a some kind of L2-service to do it's announcements, etc.

    tte> As in: lets make sure that our selector field header could support
    tte> the same flexibility for those use-cases. At least to the extent
    tte> that we know for a rev0 spec how many "reserved/ignore" bits we need
    tte> and then fill them in later.

My reading is that they accomplish this via table 11-1, and if we were to
build upon EAPOL, that it would all come for free.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide