Re: [Bgp-autoconf] Short comparison of the different documents.

[Warren Kumari <[e-mail]>]

On Wed, Mar 4, 2020 at 5:01 PM Jeffrey Haas <[e-mail]> wrote:

> Warren,
>
> On Sat, Feb 29, 2020 at 03:52:14PM -0500, Warren Kumari wrote:
> > 4: BGP LLDP Peer Discovery - draft-acee-idr-lldp-peer-discovery
> > ------------------
> > This seems like a very good option to me -- LLDP is a well-known, well
> > implemented protocol. It also already carries information which solves
> > much of the "auditability" (are the cables right?) use-case.
> > I am concerned about the possible message size limits
>
> The size consideration is valid.  It does mean that if we end up with a
> large bit of configuration blob that baseline LLDP is no longer suitable.
>
> There is work going on in IEEE that will permit larger stuff for LLDP.
> But for purposes of our analysis I don't think we are specifically hung up
> on that expectation.
>

What I'm not sure about is if it is acceptable for a device to send
multiple LLDP messages - I've even read some of the 802.1AB spec to try
figure this out -- Section "9.1.3 Frame reception" seems to imply that new
information replaces old information, but I didn't explicitly see something
saying that this (wildly hacky) option is not allowed.
So, perhaps we could send out one LLDP packet with: Peering Address, Local
AS, BGP Identifier,  Session Group-ID, Session Capabilities, Key Chain
Name  ... keep adding things till you hit ~1400bytes.
and then a second LLDP packet with Local Address, Recursive Routes,
Favorite Cookie Types, Chassis ID, Port ID, System Name, etc.

If the "normal" LLDP stuff gets carried in the second PDU, it would be the
one that is displayed in CLI, etc. I suspect that this really is uglier
than we want to contemplate, but I'd be interested to know if it is
"allowed"




>
> > The document does still need work -  e.g it talks about Session
> > Group-IDs, but is very handwavey about what they are / what you do
> > with them.
>
> This was intentional. :-)  Much like "color" or "tag" or "community", we
> have situations where we want to tag a bit of discovery in a way that
> flexibly allows the deployment to decide what things mean.
>
> Easy examples of this was role in a switching fabric.
>

Fair -- but I think that it would be useful to better document that --
currently it just says: "Session Group-ID Sub-TLV is an opaque 4-octet value
that is used to represent a category of BGP session that is supported on
the interface."
Adding some text saying that operators can define whatever the hell they
would like in here - also, can I have multiple of these? I currently "tag"
routes with all sorts of communities, I might like to be able to annotate
that this is an External Facing, Spine, Managed node. I could encode that
into 3 of the 4 bytes, but I might prefer to attach 3 separate Session
Group-IDs


>
> I think for purposes of our analysis, the property I'd prefer to highlight
> is that discovery information may carry a way of marking that information
> for purposes of letting listeners do something useful.  This markup may
> carry non-standardized code points.  We may wish to design standardized
> code
> points as well for specific profiles, for example fabrics.
>

Yup, fair.

Thank you for the explanation,

W



>
> -- Jeff
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf