Subject: [Idr] BGP Auto discovery - L2 liveliness??

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 20 Jul 2018 15:43:49 +0000

Could someone please explain - How is L2 liveliness important for auto-discovery between 2 directly connected BGP neighbors (referring to the topology shown yesterday)? Or is it really meant to benefit the peering relationship (once established) - bring down the peer if L2 fails or vice versa?

Or is it meant to benefit the (tenant/services) traffic (past bgp NLRI exchange) ? Likely not, since  (tenant/services) traffic may be L3 (or MPLS), and L2 liveliness would not be sufficient (after all, L2 can be working, while L3 might not or MPLS might not). 

Cheers,
Rajiv

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 20 Jul 2018 17:02:05 +0000

Hi Rajiv, 
This function is described in section 6 of https://www.ietf.org/id/draft-ymbk-lsvr-lsoe-01.txt. I guess you are questioned whether it should be a requirement of this mechanism. 

Thanks,
Acee 

On 7/20/18, 11:43 AM, "Rajiv Asati (rajiva)" <[email-masked]> wrote:

    
    Cheers,
    Rajiv

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2018 19:20:46 +0200

Acee,

I have a comment on this section 6 and subsequent section 5.2.2 of the
document you quoted:

Link Hello are proposed to detect the L2-L2.5-L3 liveness. Well there is a
lot of real life issues with link liveness appearing sporadically and only
at some specific packet sizes. The Hello of fixed size of 25 octets will
not detect it. A sweep size is a must.

That perhaps will not likely appear in p2p fiber - however if someone is
trying to use emulated L2 links as part of DC infra it may very well be the
case.

Thx,
R.

On Fri, Jul 20, 2018 at 7:02 PM, Acee Lindem (acee) <
acee=[email-masked]> wrote:

> Hi Rajiv,
> This function is described in section 6 of https://www.ietf.org/id/draft-
> ymbk-lsvr-lsoe-01.txt. I guess you are questioned whether it should be a
> requirement of this mechanism.
>
> Thanks,
> Acee
>
>     Could someone please explain - How is L2 liveliness important for
> auto-discovery between 2 directly connected BGP neighbors (referring to the
> topology shown yesterday)? Or is it really meant to benefit the peering
> relationship (once established) - bring down the peer if L2 fails or vice
> versa?
>
>     Or is it meant to benefit the (tenant/services) traffic (past bgp NLRI
> exchange) ? Likely not, since  (tenant/services) traffic may be L3 (or
> MPLS), and L2 liveliness would not be sufficient (after all, L2 can be
> working, while L3 might not or MPLS might not).
>
>     Cheers,
>     Rajiv
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Jul 2018 13:25:45 -0400

>     auto-discovery between 2 directly connected BGP neighbors
>     (referring to the topology shown yesterday)? Or is it really meant
>     to benefit the peering relationship (once established) - bring
>     down the peer if L2 fails or vice versa?

while i imagine it could be used for other things, bringing down L3
sesiosn when L2 goes down would seem a good idea.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Jul 2018 13:52:53 -0400

> Link Hello are proposed to detect the L2-L2.5-L3 liveness.

no.  only L2

you want above that, use bfd or whatever

randy

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 20 Jul 2018 18:07:03 +0000

Hi Acee,

Yes, indeed. 

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

> On Jul 20, 2018, at 1:02 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Rajiv,

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 20 Jul 2018 14:24:06 -0400

Randy,

I would also (re)stress that keeping it only to L2 detection allows it
to be simple and scoped only to what we absolutely need.  It seems
like the intersection (standards) approach you discussed.

regards,

Victor K (LSVR hat off)

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Jul 2018 14:25:54 -0400

hi victor,

> like the intersection (standards) approach you discussed.

'zactly

randy