Re: [Lsvr] WG Adoption call for draft-ymbk-lsvr-lsoe-03 (to end 17 December 2018)

Paul Congdon <> Fri, 14 December 2018 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C12A128D0C for <>; Fri, 14 Dec 2018 06:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3fPcBUb-qBMu for <>; Fri, 14 Dec 2018 06:55:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59102128A6E for <>; Fri, 14 Dec 2018 06:55:26 -0800 (PST)
Received: by with SMTP id j21so4729767oii.8 for <>; Fri, 14 Dec 2018 06:55:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BTrBI+c+b9qtu5+VmYtI9iso7oiZ8QobB4coxrQBiwM=; b=PHC8pIiqg2rqvhohSBIfIlT/h3KB60L8L8GSUvjMkyGzH9NmTWT2cYGzMXKs+LbYpc 7bAhjSIPQ7BBjcgNZ00IXqvh7soAwQYN2FMkydxxMVop8J6xINqANPzSrMm0WvgUxlbo zL5Sz/UHw69DS92RMpp9cYlEm9vwEu0OLu60FKLkdPnLI6jfHz5HccAXgX5BTonXPEuD NpvFiGb2zp36oqzZSe6967DFsgqhY3pNsqPr9z5l47PPiP5shqWf9CPYfms5iMu4KQL+ 2D1bphhpLRhW3QN0EehcUrOaliZ1GewJ4RfA/MIkL1ueFRJKLnRnG/wZM+woNmxsZIN6 NcAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BTrBI+c+b9qtu5+VmYtI9iso7oiZ8QobB4coxrQBiwM=; b=BrZ8TtDeyR9fkP3mF+GRYxUh6GoTxjXWnI+FhAbtAFFY6nQH67I6qjUPlRcdIjiQ4n Ix300NO8NCCC/IwnEMmlRpZlJvOdCmZ/DaQla+fhmuwn2cDUXl3iB7oqHJYi8R0zoS5H iiLLm9opM050znLNQqasvbMGe3zS+xNfRqAbNb59vUxMnPwSsOzVqjFVMM1gEmjakqmu 0+k/eazmoOEwVtqPrTnUg8BF5mIBkewyWGeOfxFw9HWw5ARObqa2WKJ+qtgde2Q1bxJN xQnVSvHxbGVIWrhPsEcUxkTVUB2g/WVshHk0wRrF2NUbGsJAHy/lwe64aM6SUfAJt/ZX PNDg==
X-Gm-Message-State: AA+aEWZjK69zYm9aQT2sLUZAiSPSqIinCYzoPfcuPyt77L3Has9S6lL5 bg7rAnZkXReaQxt8e5/KSAL6HHyZEad9wgI+KEPpr4N6
X-Google-Smtp-Source: AFSGD/VI9s3ZR8CJoqM/q+65CgGf8VaY8KoeA/CW11sxI5EqCEDyAFHwNESqBO0rlSoBmAr2Io5/GQu7gxruAgwhzlU=
X-Received: by 2002:aca:2c05:: with SMTP id s5mr2034491ois.190.1544799325584; Fri, 14 Dec 2018 06:55:25 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Paul Congdon <>
Date: Fri, 14 Dec 2018 06:55:14 -0800
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000000d43e9057cfc9f02"
Archived-At: <>
Subject: Re: [Lsvr] WG Adoption call for draft-ymbk-lsvr-lsoe-03 (to end 17 December 2018)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Dec 2018 14:55:29 -0000

> Please indicate the following things:
> 1) Support to adopt draft " draft-ymbk-lsvr-lsoe-03" as LSVR WG document?

I do not support the adoption of this draft as is.  I still believe there
are technical issues which I describe below, but they can be fixed in a
future draft.

One other significant issue is the name of this protocol.  It is not a link
state protocol over ethernet and that can lead to confusion.  There is
already a standard 'link state' protocol over Ethernet called SPB (shortest
path bridging) in 802.1Q.

This is really a peer discovery and liveness protocol.  Better names would
be any of the following:

BGP Peer Discover Protocol over Ethenet, or just
Peer Discovery over Ethernet
Encapsulation Discovery over Ethernet

2) Are there any technical issues with this draft?

I still do not believe the ACK mechanism works without some sort of packet
number or identifier for what it is ACKing.  It is possible for an
unambiguous ACK to pass in flight with a retransmission can cause a
duplication at the receiver.

> 3) Which are current pain-points in the draft requiring additional content
> and technical attention?

Given that this protocol sends 'Hello' messages, I think the strict policy
of dropping packets that don't match the version number will create extra
chatter on the network when a subsequent version of this is rolled out.  It
would be a good idea to attempt to be forward/backward compatible if
possible.  Examples of this have been documented in 802.1.

> 4) What is missing from this draft?
As stated above

As a side note and FYI, I have requested time to present a consideration
for an LLDPv2 proposal within 802.1.   There is a universal need to extend
LLDP's ability to transfer TLVs beyond what can fit a single PDU and
several of us with 802.1 have created an initial proposal to be presented
at an upcoming conference call or F2F meeting.  This is not an intention to
challenge the contribution or need for this draft, rather to address a
current unmet need of a widely deployed protocol.


> The authors (or anybody else) of this draft should send their IPR
> statements in response to this email.
> Kind Regards,
> Gunter & Victor
> LSVR WG co-chairs
> _______________________________________________
> Lsvr mailing list