Skip to main content

Liaison statement
Liaison response to IETF LSVR WG Work on LSoE (Link neighbor, liveness and encapsulation discovery)

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2019-03-28
From Group IEEE-802-1
From Contact Glenn Parsons
To Group lsvr
To Contacts Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Victor Kuarsingh <victor@jvknet.com>
Cc Deborah Brungard <db3546@att.com>
Victor Kuarsingh <victor@jvknet.com>
Link State Vector Routing Discussion List <lsvr@ietf.org>
Martin Vigoureux <martin.vigoureux@nokia.com>
Alvaro Retana <aretana.ietf@gmail.com>
Eric Gray <Eric.Gray@Ericsson.com>
Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Response Contact Paul Nikolich <p.nikolich@ieee.org>
Glen Parsons <glenn.parsons@ericsson.com>
John Messenger <jmessenger@advaoptical.com>
Purpose In response
Attachments (None)
Liaisons referred by this one IETF LSVR WG Work on LSoE
Body
Thank you for your liaison regarding IETF LSVR WG Work on LSoE (Link neighbor,
liveness and encapsulation discovery). The IEEE 802.1 WG is aware of the LSoE
(Link State over Ethernet) contribution and the call for working group adoption
within the LSVR (Link State Vector Routing) working group.

As stated in your liaison, the LSoE protocol intends to provide link discovery,
an exchange of supported encapsulations (IPv4, IPv6, ...), discovery of
encapsulation addresses (Layer 3 / MPLS identifiers) over raw Ethernet, and
layer 2 liveness checking. The LSoE protocol itself does not maintain link
state, but rather supports the LSVR protocol with the discovery, information
exchange and liveness checking. We believe the name of this protocol miss
represents its purpose and creates confusion with the existing IEEE 802.1 Layer
2 link state protocol known as SPB (Shortest Path Bridging) and fully specified
in Clauses 27 and 28 of IEEE Std 802.1Q-2018.

IEEE 802 also has standardized a widely deployed layer 2 discovery protocol
known LLDP (Link Layer Discover Protocol) as specified in IEEE Std
802.1AB-2016. We believe that it would be undesirable for the industry to have
multiple discovery protocols and any new protocol developed should have
backward compatibility with the widely deployed IEEE Std 802.1AB-2016. We
understand that the current LLDP protocol does not meet the requirements to
support the LSVR protocol. Individual contributions proposing enhancements to
the existing LLDP protocol are currently under consideration by the IEEE 802.1
WG. These proposals intend to meet the needs of LSVR. One such proposal is
available at
http://www.ieee802.org/1/files/public/docs2019/new-congdon-lldpv2-consideration-0119-v01.pdf.
An analysis of the LSVR requirements against this proposal was presented at the
IEEE 802.1 Interim in January, 2019 and is available at
http://www.ieee802.org/1/files/public/docs2019/new-congdon-lsvr-disco-requirements-for-LLDPv2-0119-v01.pdf.
There is currently no active project within IEEE 802.1 to enhance LLDP to meet
the needs of LSVR, however, existing solutions for layer 2 liveness include
Connectivity Fault Management (CFM) specified in Clauses 18-22 of IEEE Std
802.1Q-2018. Your contribution to IEEE 802.1 and collaboration on these
proposals are welcomed.

We look forward to continued collaboration through individual contributions and
the IEEE 802 – IETF Coordination Group. We welcome ongoing communication with
LSVR through the IEEE 802.1 email reflector, scheduled conference calls
(http://www.ieee802.org/1/tsn/tsn-task-group-agenda/#Upcoming_conference_calls),
or face-to-face meetings (http://www.ieee802.org/1/meetings).

Respectfully submitted,
John Messenger
Acting Chair, Vice-Chair, IEEE 802.1 WG