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

Hi Warren, 

Thanks a lot for your review and analysis of the solution drafts. It could help to identify the set of common requirements/functions, and also the differences between the solutions. 

I will provide a list of requirements based on the feedbacks received from the draft authors last week and share it to this list. Further comments on the requirements are welcome.

Best regards,
Jie

-----Original Message-----
From: Bgp-autoconf [mailto:bgp-autoconf-bounces@ietf.org] On Behalf Of Warren Kumari
Sent: Sunday, March 1, 2020 4:52 AM
To: bgp-autoconf@ietf.org
Subject: [Bgp-autoconf] Short comparison of the different documents.

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

--
Bgp-autoconf mailing list
Bgp-autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/bgp-autoconf