RE: [EFM] EFM-OAM frame fomat
Hi Roy, matt, and folks.
[Matt Squire]
> Slow protocols cannot be VLAN tagged. The tagging mechanism resides
> above the MAC, and slow protocols are below.
[Roy Bynum]
> This limitation means that vendors that provide equipment to "Ethernet"
> vendors using VLAN Tags to segregate customer traffic or $subsriptions
> services will not be able to use OAM frames to manage those services. end
> to end. I am not even sure that the end customers will be able to
> "manage" their network links using OAM fames over these types
> of facilities either.
While what Roy points out is true, I'm sure that proprietary solutions
will appear in short time after the standard is finished to solve this
particular problem. Most probably it will rely on some form of tunneling
to achieve the same end effect; alternatively, it will rely on a
upper-layer protocol (for example, SNMP) being used to coordinate the
relay of OAM-related info at a higher layer, circumventing in fact the
limitation mentioned above. Of course any such system will not be as
responsible as a direct implementation - it may be quite slow in fact -
and it will also be much more complex to manage, but it is the way things
are going to be due to the limitations imposed.
Of course, all limitations themselves are pretty reasonable - the ones in
the OAM implementation included - but that's what happen when Ethernet is
pushed well beyond its original environment and into the carrier's world.
It's still Ethernet and you can't just change that.
BTW, I always held the opinion that VLAN tags should evolve to become more
like Frame Relay DLCIs. It should be possible to actively switch traffic
using VLAN tags, pretty much as it is done with DLCI numbers - including
the possibility to renumber VLAN tags as it crosses through an Ethernet
service switch (example: "VLAN 1 from port 1 will be switched as VLAN 2 at
port 3"). Please note that, as far as I know, this is well beyond the
current VLAN implementations available (including the ones that already do
some form of stacking and tunneling). But I'm digressing. Back to the EFM
track...
P.S. I'm still here and listening. I'm not currently involved with any
professional activity regarding Ethernet or EFM, but I'm still a firm
believer of this initiative. It's good to know that you guys made such
great progress over the last year. Congrats to everyone involved.
Carlos Ribeiro
cribeiro@mail.inet.com.br