Subject: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

From: "Susan Hares" <[email-masked]>
Date: Mon, 2 Sep 2019 14:01:58 -0400

This begins a 2 week WG adoption call for
draft-merciaz-idr-bgp-bfd-strict-mode-02.txt which you can access at:

https://datatracker.ietf.org/doc/draft-merciaz-idr-bgp-bfd-strict-mode/

For those who have indicated support for this draft during the lengthy IPR
call, you are welcome to comment again

or to trust that the IDR chairs read your comments during the lengthy IPR
call. 

Please indicate if you think this draft is a good start for using the BFD
technology 

as a check that prevents BGP connectivity until BFD session is established 

(indicating link connectivity).  

Cheerily, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 5 Sep 2019 07:50:54 +0000

Hello Sue,

I support the adoption of this draft by the WG. Specification of the signalling mechanisms and interaction with BGP operations is required for interoperability.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 02 September 2019 23:32
To: [email-masked]
Subject: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

This begins a 2 week WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt which you can access at:

For those who have indicated support for this draft during the lengthy IPR call, you are welcome to comment again
or to trust that the IDR chairs read your comments during the lengthy IPR call.

Please indicate if you think this draft is a good start for using the BFD technology
as a check that prevents BGP connectivity until BFD session is established
(indicating link connectivity).

Cheerily, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 5 Sep 2019 20:04:55 +0000

I support it.

Thanks,
Jakob.

On Sep 5, 2019, at 12:51 AM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Sue,

I support the adoption of this draft by the WG. Specification of the signalling mechanisms and interaction with BGP operations is required for interoperability..

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: 02 September 2019 23:32
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

Cheerily, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 6 Sep 2019 19:57:17 +0000

Speaking as a co-author, I support WG adoption.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Monday, September 2, 2019 at 2:02 PM
To: IDR List <[email-masked]>
Subject: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

Cheerily, Susan Hares

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 6 Sep 2019 21:46:25 +0000

I support the adoption of this draft. This mechanism is needed for BGP interoperability.

Thanks,
Yingzhen

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 2, 2019 at 2:02 PM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

https://datatracker.ietf.org/doc/draft-merciaz-idr-bgp-bfd-strict-mode/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-merciaz-idr-bgp-bfd-strict-mode%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ca894b26619874ef0da5108d733050324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637033968943042447&sdata=KDsSEOQMj0oNqYIbB2pA%2BRRvWQlt1XJn5RVKFNMcHu0%3D&reserved=0>

Cheerily, Susan Hares

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 6 Sep 2019 19:40:41 -0700

Support the adoption, long time due!

Regards,
Jeff

> On Sep 2, 2019, at 11:01, Susan Hares <[email-masked]> wrote:
> 
> [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 8 Sep 2019 23:36:09 +0200

Hi Acee,

I have read the draft. Have one key question in fact triggered by
colleagues comment below :)

In the draft you are not making any distinction between iBGP and eBGP
sessions. Is this intentional ?

Procedures to establish and maintain eBGP vs iBGP sessions are
vastly different hence an obvious question if you intentionally made no
distinction or perhaps you had in mind all along that the draft applies
only to eBGP ?

I think for eBGP it is useful, for iBGP I already see real cases where it
may not give you what you expect.

In any case I support the adoption.

Thx,
Robert.

On Fri, Sep 6, 2019 at 9:57 PM Acee Lindem (acee) <[email-masked]> wrote:

> *From: *Idr <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date: *Monday, September 2, 2019 at 2:02 PM
> *To: *IDR List <[email-masked]>
> *Subject: *[Idr] WG adoption call for
> draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Sep 2019 15:20:00 +0000

Support.

Linda Dunbar

On Sep 2, 2019, at 11:01, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt which you can access at:

https://datatracker.ietf.org/doc/draft-merciaz-idr-bgp-bfd-strict-mode/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-merciaz-idr-bgp-bfd-strict-mode%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C278c8238c06340b1112108d7333cd385%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637034208672171016&sdata=R9HrMQ8sZ3zIzDTbpCm6%2BBkHm4nGDb5DPexZufUyxvU%3D&reserved=0>

Cheerily, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C278c8238c06340b1112108d7333cd385%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637034208672171016&sdata=890sEQuixUAC6mjiECiQ%2F%2F3ghgpw5QGuBEZDnA9eR7k%3D&reserved=0>

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Mon, 9 Sep 2019 17:17:46 +0000

Support its adoption.

However, as I talked with some of the co-authors privately, this “Value” filed (i.e., the BFD Flags) of the capability
does not server any useful purpose and is not needed.  I suggest the field be removed.

Thanks.  -- Enke

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Monday, September 2, 2019 at 11:02 AM
To: "[email-masked]" <[email-masked]>
Subject: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

Cheerily, Susan Hares

---

From: "Mercia Zheng (merciaz)" <[email-masked]>
Date: Mon, 9 Sep 2019 19:33:24 +0000

Hi Susan,

I support WG adoption as a co-author.

Thanks,
Mercia

Cheerily, Susan Hares

---

From: "Mercia Zheng (merciaz)" <[email-masked]>
Date: Mon, 9 Sep 2019 21:31:57 +0000

Hi Robert,

Thanks for the review comments.
The similar question has been asked early on whether  or not this draft should be only for eBGP.
BGP BFD is enabled mostly for eBGP. RFC5882 section 10.2 specifies  “it is generally
unwise for IBGP sessions to interact with BFD if the underlying IGP
is already doing so.”.

There could still be cases where users only want to run iBGP BFD since no IGP is enabled
(e.g. fully mesh case).

Anyway, we’ll take care of this comment in the next revision.

Thanks,
Mercia

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Sunday, September 8, 2019 at 2:37 PM
To: "Acee Lindem (acee)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

Hi Acee,

I have read the draft. Have one key question in fact triggered by colleagues comment below :)

In the draft you are not making any distinction between iBGP and eBGP sessions. Is this intentional ?

Procedures to establish and maintain eBGP vs iBGP sessions are vastly different hence an obvious question if you intentionally made no distinction or perhaps you had in mind all along that the draft applies only to eBGP ?

I think for eBGP it is useful, for iBGP I already see real cases where it may not give you what you expect.

Thx,
Robert.

On Fri, Sep 6, 2019 at 9:57 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as a co-author, I support WG adoption.
Thanks,
Acee

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2019 23:43:34 +0200

Hi Mercia,

Many thx for an ack and reply.

Yes making the reference to RFC5882 section 10.2 is helpful. I see some
today may still run BFD on IBGP sessions for no reason. In fact it is
actually a sign of bad BGP design if such IBGP sessions are towards route
reflectors.

> (e.g. fully mesh case).

Well let's not equate full mesh of IBGP with deployment of BGP as IGP.
Those are completely different deployment models.

While someone could run iBGP in a p2p mode as DC reachability protocol that
is rather an exception then a rule.

Concluding - I think it would be pretty safe to state that draft applies
only to point-to-point BGP sessions.

Kind regards,

Robert.

On Mon, Sep 9, 2019 at 11:32 PM Mercia Zheng (merciaz) <[email-masked]>
wrote:

> *unwise* for IBGP sessions to interact with BFD if the underlying IGP
>
> is already doing so.”.
>
>
>
> *From: *Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Sunday, September 8, 2019 at 2:37 PM
> *To: *"Acee Lindem (acee)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
> *Subject: *Re: [Idr] WG adoption call for

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Sep 2019 13:00:30 -0400

Robert,

> is rather an exception then a rule.

Directly connected iBGP happens.

> only to point-to-point BGP sessions.

But that said, protecting iBGP when it's not directly connected also
happens.  It has a range of caveats.

IMO, it's unwise to unnecessarily restrict when strict mode gets used.  If
you're choosing to use BFD, you'll need this mechanism for interop.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 19:13:44 +0200

Jeff,

> you're choosing to use BFD, you'll need this mechanism for interop.

The fact that someone may enable BFD on IBGP how unwise it can be we can
not help.

But see this solution one of the main benefits is to give green light to
BGP OPEN when BFD between said multihop endpoints get's established.

But just please imagine that we are talking about WAN where there is a lot
of ECMP paths (across nodes or across links). What makes you even remotely
think that the actual path BFD packet take will be the same as the path TCP
OPEN to 179 is going to take ? Last time I checked hashes are very random
for a good reasons.

So I am not talking about some fancy purity ... I am talking about basic
functionality which this draft is stating to provide and which can not be
met over other then p2p links/sessions.

Many thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Sep 2019 13:41:35 -0400

Robert,

> BGP OPEN when BFD between said multihop endpoints get's established.

Not in the current definition of the feature.  The only thing signaled is
where in the BGP state machine the BFD session needs to be established
before the FSM may advance.

In the absence of the capability, or the S-bit set to zero (I recognize
Enke's point that the bit is redundant), sessions will fall back to prior
BFD behaviors.

> OPEN to 179 is going to take ? Last time I checked hashes are very random

Or even over external paths.  It may be a LAG, e.g.

> met over other then p2p links/sessions.

I recognize the point you're trying to make.  This draft does not address
when BFD may or may not be used - only how to make BFD coming up
interoperable.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 20:46:22 +0200

Jeff,

The draft makes it very clear in number of sentences that BGP session state
now will depend on BFD. In case of multihop (typical case for say IBGP to
RRs) this can not be accomplished by two different independent flows.

Example:

   To avoid situations which result in routing churn and to minimize the
   impact of network interruptions, it will be beneficial to disallow
   BGP to establish a session until BFD session is successfully
   established and has stabilized.

If you really want to make it work for IBGP (other then corner p2p use
cases) you need to encap both BFD and BGP into UDP/IP header and treat as
one flow. I don't see any issue with that. Otherwise it will likely only
create either false positives or false alarms.

And last bringing down the BGP session to RRs just because BFD in strict
mode on that session got a hiccup serves no good. The 180 sec long
keepalives are there for good reasons especially when RRs are not in the
data plane path. The paths they advertised may be completely healthy and
clients may reach each other just fine when say control plane of x86 where
you had your virtual RR reloads and to bring it up takes say 60 sec.

To detect remote next hop liveness you have different mechanisms in place.

Many thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Sep 2019 10:49:56 -0400

Robert,

On Tue, Sep 10, 2019 at 08:46:22PM +0200, Robert Raszuk wrote:
> one flow. I don't see any issue with that.

Aside from some radical changes to BGP transport.  That's a non-starter, and
not a problem we're intending to address.

> mode on that session got a hiccup serves no good.

As I noted in the last response, there's a number of caveats.  Your use case
may be different than someone else's.  If you don't like it - don't do that.

Again, BFD gets used both in single and multi-hop situations for BGP.  We're
only addressing where in the state machine it's used, not the use cases.
And very intentionally, not prohibiting existing use cases.

> To detect remote next hop liveness you have different mechanisms in place.

See draft-ietf-idr-rs-bfd for some discussion on that.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 12 Sep 2019 13:57:06 +0000

Hi Jeff, Robert, 
I couldn't agree more with Jeff. 
Thanks,
Acee

On 9/11/19, 10:49 AM, "Idr on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Robert,

    

    

    -- Jeff