[Bgp-autoconf] RE: Questions to draft�\dt�\idr�\bgp�\autoconf�\considerations�\00

["Dongjie (Jimmy)" <[e-mail]>]

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:[e-mail]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 27, 2021 7:55 AM
To: Jeffrey Haas <[e-mail]>; Sue Hares <[e-mail]>
Cc: [e-mail]; Majumdar, Kausik <[e-mail]>
Subject: [Bgp-autoconf] 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.

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

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?

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

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?

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

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?

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

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?

[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:
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?

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

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

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

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

[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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 26, 2021 7:54 AM
To: Sue Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Majumdar, Kausik <[e-mail]<mailto:[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]<mailto:[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 ¨C

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 ¨C 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
[e-mail]<mailto:[e-mail]>
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>