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

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 2 Mar 2020 12:43:52 +0000

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:[email-masked]] On Behalf Of Warren Kumari
Sent: Sunday, March 1, 2020 4:52 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/bgp-autoconf

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Mar 2020 17:07:27 -0500

Warren,

On Sat, Feb 29, 2020 at 03:52:14PM -0500, Warren Kumari wrote:
> 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.

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

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.

-- Jeff

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Mar 2020 17:50:18 -0500

> But for purposes of our analysis I don't think we are specifically hung up

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"

> 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

> points as well for specific profiles, for example fabrics.

Yup, fair.

Thank you for the explanation,

W

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Mar 2020 18:14:36 -0500

Warren,

> saying that this (wildly hacky) option is not allowed.

I think the best analogy is this is the RIP protocol: Throw out the old stuff.

> that is used to represent a category of BGP session that is supported on

When the rumors of the design team were spun up, work to rev the spec was
halted.  

> into 3 of the 4 bytes, but I might prefer to attach 3 separate Session

A use case I hadn't necessarily considered.  I think this was mostly that
the LLDP was scoped to interfaces and thus you'd likely have a single group
"namespace".

For the more general case where we may have different scoping that links we
may wish to use more than one.  So, perhaps something to add to the use
cases.

-- Jeff

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 12 Mar 2020 16:34:45 +0000

Hi Jeff, Warren and all,

Based on your discussion, it seems both of you agree with the requirement to advertise the role of a router to its peer. 

I'd like to check whether other design team members also agree with this? If there is rough consensus, we probably could add it to the common requirement list. 

As for the message size, IMO it may not be a big problem if a message is only for BGP auto-discovery, while if the protocol or message is shared with other applications, it may become large and can require some additional functionality to handle it. So yes we need to take this into consideration, but it may not be applicable to all candidate solutions. 

Best regards,
Jie

> From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of
> Jeffrey Haas
> Sent: Thursday, March 5, 2020 6:07 AM
> To: Warren Kumari <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Bgp-autoconf] Short comparison of the different documents.
> 
> Warren,
> 
> 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.
> 
> But for purposes of our analysis I don't think we are specifically hung up on
> that expectation.
> 
> 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.
> 
> 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2020 13:12:18 -0700

> Based on your discussion, it seems both of you agree with the
> requirement to advertise the role of a router to its peer.
> 
> I'd like to check whether other design team members also agree with
> this?

what roles?

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 17 Mar 2020 14:56:49 +0000

Hi Randy, 

Based on the discussion we had on the conference call and the mail discussion between Jeff and Warren, my understanding is we may consider it useful to provide a generic mechanism to advertise the role of a router to its peer. As mentioned in Jeff's mail, maybe it could be defined as a generic ID to give flexibility to the deployment. And as said in Warren's mail, depending on the operators requirement, the role can have different meanings in different use cases, and it may carry either well-known or customized code points.

I'd like to know your and other design team member's opinions on this. Thanks.

Best regards,
Jie

> From: Randy Bush [mailto:[email-masked]]
> Sent: Friday, March 13, 2020 4:12 AM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>; Warren Kumari <[email-masked]>;
> [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Mar 2020 16:04:35 +0100

I guess they are talking here about TOR, ACCESS, SPINE, SUPERSPINE, GWY ...

I guess in general it may be very useful, but in BGP itself and make it
transitive ...

Not sure how it changes anything during the basic session establishment
phase. Maybe to auto apply different peer template ?

On Tue, Mar 17, 2020 at 3:57 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Randy,
>
> Based on the discussion we had on the conference call and the mail
> discussion between Jeff and Warren, my understanding is we may consider it
> useful to provide a generic mechanism to advertise the role of a router to
> its peer. As mentioned in Jeff's mail, maybe it could be defined as a
> generic ID to give flexibility to the deployment. And as said in Warren's
> mail, depending on the operators requirement, the role can have different
> meanings in different use cases, and it may carry either well-known or
> customized code points.
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Mar 2020 09:48:34 -0700

jimmy,

i was perhaps a little subtle.  i contend that the attributes are not
decidable by anyone other than the op.

see Attribute List in draft-ymbk-lsvr-l3dl-ulpc

3.  Upper Layer Protocol Configuration PDU

   To communicate parameters required to configure peering and operation
   of Upper Layer Protocols at IP layer 3 and above, e.g., BGP sessions
   on a link, a neutral sub-TLV based Upper Layer Protocol PDU is
   defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 9   |                 Payload Length                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |   ULPC Type   |   AttrCount   |               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~       Attribute List ...      |    Sig Type   | Signature Len ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |                 Signature ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type and Payload Length are defined in [I-D.ietf-lsvr-l3dl].

   ULPC Type: An integer denoting the type of the uper layer protocol

   0     :  Reserved
   1     :  BGP
   2-255 :  Reserved

   The AttrCount is the number of attribute sub-TLVs in the Attribute
   List.

   The Attribute List is a, possibly null, set of sub-TLVs describing
   the configuration attributes of the specific upper layer protocol.

   An Attribute consists of a one octet Attribute Type, a one octet
   Attribute Length of the number of octets in the Attribute, and a
   Payload of arbitrary length up to 253 octets.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Attr Type = 1 |    Attr Len   |            Payload            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Mar 2020 15:52:58 +0000

Hi Robert,

In my understanding the role of a router is only advertised to the peer during BGP auto-discovery, so in general it will not be received by other BGP speakers.

There can be several different use cases of the role information, such as applying different policies/template for route advertisement, or for validation of session establishment (e.g. session between leafs may not be permitted). And if you have other use cases, please help to list them. Thanks.

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]]
Sent: Tuesday, March 17, 2020 11:05 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Randy Bush <[email-masked]>; Jeffrey Haas <[email-masked]>; [email-masked]; Warren Kumari <[email-masked]>
Subject: Re: [Bgp-autoconf] Short comparison of the different documents.

I guess in general it may be very useful, but in BGP itself and make it transitive ...

Not sure how it changes anything during the basic session establishment phase. Maybe to auto apply different peer template ?

On Tue, Mar 17, 2020 at 3:57 PM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Randy,

Best regards,
Jie

> From: Randy Bush [mailto:[email-masked]<mailto:[email-masked]>]
> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
> Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>; Warren Kumari <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>

--
Bgp-autoconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bgp-autoconf

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Mar 2020 16:03:47 +0000

Hi Randy,

Thanks for your comments and the information about l3dl-ulpc draft. 

In general I agree the value of the attribute should be decided by an operator, and its meaning may be only understood by that operator. While as discussed it may be useful to define a specific attribute type for a set of use cases and describe the typical use cases in some document. The attribute values will not be standardized (at least not all of them).

Best regards,
Jie

> Sent: Wednesday, March 18, 2020 12:49 AM
> i was perhaps a little subtle.  i contend that the attributes are not decidable
> by anyone other than the op.
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 18 Mar 2020 16:57:08 -0700

jie,

> There can be several different use cases of the role information, such
> as applying different policies/template for route advertisement, or
> for validation of session establishment (e.g. session between leafs
> may not be permitted). And if you have other use cases, please help to
> list them.

no.  we should not try to enumerate all possible operational practices,
roles of devices, ... in the design spec.  to explore the space, we may
need to discuss one or two examples to ensure we are not making a
serious omission.

but please let us not go down this capybara hole.

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 19 Mar 2020 14:47:24 +0000

Hi Randy,

> Sent: Thursday, March 19, 2020 7:57 AM
> Cc: Robert Raszuk <[email-masked]>; Jeffrey Haas <[email-masked]>;
> [email-masked]; Warren Kumari <[email-masked]>
> no.  we should not try to enumerate all possible operational practices, roles
> of devices, ... in the design spec.  to explore the space, we may need to
> discuss one or two examples to ensure we are not making a serious omission.

I guess we are in-sync about this.

My thought was to list a few typical use cases to prove that this is something useful in general, and I agree that we don't need to provide an exhaustive list. 

-Jie

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Mar 2020 08:39:39 -0700

jie,

to be clear i am good with a coulle of examples to motivate the need for
attributes.  but we should not specify any code points for any specific
attribuutes.

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 23 Mar 2020 06:20:32 +0000

Hi Randy, 

Thanks for your clarification. It is good that you also agree with the requirement. 

How such information should be encoded can be discussed later. 

Best regards,
Jie

-----Original Message-----
From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Thursday, March 19, 2020 11:40 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>; [email-masked]; Warren Kumari <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [Bgp-autoconf] Short comparison of the different documents.

jie,

to be clear i am good with a coulle of examples to motivate the need for attributes.  but we should not specify any code points for any specific attribuutes.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Mar 2020 16:03:49 -0700

ace,

so i have been sitting on this for a month, trying to think how to be
simple about this

draft-ymbk-lsvr-l3dl-ulpc was not directly intended for this.  it is a
layer two protocol to go with l3dl.  i think we probably want a layer
three protocol, though there are discovery issues.  btw, for loopback
peering, pass the forwarding setup in the attribute list.  though you
can discover that loopbacks are present, you re not going to discover
that loopback bgp peering is desired, and over which loopbacks (zing).

unfortunately draft-acee-idr-lldp-peer-discovery will need lldpv2 to get
reasonable pdus.  i am trying to help the lldpv2 work over in 802.1.  i
do not understand ieee processing pacing.  but if it took idr eight
yesas to change a constant 4,096 to 64k, i suspect i may not have the
patience for ieee (actually i was an ieee tag chair back in the early
'80s) :)

so i think we have some work to do.  but that's why we get the big bucks
or won.  settling the requirement parameters and limits up front is
important.  i see the extant drafts as examples and a source for ideas,
not competitors for a solution.

randy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 Mar 2020 11:13:04 +0000

Hi Randy, 
I think for the basic requirements, the deployed LLDP will suffice. I guess it depends on the other IEEE 802 TLVs that need to be sent in each periodic advertisement. 
Thanks,
Acee

On 3/24/20, 7:04 PM, "Bgp-autoconf on behalf of Randy Bush" <[email-masked] on behalf of [email-masked]> wrote:

    ace,

    

    randy