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

[Susan Hares <[e-mail]>]

Forwarding to list



From: Linda Dunbar [mailto:[e-mail]]
Sent: Tuesday, January 26, 2021 6:55 PM
To: Jeffrey Haas; Sue Hares
Cc: [e-mail]; 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, ..”

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 <[e-mail]>
Sent: Tuesday, January 26, 2021 7:54 AM
To: Sue Hares <[e-mail]>
Cc: [e-mail]; Linda Dunbar <[e-mail]>;
Majumdar, Kausik <[e-mail]>
Subject: Re: [Bgp-autoconf] Issues not mentioned in yesterday's revision







On Jan 26, 2021, at 8:52 AM, Susan Hares <[e-mail]> 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
 <mailto:[e-mail]> [e-mail]

<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