[Lsvr] New Liaison Statement, "Liaison response to IETF LSVR WG Work on LSoE (Link neighbor, liveness and encapsulation discovery)"

Liaison Statement Management Tool <statements@ietf.org> Thu, 28 March 2019 12:25 UTC

Return-Path: <statements@ietf.org>
X-Original-To: lsvr@ietf.org
Delivered-To: lsvr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 910EF120296; Thu, 28 Mar 2019 05:25:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool <statements@ietf.org>
To: 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>, Glen Parsons <glenn.parsons@ericsson.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, Alvaro Retana <aretana.ietf@gmail.com>, Paul Nikolich <p.nikolich@ieee.org>, Eric Gray <Eric.Gray@Ericsson.com>, Gunter Van de Velde <gunter.van_de_velde@nokia.com>, John Messenger <jmessenger@advaoptical.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155377592455.1588.3438827473565646607.idtracker@ietfa.amsl.com>
Date: Thu, 28 Mar 2019 05:25:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/X8Zn6cRwrq_y4vCWkHTYP3bcpl0>
X-Mailman-Approved-At: Thu, 28 Mar 2019 06:01:47 -0700
Subject: [Lsvr] New Liaison Statement, "Liaison response to IETF LSVR WG Work on LSoE (Link neighbor, liveness and encapsulation discovery)"
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 12:25:25 -0000

Title: Liaison response to IETF LSVR WG Work on LSoE (Link neighbor, liveness and encapsulation discovery)
Submission Date: 2019-03-28
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1637/

From: Glenn Parsons <glenn.parsons@ericsson.com>
To: 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 Contacts: Paul Nikolich <p.nikolich@ieee.org>,Glen Parsons <glenn.parsons@ericsson.com>,John Messenger <jmessenger@advaoptical.com>
Technical Contacts: 
Purpose: In response

Referenced liaison: IETF LSVR WG Work on LSoE (https://datatracker.ietf.org/liaison/1621/)

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
Attachments:

No document has been attached