Subject: [Bgp-autoconf] Questions to draft‐dt‐idr‐bgp‐autoconf‐considerations‐00

From: Linda Dunbar <[email-masked]>
Date: Tue, 26 Jan 2021 23:54:32 +0000

Jeff and Warren,

Section 2.3 Page 3 third bullet says “Discovery of BGP transport protocol end-points”:
The previous bullet already stated that the directly attached interface address can be used. Can we assume that the "directly attached interface address" is the Transport protocol "end point" address?
Is there any problem in using Reverse ARP (IPv4)  or Neighbor Solicitation (IPv6) to discover the neighbor’s link or loopback addresses? There is no mentioning of using RARP/NS in the document.

The 3rd bullet also says “layer 3 liveness mechanism such as BFD and support for GTSM”. Can node use BGP UPDATE to validate neighbor’s liveness?

4th bullet says “discovery of BGP peer session parameters relevant to peer selection such as AS, BGP ID, ..”
Is there any reason that the information carried by BGP OPEN cannot be used?

6th bullet says “once this information has been learned, a BGP Speaker has the necessary information…. to open BGP session”
This requirement prohibits a node to learn peer's ASN number from BGP OPEN message. Is it necessary to have this requirement, and why?

Section 2.4 says that “BGP auto-Discovery Protocol State may be carried in multiple transport protocols”
BGP running over TCP,  what other transport protocols are implied here?

Section 3:
1st bullet says “Select or otherwise filter which peers to actually try to send BGP OPEN msg”.
Can the selection be NULL, meaning all directly connect neighbors?

Section 4.1 Transport considerations:
Calling Layer 2 or Layer 3 as "transport" options is confusing, conflict with common used Transport Layer (TCP/UDP/QUIC).

Section 5.1 says there are two available candidates for peer discovery at Layer 2.
Should add the 3rd option:
Reverse ARP (IPv4) can also find the IP address on P2P links.
For IPv6: Neighbor Solicitation message [RFC4861] can be used to get neighbor's Link address and IP addresses

Thank you,

Linda Dunbar
From: Jeffrey Haas <[email-masked]>
Sent: Tuesday, January 26, 2021 7:54 AM
To: Sue Hares <[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>; Majumdar, Kausik <[email-masked]>
Subject: Re: [Bgp-autoconf] Issues not mentioned in yesterday's revision

On Jan 26, 2021, at 8:52 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Jeff and Warren:

Thank you for the first draft.

This isn't even a full first draft.  It's the work in progress as currently completed for discussion today.

We can certainly cover many of the items you list below today if that's your agenda.

-- Jeff

Here’s a list of requirements that I do not see mentioned:

1.  security requirements -

Is it a requirement to secure data sent in a L3 multicast BGP auto-configuration packet?
Is there a requirement that people could send a secure portion of the packet if they desired?

It all gets down to trust vs. complexity

2.  validation of Data sent

Will the bgp-autoconf  check syntax of data sent?
Will it validate the content of the data set?

3.  Will it carry link level information?
If so, what security issues will that cause.
If you trust everyone, what about errors in the fabric.

4.  Will it have a link to BFD?

5.  What requirements are there on top of the IP Multicast -
 Is the IP multicast a “spray and pray” multicast without   or is it “blast and echo check”?

Mechanisms that I personally hoped would work:
a) layer 3 multicast with “blast and echo” with ability to go through 2+ switches on way to remote end
b) optional securing of the data sent on BGP auto-configuration
c) Fast failure - via BFD or some “x” mechanism
d) optional bootstrap from IGPs or LLDP
Mechanism that I personally hoped a BGP-5 might revise its FSM.

Sue

--
Bgp-autoconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bgp-autoconf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbgp-autoconf&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5d51d738ae44df9088308d8c201e7fd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637472660728036184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=sBbKUQfc%2FpTUGAe5wub%2FaCsWF24DurbxwotNF8I9UQs%3D&reserved=0>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 27 Jan 2021 16:19:25 +0000

Hi Linda,

Thanks a lot for your review and the comments. Here I try to give my thoughts to some of them. Please see inline with [Jie]:

From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 27, 2021 7:55 AM
To: Jeffrey Haas <[email-masked]>; Sue Hares <[email-masked]>
Cc: [email-masked]; Majumdar, Kausik <[email-masked]>
Subject: [Bgp-autoconf] Questions to draft‐dt‐idr‐bgp‐autoconf‐considerations‐00

Jeff and Warren,

[Jie] The previous bullet says “The ability to use directly attached interface addresses, or the device's Loopback address”. Thus it is not always the directly attached interface address. The direct interface address can be obtained via RARP or ND, while the loopback address may need some additional effort.

[Jie] My understanding of this bullet is some liveness mechanism faster than BGP keepalive or Update is needed.

[Jie] This bullet is about the information which are needed in determining whether and how to set up the BGP peer session , BGP OPEN will be exchanged after this.

While one minor question from myself is about the discovery of address families/subsequent-address families (AFI/SAFIs) information. I can see this could help to avoid the failure in address families negotiation in BGP OPEN, while is this information be considered optional?

[Jie] I don’t think it prohibits the ASN learning in BGP OPEN, as the BGP OPEN procedure will be kept unchanged. While since the ASN number is already known from the BGP discovery, the ASN in BGP OPEN may be considered as a validation.

[Jie] Here the transport protocol refers to the protocol which is used to carry the BGP autoconf information. As discussed in the draft and the meeting, there are several candidates.

Section 3:

[Jie] I think NULL can also be one option.

[Jie] I agree transport may confuse some people who are not involved in the design team discussion. Does anyone have some better choice for this?

[Jie] Here the candidates mainly refers to the candidate solutions described in the drafts related to BGP peer discovery. The mechanisms you mentioned may be used as options for the direct peer address discovery, while they may not meet other requirements listed in the draft. Nevertheless, it seems no harm to have some discussion about their functionality and limitations in the design team.

Best regards,
Jie

Thank you,

Linda Dunbar
From: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 26, 2021 7:54 AM
To: Sue Hares <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Majumdar, Kausik <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bgp-autoconf] Issues not mentioned in yesterday's revision

Jeff and Warren:

-- Jeff

1.  security requirements –

c) Fast failure – via BFD or some “x” mechanism

Sue

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 Jan 2021 07:52:38 -0500

Forwarding to list

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, January 26, 2021 6:55 PM
To: Jeffrey Haas; Sue Hares
Cc: [email-masked]; Majumdar, Kausik
Subject: Questions to draft‐dt‐idr‐bgp‐autoconf‐considerations‐00

Jeff and Warren,

Section 2.3 Page 3 third bullet says “Discovery of BGP transport protocol
end-points”:

The previous bullet already stated that the directly attached interface
address can be used. Can we assume that the "directly attached interface
address" is the Transport protocol "end point" address?

Is there any problem in using Reverse ARP (IPv4)  or Neighbor Solicitation
(IPv6) to discover the neighbor’s link or loopback addresses? There is no
mentioning of using RARP/NS in the document.

The 3rd bullet also says “layer 3 liveness mechanism such as BFD and
support for GTSM”. Can node use BGP UPDATE to validate neighbor’s
liveness?

4th bullet says “discovery of BGP peer session parameters relevant to peer
selection such as AS, BGP ID, ..”

6th bullet says “once this information has been learned, a BGP Speaker has
the necessary information…. to open BGP session”

This requirement prohibits a node to learn peer's ASN number from BGP OPEN
message. Is it necessary to have this requirement, and why?

Section 2.4 says that “BGP auto-Discovery Protocol State may be carried in
multiple transport protocols”

Section 3:

1st bullet says “Select or otherwise filter which peers to actually try to
send BGP OPEN msg”.

Calling Layer 2 or Layer 3 as "transport" options is confusing, conflict
with common used Transport Layer (TCP/UDP/QUIC).

Section 5.1 says there are two available candidates for peer discovery at
Layer 2.

For IPv6: Neighbor Solicitation message [RFC4861] can be used to get
neighbor's Link address and IP addresses

Thank you,

Linda Dunbar

From: Jeffrey Haas <[email-masked]>
Sent: Tuesday, January 26, 2021 7:54 AM
To: Sue Hares <[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>;
Majumdar, Kausik <[email-masked]>
Subject: Re: [Bgp-autoconf] Issues not mentioned in yesterday's revision

On Jan 26, 2021, at 8:52 AM, Susan Hares <[email-masked]> wrote:

Jeff and Warren:

This isn't even a full first draft.  It's the work in progress as currently
completed for discussion today.

We can certainly cover many of the items you list below today if that's your
agenda.

-- Jeff

Is it a requirement to secure data sent in a L3 multicast BGP
auto-configuration packet?

Is there a requirement that people could send a secure portion of the packet
if they desired?

 Is the IP multicast a “spray and pray” multicast without   or is it
“blast and echo check”?

a) layer 3 multicast with “blast and echo” with ability to go through 2+
switches on way to remote end

Sue

--
Bgp-autoconf mailing list
 <mailto:[email-masked]> [email-masked]

<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
org%2Fmailman%2Flistinfo%2Fbgp-autoconf&data=04%7C01%7Clinda.dunbar%40future
wei.com%7Ce5d51d738ae44df9088308d8c201e7fd%7C0fee8ff2a3b240189c753a1d5591fed
c%7C1%7C0%7C637472660728036184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=sBbKUQfc%2FpTUGAe
5wub%2FaCsWF24DurbxwotNF8I9UQs%3D&reserved=0>
https://www.ietf.org/mailman/listinfo/bgp-autoconf