Re: [Lsvr] LSOE and Switch behaviors

[Paul Congdon <[e-mail]>]

A couple of comments on addressing...

I believe in these networks, we won't be having very large L2 domains and
most links are point-to-point L3 links to build the Clos.  So, using a
multicast address that passes through a bridge should not have a big issue
with scaling.   If the L2 domain is large, then clearly passing through a
bridge might be an issue.

In 802.1Q, there are addresses defined that do NOT pass through bridges and
some that will pass through certain types of bridges (S-VLAN bridges,
Two-port MAC relay (TPMR) - something like a fiber to twisted pair
converters).  These different addresses are used by LLDP and security
protocols, for example, to achieve different 'reach' for the messages
across the L2 network.  These are documented in tables 8-1, 8-2, 8-3 of
802.1Q as follows:

Table 8-1 C-VLAN and MAC Bridge component Reserved addresses

Assignment                                                      Value
Bridge Group Address, Nearest Customer Bridge group address
 01-80-C2-00-00-00
IEEE MAC-specific Control Protocols group address
 01-80-C2-00-00-01
IEEE 802.3 Slow_Protocols_Multicast address
 01-80-C2-00-00-02
Nearest non-TPMR Bridge group address
 01-80-C2-00-00-03
IEEE MAC-specific Control Protocols group address
 01-80-C2-00-00-04
Reserved for future standardization
 01-80-C2-00-00-05
Reserved for future standardization
 01-80-C2-00-00-06
MEF Forum ELMI protocol group address
 01-80-C2-00-00-07
Provider Bridge Group Address
 01-80-C2-00-00-08
Reserved for future standardization
 01-80-C2-00-00-09
Reserved for future standardization
 01-80-C2-00-00-0A
EDE-SS PEP Address (IEEE Std 802.1AEcg)
 01-80-C2-00-00-0B
Reserved for future standardization
 01-80-C2-00-00-0C
Provider Bridge MVRP Address
01-80-C2-00-00-0D
Individual LAN Scope group address Nearest Bridge group address
01-80-C2-00-00-0E
Reserved for future standardization
 01-80-C2-00-00-0F

Table 8-2 S-VLAN component Reserved addresses

Assignment                                                      Value
IEEE MAC-specific Control Protocols group address
01-80-C2-00-00-01
IEEE 802.3 Slow_Protocols_Multicast address
01-80-C2-00-00-02
Nearest non-TPMR Bridge group address
01-80-C2-00-00-03
IEEE MAC-specific Control Protocols group address
01-80-C2-00-00-04
Reserved for future standardization
01-80-C2-00-00-05
Reserved for future standardization
01-80-C2-00-00-06
MEF Forum ELMI protocol group address
01-80-C2-00-00-07
Provider Bridge Group Address
01-80-C2-00-00-08
Reserved for future standardization
01-80-C2-00-00-09
Reserved for future standardization
01-80-C2-00-00-0A
Individual LAN Scope group address Nearest Bridge group address
01-80-C2-00-00-0E

Table 8-3—TPMR component Reserved addresses

Assignment                                                      Value
IEEE MAC-specific Control Protocols group address
01-80-C2-00-00-01
IEEE 802.3 Slow_Protocols_Multicast address
01-80-C2-00-00-02
IEEE MAC-specific Control Protocols group address
01-80-C2-00-00-04
Individual LAN Scope group address Nearest Bridge group address
01-80-C2-00-00-0E

You can see that in some devices, the reserved address is simply NOT
defined, thus it will pass through those types of devices.
I think in short, LSOE just needs to avoid 01-80-C2-00-00-0X addresses in
order to assure message pass through L2 switches.

In 802 Overview and Architecture - section 9.2, there is a definition of
using Ethertypes for prototype and vendor specific protocol development.
Perhaps early development of LSOE should consider this approach.  I suspect
you will ultimately want to allocate your own EtherType for LSOE, but you
could easily define the L2 header using the IETF vendor OUI as well.  Just
a though.  If you would like more details, let me know - otherwise the info
is available in Std 802-2014 which can be freely download.

Regards,
Paul






On Fri, Oct 5, 2018 at 6:15 AM Jacob Uecker <[e-mail]> wrote:

> Hi All,
>
> We had a discussion at the LSVR Interim meeting this week that the chairs
> asked to be sent to the list for full communication.
>
> During the LSOE requirements discussion, we discussed the behavior of
> other protocols and how they interact with switches (frames forwarded
> through switch or not). The request was that the switch behavior be
> deterministic with respect to LSOE frames and that we should state what
> that is. The recommendation was that LSOE frames be forwarded through the
> switch.
>
> Cheers,
>
> Jacob
>
>
> _______________________________________________
> Lsvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsvr
>