Re: [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal

[Randy Bush <[e-mail]>]

hey paul,

>>> Back in 2021, IEEE 802.1 enhanced LLDP to support the discovery
>>> requirements of LSVR.
>> uh, did lldpv2 get through the ieee sausage machine yet?  i think we
>> had a race to see which machine could take the longest :)
> The first draft was September 2020.  Technical changes were completed
> in September of 2021 and it was published in April of 2022.  I think
> IEEE 802.1 won that race 😉

read again.  the race was to see which org could take the *longest*.  so
the ietf has won!  but the contest was not really fair.  we practiced;
it took the ietf eight years to change the constant 4,096 to 65,535 (see
RFC 8654).  :)

>> as i remember, there were two problems with using lldpv2 in this
>> space which l3dl addresses, security and serious scale.  has lldpv2
>> managed to move forward on these?  truth is, it has all been so long,
>> i did not keep my eyes on the ball.
> 
> LLDP itself does not have any inherent security features and that was
> never part of its scope. It would be expected to run ontop of MACSec
> or people could security their own TLVs using other approaches.

to me, this is a show-stopper.  this is like the ietf in the old days
"no this is not secure.  run it over ipsec."  it's not the 1990s any
more; though i sure wish it was.

one of the lessons we have learned over the years is that a protocol
designed for the LAN will be deployed on the WAN, and vice versa.  heck,
this WG is hacking BGP for the LAN :)  security is pretty much required
these days.

> I'm not sure what you mean by serious scale issues.

think of a pod with 20 or whatever racks, 40 servers each, and a jillion
micro-services on each server.  and they want service mobility.  observe
the serious scale of l3dl.  and, with l3dl, there are some *simple* and
*efficient* ways to achieve this.

randy