Subject: [Idr] draft-xu-idr-neighbor-autodiscovery-08

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Jul 2018 10:38:12 +0200

Few questions and comments on draft-xu-idr-neighbor-autodiscovery:

1. I recommend you rename HOLDTIME to H-TIME or R-TIME (Retention Time) in
order to avoid confusion with BGP OPEN HOLDTIME.

2. While most of the text is consistent and talks about single peering
address there is moment when plural form is used:  "that cover the peering
address(es)". Can someone elaborate more on intention here to send multiple
peering addresses ? Also if sending multiple peering addressed in BGP Hello
is being considered where such addresses will be actually sent as Peering
Address TLV clearly talks about single address

3. Related to #2 if I would like to send both IPv4 and IPv6 peering
addresses how those will be encoded ? Is there an assumption that Peering
Address TLV will be present multiple times in such cases ?

4. Are proposed Hello messages supposed to be send over all interfaces or
it will be customized on a per outbound interface or group of interfaces
basis ?

5. Having Peering Address TLV & Local Prefixes TLV (for cases of loopback
peering) I don't quite see a need for Link Attribute TLV at all.

6. Likewise Neighbor TLV seems quite unnecessary to me. To whom it will be
sent ? To the peer we just established the peering with :) ? To other peers
- why ?

7. One of the fundamental element of all BGP peerings is ability to detect
peering liveness without tuning down BGP holdtime timer. Yet this proposal
does not mention nor signal a bit about say BFD to be used mutually by both
sides on the discovered links.

8. The draft is also pretty silent on how often the BGP HELLOs  will be
sent. For example is there an exponential timer allowing to slow down when
the other side is not there yet ?

9. The text I read in the last paragraph is super scary:

   "A BGP peer
   maintains a hold timer with each Hello adjacency that it restarts
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, BGP
   concludes that the peer no longer wishes to keep BGP session for that
   link or that the peer has failed. The BGP peer then deletes the
   Hello adjacency.  The route towards the BGP neighbor's loopback
   address that had been dynamically created due to that BGP Hello
   adjacency SHOULD be deleted accordingly.  When the last Hello
   adjacency for an BGP session is deleted, the BGP peer terminates the
   BGP session and closing the transport connection."

Your recommendation for two octet BGP Hello Holdtime expressed in seconds
is 15 sec. Are you invalidating use and state machine associated with BGP
Keepalive MSG above? I recommend this text is removed as it adds a lot of
new mechanism to BGP state machine.

10. Do you plane to actually update BGP state machine ?

11. At present your auto-discovery does not mention anything about use of
BGP MD5 or TCP-A0. Is there an assumption that peers which are discovering
themselves will have those configured ? Is there also an assumption that I
should always trust information received with BGP Hello messages ?
Shouldn't we perhaps aim at private/public key authentication model instead
?

12. Draft says:

"BGP hello messages are only exchanged between physically connected peers
that are trustworthy."

How is that trust determined ? Is there an implicit assumption that BGP
Hello is something you need to enable on a per physical interface basis
where you know apriori the other side of the fiber ? Doesn't it reduce the
full automation one should expect out of this proposal ? Also when I peer
with someone via L2 switch - still assume on a p2p basis - does this setup
prevents me from use of BGP Hello Messages ?

Thx,
Robert.

PS. I would like to first understand the authors perspective on the above
observations before responding to Sue's WG adoption call.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Jul 2018 09:49:04 +0000

Hi Robert,

Thanks for your review and comments. Please check inline below for responses.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: 04 July 2018 14:08
To: idr wg <[email-masked]>
Subject: [Idr] draft-xu-idr-neighbor-autodiscovery-08

1. I recommend you rename HOLDTIME to H-TIME or R-TIME (Retention Time) in order to avoid confusion with BGP OPEN HOLDTIME.
[KT] Ack – we could rename it to disambiguate.

2. While most of the text is consistent and talks about single peering address there is moment when plural form is used:  "that cover the peering address(es)". Can someone elaborate more on intention here to send multiple peering addresses ? Also if sending multiple peering addressed in BGP Hello is being considered where such addresses will be actually sent as Peering Address TLV clearly talks about single address
[KT] It may be desired to have multiple (say loopback) peering addresses for different types of BGP sessions. E.g. IPv4 and IPv6 or any other AFI/SAFI split. Also see next comment.

3. Related to #2 if I would like to send both IPv4 and IPv6 peering addresses how those will be encoded ? Is there an assumption that Peering Address TLV will be present multiple times in such cases ?
[KT] Yes. One for each peering address.

4.. Are proposed Hello messages supposed to be send over all interfaces or it will be customized on a per outbound interface or group of interfaces basis ?
[KT] Customized on per interface basis that is defined by a local config policy/template.

5. Having Peering Address TLV & Local Prefixes TLV (for cases of loopback peering) I don't quite see a need for Link Attribute TLV at all.
[KT] At this point it is to exchange interface ID and addresses so that the links may be defined in an unambiguous was in the BGP-LS Link NLRI for each of these links. This may be required for BGP-SPF or other use-cases in DC where we want to signal the underlying link topology for say TE.

6. Likewise Neighbor TLV seems quite unnecessary to me. To whom it will be sent ? To the peer we just established the peering with :) ? To other peers - why ?
[KT] There may be policies that allow a peering to be accepted on a specific link. It would be good to avoid one side trying setup a BGP session while the other does not wish to. This mechanism allows establishment of a 2-way state at each link level before the BGP session establishment happens and also to ensure that the “peering route” is actually setup over that link.

7. One of the fundamental element of all BGP peerings is ability to detect peering liveness without tuning down BGP holdtime timer. Yet this proposal does not mention nor signal a bit about say BFD to be used mutually by both sides on the discovered links.
[KT] Yes, this was not covered explicitly but can be done optionally. The desire to run BFD is one such attribute that may be signaled using the link attribute TLV.

8. The draft is also pretty silent on how often the BGP HELLOs  will be sent. For example is there an exponential timer allowing to slow down when the other side is not there yet ?
[KT] This would be very similar to how IGPs or LDP run their hello which is periodic but then also triggered when some change or a new neighbor is learnt.

9.. The text I read in the last paragraph is super scary:

   "A BGP peer

Your recommendation for two octet BGP Hello Holdtime expressed in seconds is 15 sec. Are you invalidating use and state machine associated with BGP Keepalive MSG above? I recommend this text is removed as it adds a lot of new mechanism to BGP state machine.
[KT] There is no intention to change the BGP state machine for the TCP session. The hello procedure brings in its own mechanism which is gets to the same point where the BGP session is provisioned in existing procedure. Consider that an auto-discovered BGP session is to be removed or disabled on an interface. This can be done by taking that link out of this discovery mechanism. Such an action should result in stopping the hellos and subsequently we also would like the BGP session state at TCP level to be cleaned up at both ends.

10. Do you plane to actually update BGP state machine ?
[KT] No change. However, you are right that the relationship between the discovery mechanism and BGP state machine needs to be explained.

11. At present your auto-discovery does not mention anything about use of BGP MD5 or TCP-A0. Is there an assumption that peers which are discovering themselves will have those configured ? Is there also an assumption that I should always trust information received with BGP Hello messages ? Shouldn't we perhaps aim at private/public key authentication model instead ?
[KT] This aspect still needs to be covered.

12. Draft says:

"BGP hello messages are only exchanged between physically connected peers that are trustworthy."

How is that trust determined ? Is there an implicit assumption that BGP Hello is something you need to enable on a per physical interface basis where you know apriori the other side of the fiber ? Doesn't it reduce the full automation one should expect out of this proposal ? Also when I peer with someone via L2 switch - still assume on a p2p basis - does this setup prevents me from use of BGP Hello Messages ?
[KT] While this is true in a DC environment, perhaps we do need to define a generic security mechanism as part of this protocol extension.

Thanks,
Ketan

Thx,
Robert.

PS. I would like to first understand the authors perspective on the above observations before responding to Sue's WG adoption call.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Jul 2018 16:34:22 +0200

Hi Ketan,

Thank you for comments.

I see two fundamental issues here:

*Issue #1: *

With all assumptions made in the draft about awareness of the "other side"
as well as with the additional requirement to set per interface policy to
scope the content of BGP Hellos to specific peer or peers what is proposed
here is not autodiscovery. At most it is BGP build in automation for p2p
BGP session auto provisioning. So inbound configuration automation. Don't
we have sufficient set of tools already ? And this is only local ... It
does not discover IBGP or EBGP peers far from each other like proposed in
other IDR expired document: draft-raszuk-idr-bgp-auto-discovery-05

I am really not sure if we should do that in BGP, but if so let's at least
call it correctly.

*Issue #2: *

As you mentioned some proposed already TLVs have nothing to do with BGP.
What is defined is the IGP like interface_IDs discovery for the purpose of
LSVR. So initially LSVR claimed to *only* get passively BGP-LS information.
Now we see more stuff being defined to help LSVR. Where does it stop ? Do
we really want to add this code to BGP protocol which creates a global
Internet reachability only if someone thought about using LSVR in few DCs ?

You actually go further and already indicating that now BGP will be used as
topology discovery for TE purposes. This is getting IMHO really bad.

TLVs here look very innocent by itself ... but when you realize
consequences this attaches LSVR together with core BGP - at least BGP code
wise. I do not think this is good idea at all.

Note that because basic BGP is used in few MSDCs there is number of
followers which do want to use it also in much smaller DC fabrics. When you
have few hundreds L3 nodes regular link state routing (even without any
flooding reduction) would do much better job - but because of all of the
noise to use BGP a lot of folks are getting very confused and positioning
"BGP everywhere" regardless if this is optimal fit or not.

+ one more comment below ...

*​[KT] There is no intention to change the BGP state machine for the TCP
session. *

Well you are clearly calling for tearing down BGP upon missing reception of
BGP Hello by removing reachability information. Well let's discuss this
more. If BGP is established over connected interface (not to loopback) how
do you attempt to bring down BGP when BGP peer will stop sending Hellos ?

And if you have session between loopbacks is cutting reachability the best
way to bring down BGP between two peers ? It sounds like we spend so much
energy in routing BGP to be graceful that such brutal force is rather
something to be avoided.

So the way you are referring to deleting BGP sessions when Hellos stop does
require quite some interaction with other BGP mechanisms as well as
adjusting state machine. I understand you are trying to stay away from it
.. well I am afraid it is not going to be possible :(.

Thx,
R.

On Wed, Jul 4, 2018 at 11:49 AM, Ketan Talaulikar (ketant) <[email-masked]
> wrote:

> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* 04 July 2018 14:08
> *To:* idr wg <[email-masked]>
> *Subject:* [Idr] draft-xu-idr-neighbor-autodiscovery-08
>
>
>
>
>
> *[KT] Ack – we could rename it to disambiguate.*
>
>
>
> *[KT] It may be desired to have multiple (say loopback) peering addresses
> for different types of BGP sessions. E.g. IPv4 and IPv6 or any other
> AFI/SAFI split. Also see next comment.*
>
>
>
> *[KT] Yes. One for each peering address.*
>
>
>
> 4.. Are proposed Hello messages supposed to be send over all interfaces or
> *[KT] Customized on per interface basis that is defined by a local config
> policy/template.*
>
>
>
> *[KT] At this point it is to exchange interface ID and addresses so that
> the links may be defined in an unambiguous was in the BGP-LS Link NLRI for
> each of these links. This may be required for BGP-SPF or other use-cases in
> DC where we want to signal the underlying link topology for say TE.*
>
>
>
> *[KT] There may be policies that allow a peering to be accepted on a
> specific link. It would be good to avoid one side trying setup a BGP
> session while the other does not wish to. This mechanism allows
> establishment of a 2-way state at each link level before the BGP session
> establishment happens and also to ensure that the “peering route” is
> actually setup over that link.*
>
>
>
> *[KT] Yes, this was not covered explicitly but can be done optionally. The
> desire to run BFD is one such attribute that may be signaled using the link
> attribute TLV.*
>
>
>
> *[KT] This would be very similar to how IGPs or LDP run their hello which
> is periodic but then also triggered when some change or a new neighbor is
> learnt.*
>
>
>
> *​​*
> *[KT] There is no intention to change the BGP state machine for the TCP
> session. The hello procedure brings in its own mechanism which is gets to
> the same point where the BGP session is provisioned in existing procedure.
> Consider that an auto-discovered BGP session is to be removed or disabled
> on an interface. This can be done by taking that link out of this discovery
> mechanism. Such an action should result in stopping the hellos and
> subsequently we also would like the BGP session state at TCP level to be
> cleaned up at both ends.*
>
>
>
> *[KT] No change. However, you are right that the relationship between the
> discovery mechanism and BGP state machine needs to be explained.*
>
>
>
> *[KT] This aspect still needs to be covered.*
>
>
>
> 12. Draft says:
>
>
>
> *[KT] While this is true in a DC environment, perhaps we do need to define
> a generic security mechanism as part of this protocol extension.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Thx,
>
> Robert.
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Jul 2018 02:17:14 +0000

Hi Robert,

Apologies for the delay in response. Please check inline below.

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: 04 July 2018 20:04
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: idr wg <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] draft-xu-idr-neighbor-autodiscovery-08

Hi Ketan,

Thank you for comments.

Issue #1:

With all assumptions made in the draft about awareness of the "other side" as well as with the additional requirement to set per interface policy to scope the content of BGP Hellos to specific peer or peers what is proposed here is not autodiscovery. At most it is BGP build in automation for p2p BGP session auto provisioning. So inbound configuration automation. Don't we have sufficient set of tools already ? And this is only local ... It does not discover IBGP or EBGP peers far from each other like proposed in other IDR expired document: draft-raszuk-idr-bgp-auto-discovery-05

I am really not sure if we should do that in BGP, but if so let's at least call it correctly.
[KT] The mechanism described in draft-xu-idr-neighbor-autodiscovery is expected to work for directly connected BGP routers and using a link-local signaling. As such, it is different from the draft that you propose in scope and purpose even though there are similarities.

Issue #2:

As you mentioned some proposed already TLVs have nothing to do with BGP. What is defined is the IGP like interface_IDs discovery for the purpose of LSVR. So initially LSVR claimed to *only* get passively BGP-LS information. Now we see more stuff being defined to help LSVR. Where does it stop ? Do we really want to add this code to BGP protocol which creates a global Internet reachability only if someone thought about using LSVR in few DCs ?

You actually go further and already indicating that now BGP will be used as topology discovery for TE purposes. This is getting IMHO really bad.

TLVs here look very innocent by itself ... but when you realize consequences this attaches LSVR together with core BGP - at least BGP code wise. I do not think this is good idea at all.

Note that because basic BGP is used in few MSDCs there is number of followers which do want to use it also in much smaller DC fabrics. When you have few hundreds L3 nodes regular link state routing (even without any flooding reduction) would do much better job - but because of all of the noise to use BGP a lot of folks are getting very confused and positioning "BGP everywhere" regardless if this is optimal fit or not.
[KT] The draft does not propose or discuss any such aspects. It is primarily focused at DC deployments where BGP is already used/proposed.

​
[KT] There is no intention to change the BGP state machine for the TCP session.

Well you are clearly calling for tearing down BGP upon missing reception of BGP Hello by removing reachability information. Well let's discuss this more. If BGP is established over connected interface (not to loopback) how do you attempt to bring down BGP when BGP peer will stop sending Hellos ?

And if you have session between loopbacks is cutting reachability the best way to bring down BGP between two peers ? It sounds like we spend so much energy in routing BGP to be graceful that such brutal force is rather something to be avoided.

So the way you are referring to deleting BGP sessions when Hellos stop does require quite some interaction with other BGP mechanisms as well as adjusting state machine. I understand you are trying to stay away from it .. well I am afraid it is not going to be possible :(.
[KT] Will work on updating the draft with co-authors to clarify/detail these aspects in an upcoming version.

Thanks,
Ketan

Thx,
R.

On Wed, Jul 4, 2018 at 11:49 AM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: 04 July 2018 14:08
To: idr wg <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] draft-xu-idr-neighbor-autodiscovery-08

   "A BGP peer

​​

12. Draft says:

Thanks,
Ketan

Thx,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jul 2018 10:51:51 +0200

Hi Ketan,

Ad 1 - You missed the point of the issue. The point was that you are *not*
doing any discovery - at most automating some aspects of BGP provisioning
for MSDCs. The other draft was just the example what is auto discovery ie.
you don't apriori know the other side. Here due to amount of policy
required to scope BGP Hellos per interface you surely do.

Ad 2 - If draft does not propose any such aspects please remove TLVs which
are there for LSVR.

Ad 3 - Today BGP sessions goes down either via manual shut or via missing
keepalives. You are asking for bringing BGP sessions down based on missing
BGP Hellos. This is new state to BGP operation. If you remove this section
making BGP Hellos only for BGP session auto configuration bootstrapping as
ephemeral data - point will be addressed.

Thx,
R.

On Thu, Jul 12, 2018 at 4:17 AM, Ketan Talaulikar (ketant) <[email-masked]

> *From:* [email-masked] <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* 04 July 2018 20:04
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* idr wg <[email-masked]>; Susan Hares <[email-masked]>
> *Subject:* Re: [Idr] draft-xu-idr-neighbor-autodiscovery-08
>
>
>
> Hi Ketan,
>
>
>
> Thank you for comments.
>
>
>
> *[KT] The mechanism described in draft-xu-idr-neighbor-autodiscovery is
> expected to work for directly connected BGP routers and using a link-local
> signaling. As such, it is different from the draft that you propose in
> scope and purpose even though there are similarities.*
>
>
>
> *Issue #2: *
>
>
>
> You actually go further and already indicating that now BGP will be used
> as topology discovery for TE purposes. This is getting IMHO really bad.
>
>
>
> *[KT] The draft does not propose or discuss any such aspects. It is
> primarily focused at DC deployments where BGP is already used/proposed.*
>
>
>
>
>
> *​*
> Well you are clearly calling for tearing down BGP upon missing reception
> of BGP Hello by removing reachability information. Well let's discuss this
> So the way you are referring to deleting BGP sessions when Hellos stop
> does require quite some interaction with other BGP mechanisms as well as
> *[KT] Will work on updating the draft with co-authors to clarify/detail
> these aspects in an upcoming version.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
> On Wed, Jul 4, 2018 at 11:49 AM, Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Robert,
>
>
>