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

[Warren Kumari <[e-mail]>]

Hi there all,

I read through the documents at
https://git.rg.net/randy/randy/src/master/bgp-autodiscovery.md trying
to figure out the pros and cons for each, which best fits the
use-cases, which seems most complete, etc.

There are my first round of notes / thoughts - they are not very
complete or organized.

1:  L3DL Upper Layer Protocol Configuration - draft-ymbk-lsvr-l3dl-ulpc-02
---------------------------
I like this document - it is really simple, flexible and clear. It
seems easily extensible (add some TLVs), but I do have some concerns:
1.1: this rides on L3DL, and so (obviously) will need equipment to
support / implement L3DL. I have not reviewed draft-ietf-lsvr-l3dl in
depth, but from a quick skim it seems reasonable (although I do have a
bunch of nits / comments on the document which I will send over once
I've written them up)

1.2: It looks easily extensible, although I am a bit concerned that
the type field is only 8 bits (easily changed if others agree)

1.3: It currently does not support adding routes so that I can peer
between loopback. This could be easily added to the protocol, but we
will need to figure out if it is a good idea, the implications, how to
minimize the threat of doing so (this is true for all of these
protocols, not just L3DL-ULPC)

1.4: I didn't understand Section 3.1.5 - perhaps it is just an example
of extensibility?

1.5: The security considerations made me giggle - this *is* an
important feature.

Missing: Loopback recursion peering, BFD, requires L3DL - not implemented.
Other thoughts: This (L3DL) builds something like a session (unlike
the LLDP document) - is this a feature or a bug? I think feature,
but...


2: BGP Neighbor Discovery - draft-xu-idr-neighbor-autodiscovery
----------------------------
I found this document hard to read - it is overly verbose and needs a
good edit to make it understandable.
It seems overly complex, and requires changes to BGP / feels like it
tries to shoehorn BGP into this use-case, instead of being a separate
discovery protocol which then "bootstraps" BGP.

The complexity / changes to BGP largely ruled this one out for me.


3: BGP Automated Session Setup - draft-raszuk-idr-bgp-auto-session-setup
------------------------
Sufficiently incomplete that it doesn't really say anything / I was
not able to evaluate it -- it seems more like an aspirational /
placeholder document.
e.g:
"The following changes to BGP FSM are proposed: To be completed
when/if document gets traction in the WG."


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 (it was unclear
from my initial reading how extensible this is -- e.g: if I need to
send 1000 bytes of "information" can I send some TLVs in one packet
and then the rest in a second one? I don't see why not, but....
This currently (like most!) punts on "recursive routes", and BFD, and
various other things - but I see no reason why this transport could
not be used to carry $whatever_we_decide.

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. It also needs firming up re: things like ASN transitions
(you can advertise a second ASN, but there is not enough text around
choosing between them, etc).


Summary:
-----------------
I like both the L3DL-ULPC and LLDP options. The other two are either
too complex, or incomplete.

The L3DL-ULPC draft is nicely simple, but some of this may be because
it isn't as complete as the LLDP document and / or complexity may hide
in L3DL itself.

LLDP has the big advantage that it rides on an existing, implemented
and deployed protocol.  If we can deal with the limited size issue, it
is my current preference.


W

[0]:  I'm going to call these "recursive routes" for now. It's not the
right term, but it is the only one I can think of at the moment!

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