a quick survey about LLDP and similar

[pf at tippete.net (Pierfrancesco Caci)]

Thank you both for the feedback.
I left out the "it depends" because it is more suited to a conversation
or email thread like this than to a quick survey. I'm aware of a few
reasons for which "it depends" and I'm learning a few more from the
feedback I'm getting.

Pf


>>>>> "Eddie" == Eddie Parra <eparra at zscaler.com> writes:


    Eddie> +1 on it depends.  IMO, I would prefer LLDP vs. a vendor proprietary
    Eddie> discovery protocol.  Where you intend to run it in your network is a
    Eddie> major factor for risk.

    Eddie> Also, you forgot to add LLDP-MED to #5 (but it might not be relevant
    Eddie> to your services).

    Eddie> -Eddie



    >> On Feb 28, 2019, at 1:27 AM, Owen DeLong <owen at delong.com> wrote:
    >> 
    >> The problem with your survey is that thereâ??s no option to answer â??it dependsâ??.
    >> 
    >> Hard yes or no answers arenâ??t realistic to the questions youâ??re
    >> asking because the context,
    >> security parameters, sensitivity, and other parameters about the
    >> network all factor into a
    >> decision whether to run or not run such protocols.
    >> 
    >> There are some environments where the benefit and convenience is
    >> moderately high
    >> and the risk is extremely low. There are other environments where
    >> the benefit is relatively
    >> low, but the risks are significantly higher.
    >> 
    >> Owen
    >> 
    >> 
    >>> On Feb 28, 2019, at 01:00 , Pierfrancesco Caci <pf at tippete.net> wrote:
    >>> 
    >>> 
    >>> Hello,
    >>> having a bit of a debate in my team about turning on LLDP and/or CDP.
    >>> I would appreciate if you could spend a minute answering this
    >>> survey so I have some numbers to back up my reasoning, or to accept
    >>> defeat.
    >>> 
    >>> https://www.surveymonkey.com/r/TH3WCWP
    >>> 
    >>> Feel free to cross-post to other relevant lists. 
    >>> 
    >>> Thank you
    >>> 
    >>> Pf
    >>> 
    >>> -- 
    >>> Pierfrancesco Caci, ik5pvx
    >> 


-- 
Pierfrancesco Caci, ik5pvx