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

>
> 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.

Regards,
Paul

>
>
> 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
> Lsvr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsvr
>