Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

From: "Susan Hares" <[email-masked]>
Date: Mon, 2 Jul 2018 13:08:47 -0400

Greetings: 

This begins a 2 week WG adoption call for
draft-xu-idr-neighbor-autodiscovery (July 2 – July 16).  

https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/

The authors of this draft should send their IPR statements in response to
this email.  I hope the authors will ihelp their vacationing co-authors to
respond by July 7th.  

The WG should consider the following: 

1)      Does BGP need to have an autodiscovery mechanism for peers within
Data Centers? 

2)      Does this mechanism work for other deployments? 

3)      If so, should be passed in BGP Hello message?  

Or should it be a part of another protocol (e.g. LLDP, BFD, etc). 

4)      Does this interact with any of the LSVR work? 

I want to thank the authors for their patience while we sorted through some
of the WG LC for other drafts.  We decided to wait until some of those
discussion were cleared up prior to starting a new WG Adoption call.

Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 03 Jul 2018 09:03:20 +0800

Hi Sue,

I'm not aware of any IPR related to this draft.

Best regards,
Xiaohu
------------------------------------------------------------------
From:Susan Hares <[email-masked]>
Send Time:2018年7月3日(星期二) 01:08
To:idr <[email-masked]>
Cc:draft-xu-idr-neighbor-autodiscovery <[email-masked]>; 徐小虎(义先) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; aretana.ietf <[email-masked]>; John Scudder <[email-masked]>
Subject:WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings: 
This begins a 2 week WG adoption call for draft-xu-idr-neighbor-autodiscovery (July 2 – July 16).  
https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/
The authors of this draft should send their IPR statements in response to this email.  I hope the authors will ihelp their vacationing co-authors to respond by July 7th.  
The WG should consider the following: 
1) Does BGP need to have an autodiscovery mechanism for peers within Data Centers? 
2) Does this mechanism work for other deployments? 
3) If so, should be passed in BGP Hello message?  
Or should it be a part of another protocol (e.g. LLDP, BFD, etc). 
4) Does this interact with any of the LSVR work? 
I want to thank the authors for their patience while we sorted through some of the WG LC for other drafts.  We decided to wait until some of those discussion were cleared up prior to starting a new WG Adoption call.
Susan Hares

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 03 Jul 2018 13:18:12 -0700

Hi Sue,

I’m not aware of any IPR.

1) Yes

2) if BGP is not used for reachability distribution, I’d question use of BGP as the neighbor autodiscovery technology, however for all practical reasons, there’s significant number of DC’s todays that run BGP (Use of BGP for Routing in Large-Scale Data Centers, RFC 7938) seems to be a rather popular way to deploy undelay routing.

3) Yes, it could and should if BGP is used, using Hello message to convey the information needed is a technically sound approach, while using other protocols to do the same is definitely possible, additional complexity should not be underestimated 

4) it could be leveraged by the LSVR

Cheers,

Jeff

From: Susan Hares <[email-masked]>
Date: Monday, July 2, 2018 at 10:09
To: <[email-masked]>
Cc: <[email-masked]>, "'徐小虎' (义先)" <[email-masked]>, "'Ketan Talaulikar (ketant)'" <[email-masked]>, Alvaro Retana <[email-masked]>, 'John Scudder' <[email-masked]>
Subject: WG adoption call for draft-xu-idr-neighbor-autodiscovery
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Jeff Tantsura <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Mon, 2 Jul 2018 10:09:04 -0700 (PDT)

Greetings: 

The WG should consider the following: 
Does BGP need to have an autodiscovery mechanism for peers within Data Centers? 
Does this mechanism work for other deployments? 
 
If so, should be passed in BGP Hello message?  
Or should it be a part of another protocol (e.g. LLDP, BFD, etc). 

Does this interact with any of the LSVR work? 

 

Susan Hares

---

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

Hello,

I am not aware of any IPR related to this draft.

Thanks,
Ketan

From: Susan Hares <[email-masked]>
Sent: 02 July 2018 22:39
To: [email-masked]
Cc: [email-masked]; '徐小虎(义先)' <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; 'John Scudder' <[email-masked]>
Subject: WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 11 Jul 2018 09:11:29 +0800

Hi all,

I support the adoption as a coauthor.

The following is my answer to co-chair's questions:

Yes. it's needed in large-scale data centers where BGP is deployed as a underlay routing protocol.

Yes, it works for other deployments such as metro area networks where BGP is deployed as a underlay routing protocol as well.

Yes, it seems straightforward to extend BGP itself rather than extending other protocol to realize the BGP peer discovery purpose.
4)  Does this interact with any of the LSVR work?

Yes, this interact with the LSVR work. 

Best regards,
Xiaohu

Greetings:

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jul 2018 23:31:39 -0400

Sue,

> draft-xu-idr-neighbor-autodiscovery (July 2 – July 16).  

I'm supportive of IDR working on BGP auto-discovery.  This document may be a
good place to do it.

> Or should it be a part of another protocol (e.g. LLDP, BFD, etc). 

draft-acee-idr-lldp-peer-discovery covers a bit of this space.  (Xiaohu is
also a co-author on that document.)  The documents overlap strongly on core
features, and could use general reconciliation across their feature sets.

Speaking with my BFD co-chair hat on, BFD is likely not a good place for
this. :-)

-- Jeff

P.S. I suspect Yakov would be a bit amused that LDP hello reared its head in
a useful way in BGP.  Part of BGP-4 would have been avoided if it'd been
around.

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 11 Jul 2018 10:39:26 -0700

Hi Sue,

Support.

1) Yes
2) Yes, BGP is most commonly used in most DCs. However, it may have applications beyond that.
3) yes, in order to simplify operations for DCs. Single CP is needed.
4) it should be reviewed by LSVR WG.

Gaurav

> On Mon, Jul 2, 2018 at 10:08 AM, Susan Hares <[email-masked]> wrote:
> Greetings:
> 
>  
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Nikos Triantafillis <[email-masked]>
Date: Thu, 12 Jul 2018 00:24:17 +0300

Support.

Nikos.-

On Wed, Jul 11, 2018 at 8:39 PM, Gaurav Dawra <[email-masked]> wrote:

>> I want to thank the authors for their patience while we sorted through
>> some of the WG LC for other drafts.  We decided to wait until some of those

---

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

+1 and support as co-author.

Thanks,
Ketan

From: 徐小虎(义先) <[email-masked]>
Sent: 11 July 2018 06:41
To: Susan Hares <[email-masked]>; idr <[email-masked]>
Cc: draft-xu-idr-neighbor-autodiscovery <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; aretana.ietf <[email-masked]>; John Scudder <[email-masked]>
Subject: Re: WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi all,

Best regards,

Xiaohu
------------------------------------------------------------------
From:Susan Hares <[email-masked]<mailto:[email-masked]>>
Send Time:2018年7月3日(星期二) 01:08
To:idr <[email-masked]<mailto:[email-masked]>>
Cc:draft-xu-idr-neighbor-autodiscovery <[email-masked]<mailto:[email-masked]>>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; aretana.ietf <[email-masked]<mailto:[email-masked]>>; John Scudder <[email-masked]<mailto:[email-masked]>>
Subject:WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

Susan Hares

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Thu, 12 Jul 2018 02:08:08 +0000

Support as Contributor.

Thanks,
--Satya

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Monday, July 2, 2018 at 10:10 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

  1.  Does BGP need to have an autodiscovery mechanism for peers within Data Centers?
  2.  Does this mechanism work for other deployments?

  1.  If so, should be passed in BGP Hello message?

  1.  Does this interact with any of the LSVR work?

Susan Hares

---

From: ShaoWen Ma <[email-masked]>
Date: Thu, 12 Jul 2018 13:41:14 +0800

Support

Best Regards
Shaowen Ma

---

From: Gunter Van De Velde <[email-masked]>
Date: Thu, 12 Jul 2018 09:23:31 +0200

LSVR realises that there is need for a neighbour and liveliness detection mechanism, and is making effort to understand the particular LSVR requirements for a solution. 

From a very high level perspective, there are few ways to address the aspect of LSVR peer discovery and liveliness detection:
1) Create something new
2) Extend something existing
3) Re-use something existing

LSVR has no technology religion about any of these, and would like to progress with a solution space that most 
optimal answers the particular LSVR requirements. 

Within LSVR WG meeting at IETF102, there is time reserved to discuss about these matters, and if you feel interested, we could add this draft into the agenda?

Brgds,
G/

> On 11 Jul 2018, at 19:39, Gaurav Dawra <[email-masked]> wrote:
> 
> Hi Sue,
> 
> Support.
> 
> 1) Yes
> On Mon, Jul 2, 2018 at 10:08 AM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> Greetings:
> 
>  
> 
> https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/ <https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/>
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 12 Jul 2018 16:54:41 +0800

Hi Gunter, 

Thanks for your email and suggestion. I believe the BGP peer discovery mechanism as described in this draft is applicable to the use of BGP as IGP (https://tools.ietf.org/html/rfc7938) and LSVR as well. 

Ketan, one co-auhtor of this draft would present this draft on the LSVR session.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Gunter Van De Velde <guntervandeveldecc=[email-masked]>
Send Time:2018年7月12日(星期四) 15:24
To:Gaurav Dawra <[email-masked]>
Cc:idr wg <[email-masked]>; lsvr-chairs <[email-masked]>; draft-xu-idr-neighbor-autodiscovery <[email-masked]>; Susan Hares <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Brgds,
G/

Support.

1) Yes

Gaurav

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jul 2018 11:00:01 +0200

And that is precisely what IMHO we should avoid.

Clear separation from BGP global routing and BGP as IGP including LSVR is:

- extremely important for stability of the former
- very need for innovation and new features velocity of the latter

Thx,
R.

On Thu, Jul 12, 2018 at 10:54 AM, 徐小虎(义先) <[email-masked]>
wrote:

> Hi Gunter,
>
> Thanks for your email and suggestion. I believe the BGP peer discovery
> mechanism as described in this draft is applicable to the use of BGP as IGP
> (https://tools.ietf.org/html/rfc7938) and LSVR as well.
>
> Cc:idr wg <[email-masked]>; lsvr-chairs <[email-masked]>;
> draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-
> [email-masked]>; Susan Hares <[email-masked]>
> LSVR realises that there is need for a neighbour and liveliness detection
> mechanism, and is making effort to understand the particular LSVR
> requirements for a solution.
>
> From a very high level perspective, there are few ways to address the
> aspect of LSVR peer discovery and liveliness detection:
> 1) Create something new
> Within LSVR WG meeting at IETF102, there is time reserved to discuss about
> these matters, and if you feel interested, we could add this draft into the
> agenda?
>
> Brgds,
> G/
>
>
>
>
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 12 Jul 2018 17:06:05 +0800

Robert,

The mechanism as described in this draft is only targeted for the MSDC where RFC7938 has been enabled. It's absolutely not targeted for the global routing system:)

Best regards,
Xiaohu

------------------------------------------------------------------
From:Robert Raszuk <[email-masked]>
Send Time:2018年7月12日(星期四) 17:00
To:徐小虎(义先) <[email-masked]>
Cc:Idr <[email-masked]>; Gaurav Dawra <[email-masked]>; idr wg <[email-masked]>; lsvr-chairs <[email-masked]>; draft-xu-idr-neighbor-autodiscovery <[email-masked]>; Susan Hares <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Thx,
R.

On Thu, Jul 12, 2018 at 10:54 AM, 徐小虎(义先) <[email-masked]> wrote:

Hi Gunter, 

Best regards,
Xiaohu

Brgds,
G/

Support.

1) Yes

Gaurav

---

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

BGP code is a BGP code and regardless if this is running on a router in the
Internet or in the MSDC , regardless if it comes from vendor X, Y or Z it
is the same code base.

It is *BAD*  idea to now glue BGP code base with LSVR. And this is first
draft which attempts do so in a very subtle manner by proposing two TLVs.

If we allow this to go through (because of sympathy to "reuse existing"
approach) the consequences down the road will be rather ugly for all BGP
based worlds (Internet, MSDC, but also enterprises with internal routing,
users of L2 and L3VPN etc ...).

Thx,
R.

On Thu, Jul 12, 2018 at 11:06 AM, 徐小虎(义先) <[email-masked]>
wrote:

> Robert,
>
> The mechanism as described in this draft is only targeted for the
> MSDC where RFC7938 has been enabled. It's absolutely not targeted for the
> global routing system:)
>
> Best regards,
> Xiaohu
>
> Cc:Idr <[email-masked]>; Gaurav Dawra <[email-masked]>; idr
> wg <[email-masked]>; lsvr-chairs <[email-masked]>;

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 12 Jul 2018 17:32:59 +0800

What's LSVR in your mind? isn't it built on the existing BGP code base?

By the way, have you heard any interest on this mechanism from users of the L2/L3VPN?:)

Xiaohu

Send Time:2018年7月12日(星期四) 17:13

BGP code is a BGP code and regardless if this is running on a router in the Internet or in the MSDC , regardless if it comes from vendor X, Y or Z it is the same code base. 

It is *BAD*  idea to now glue BGP code base with LSVR. And this is first draft which attempts do so in a very subtle manner by proposing two TLVs. 

If we allow this to go through (because of sympathy to "reuse existing" approach) the consequences down the road will be rather ugly for all BGP based worlds (Internet, MSDC, but also enterprises with internal routing, users of L2 and L3VPN etc ...). 

Thx,
R.

On Thu, Jul 12, 2018 at 11:06 AM, 徐小虎(义先) <[email-masked]> wrote:

Robert,

Best regards,
Xiaohu

Thx,
R.

Best regards,
Xiaohu

Brgds,
G/

Support.

1) Yes

Gaurav

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jul 2018 11:58:47 +0200

> What's LSVR in your mind? isn't it built on the existing BGP code base?

​No. Please see LSVR charter​:

*The LSVR protocol is intended as a self-standing routing protocol even if
using existing BGP transport mechanisms and encodings, or if sharing the
same transport session with other existing BGP address families.  *

​Here we are proposing even tighter dependency ... information in BGP
Hellos to be critical element of LSVR operation. ​Today someone can very
easily move LSVR transport to say TI-BGP proposed separated at the port
level sessions.

But if you add even single hard attachment to BGP for LSVR like proposed
TLVs it will become a hard anchor.

> By the way, have you heard any interest on this mechanism from users of

​You missed ​it ... it was not about their interest in LSVR or BGP Hellos
... it was about their fear that something they do not need will impact
them due to bugs.

Cheers
R.

> BGP code is a BGP code and regardless if this is running on a router in
> the Internet or in the MSDC , regardless if it comes from vendor X, Y or Z
> it is the same code base.
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 12 Jul 2018 18:18:25 +0800

Robert,

Please see my response inline.

Send Time:2018年7月12日(星期四) 17:58

On Thu, Jul 12, 2018 at 11:32 AM, 徐小虎(义先) <[email-masked]> wrote:

No. Please see LSVR charter: 

The LSVR protocol is intended as a self-standing routing protocol even if using existing BGP transport mechanisms and encodings, or if sharing the same transport session with other existing BGP address families. 

Here we are proposing even tighter dependency ... information in BGP Hellos to be critical element of LSVR operation. Today someone can very easily move LSVR transport to say TI-BGP proposed separated at the port level sessions. 

[Xiaohu] Sorry that I don't much understand your points. Did you mean that some information in the BGP Hello messages should be removed? If so, I'm fully open to discuss with you about this.

But if you add even single hard attachment to BGP for LSVR like proposed TLVs it will become a hard anchor. 

You missed it ... it was not about their interest in LSVR or BGP Hellos ... it was about their fear that something they do not need will impact them due to bugs.

[Xiaohu] Oh, my god. Some BGP users don't need multicast in their networks, should we stop defining BGP extensions for multicast due to the fears of potential bugs?

Best regards,
Xiaohu

Cheers
R.

Xiaohu

Thx,
R.

Best regards,
Xiaohu

Thx,
R.

Best regards,
Xiaohu

Brgds,
G/

Support.

1) Yes

Gaurav

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jul 2018 14:27:05 +0200

Xiaohu,

Even most solid bag will break if you keep loading it with junk ....

Best,
R.

On Thu, Jul 12, 2018, 12:18 徐小虎(义先) <[email-masked]> wrote:

> draft-xu-idr-neighbor-autodiscovery <
> [email-masked]>; Susan Hares <
> [email-masked]>
> Here we are proposing even tighter dependency ... information in BGP
> Hellos to be critical element of LSVR operation. Today someone can very
> [Xiaohu] Sorry that I don't much understand your points. Did you mean that
> some information in the BGP Hello messages should be removed? If so, I'm
> fully open to discuss with you about this.
>
> You missed it ... it was not about their interest in LSVR or BGP Hellos
> [Xiaohu] Oh, my god. Some BGP users don't need multicast in their
> networks, should we stop defining BGP extensions for multicast due to the
> fears of potential bugs?
>
> Best regards,
> Xiaohu
>
>
> Cheers
> R.
>
>
>
>
>
> Xiaohu
>
> draft-xu-idr-neighbor-autodiscovery <
> [email-masked]>; Susan Hares <
> [email-masked]>
> draft-xu-idr-neighbor-autodiscovery <
> [email-masked]>; Susan Hares <
> [email-masked]>
> draft-xu-idr-neighbor-autodiscovery <
> [email-masked]>; Susan Hares <
> [email-masked]>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 12 Jul 2018 21:07:36 +0800

Robert,

It seems that such familiar argument has always existed since the multi-protocol capability was introduced into BGP:)

By the way, something which means junk for somebody may be valuables for somebody else.

Xiaohu

Send Time:2018年7月12日(星期四) 20:27

Xiaohu,

Best,
R.

Robert,

Best regards,
Xiaohu

Cheers
R.

Xiaohu

Thx,
R.

Best regards,
Xiaohu

Thx,
R.

Best regards,
Xiaohu

Brgds,
G/

Support.

1) Yes

Gaurav

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 12 Jul 2018 10:35:12 -0400

While I think a BGP neighbor auto-discovery protocol would be useful in 
certain scenarios, I don't think the WG should adopt this document at 
the current time.

There is so much overlap with the idr-lldp-peer-discovery draft that I 
don't see how the WG could adopt both of them.  The 
idr-neighbor-autodiscovery draft thus should not be adopted unless the 
intention is to reject the idr-lldp-peer discovery draft. Is that the 
intention?  I don't recall seeing much discussion comparing and 
contrasting the two.

For neighbor auto-discovery, I'd think that the biggest issue by far 
would be security.  All this draft really suggests about security is 
"don't use this in any environment where it is possible for the Hellos 
to be spoofed".   A somewhat more detailed set of applicability 
restrictions would seem to be warraned.

The draft does propose to use the Generalized TTL Security Mechanism on 
the BGP sessions established as a result of receiving Hellos, but 
doesn't seem to suggest using the GTSM on the Hellos themselves. Either 
way, whether GTSM actually provides any signficant amount of security 
would have to be examined.

Even if there's no need for security in DC networks, what will happen 
when someone uses this to auto-discover neighbors on, e.g., an EVPN 
Broadcast Domain or other overlay.  Also, someone will want to use 
scoped IP multicast to allow the Hellos go to several hops, in order to 
auto-discover multi-hop EBGP peers.  (Compare to Targeted LDP Hellos.)  
Are these possible use cases supposed to be prohibited?  How?  Is there 
even an analysis of DC networking security needs?

I'm a little surprised to see LDP Hellos held up as model of something 
that is proven to work well.  In LDP, the Hello stuff is really a major 
complication (one might even say "a big mess"), because you have both 
"Hello adjacencies" and "session adjacencies", and you have to handle 
all the possible interactions between them. At least the LDP Hello stuff 
is an integral part of the LDP state machine; this sort of relationship 
between state machines is not really discussed in the 
idr-neighbor-autodiscovery draft.

LDP Hellos are also a known security problem (especially, but not only, 
when targeted to non-neighboring nodes).  In fact Targeted LDP Hellos 
provide no value other than to create an attack vector. However, it is 
hard to remove the Targeted Hellos because the Hello mechanism is such 
an integral part of the LDP state machine.  We should make sure we don't 
drive BGP down the same road.

The competition between BGP keepalives and periodic Hellos for deciding 
whether to bring the session down is also a potential source of problems 
that needs to be discussed.

It is interesting that routes are automatically created due to receipt 
of Hellos.  But the talk of giving these routes a smaller admin distance 
than certain other routes is a bit scary.  Attempts to adjust the admin 
distance never seem to work quite right, and frequently have unintended 
side-effects.  Also, there's very little protection against having 
several mechanisms that each create routes under the assumption that 
their own routes will have a smaller admin distance than any other.

I'm surprised to see the Hellos carrying a list of ASNs from which the 
transmitter will accept connections.  Isn't that a little like saying "I 
won't let you log in unless you type one of the following passwords"?

Something needs to be said about interaction with existing BGP security 
measures (TCP-MD5), such as they are.

> 1) Does BGP need to have an autodiscovery mechanism for peers within Data 
Centers?

An autodiscovery mechanism certainly seems useful.  However, its use 
needs to be carefully restricted, and the applicability restrictions 
needs to be very clearly stated.

 > 2) Does this mechanism work for other deployments?

Unknown.  It's somewhat surprising that this issue is not even addressed 
in the draft.

 >3) If so, should be passed in BGP Hello message?  Or should it be a 
part of another protocol (e.g. LLDP, BFD, etc).

Unknown.  It's somewhat surprising that this issue is not even addressed 
in the draft.

BTW, it's not at all clear whether the "BGP Hello" mechanism can be 
regarded as part of the BGP protocol.  It seems like a brand new 
UDP-based mechanism, and adding it doesn't seem to be any simpler than 
adding a more generic neighbor discovery protocol.

In the DC, one could also ask whether whatever procedure is used to tell 
a node what its IP address is should not also be used to tell it who its 
BGP neighbors are.

 > 4)Does this interact with any of the LSVR work?

Unknown.  It's somewhat surprising that this issue is not even addressed 
in the draft.

I think more work needs to be done on the draft before we can really 
evaluate whether it is a good basis for future work.

---

From: "Krishna Muddenahally Ananthamurthy (kriswamy)" <[email-masked]>
Date: Thu, 12 Jul 2018 17:32:55 +0000

I support for WG adoption.

Thanks
Kris

Date: Monday, July 2, 2018 at 10:09 AM

Greetings:

Susan Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Jul 2018 16:03:03 -0400

On Thu, Jul 12, 2018 at 10:35:12AM -0400, Eric C Rosen wrote:
> There is so much overlap with the idr-lldp-peer-discovery draft that
> I don't see how the WG could adopt both of them.  The
> idr-neighbor-autodiscovery draft thus should not be adopted unless
> the intention is to reject the idr-lldp-peer discovery draft. Is
> that the intention?  I don't recall seeing much discussion comparing
> and contrasting the two.

And not contradicting any of Eric's other good points, we have other work
happening outside of IDR that overlaps this auto discovery problem space:

https://datatracker.ietf.org/doc/draft-acee-ospf-bgp-rr/

Easy to say that it's a popular topic. :-)

-- Jeff

---

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

Very good point Jeff - thx for bringing this one up too in this context.

One thing however in this entire thread is very blurry and mixed line
between what is useful for BGP itself and what is specifically useful for
the cases of BGP deployments in MSDCs.

The fundamental reason why Petr shared the idea of using BGP in large scale
DCs was redundant flooding reduction of native link state protocols as well
as lowest common denominator across OEM vendors supporting high speed L3
switches/routers for DC fabric.

With that let's face it .. there is perhaps only handful of MSDCs in the
world which technically still needs to use BGP as dynamic reachability
protocol. Rest of them would be much better using either:

* native link state protocols possibly with proposed by Tony Li flooding
reduction
* native link state protocols possibly with proposed by Naiming flooding
optimizations for DCs
* Russ's proposal for ISIS in openfabric
* (apologies if I missed any other work here)

and for those really brave:

* run RIFT

If folks having 10 or 100 or 1000 nodes in the spine of their DCs don't
want to feel any smaller the FB or MS or Amazon I think they are just fine
to either run BGP as is or be most advanced and support fork of BGP to be
focused on DCs - call it DC-BGP which would run different code base then
real WAN BGP optimized for small and medium data centers fabrics and would
includ use of different TCP ports. LSVR could be placed in that category.

Thx,
R.

PS, Most of configuration tasks in any well operated network is all
automated. I am missing the real practical need for any auto-configuration
or auto-discovery enhancements for real data centers where provisioning
tool is in place. Is this for Wild Wild West type of fabrics where spine or
super spine or TORs get mounted and connected at random then someone
expects that turning it on is all what is needed to improve the fabric's
bandwidth ?

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 12 Jul 2018 15:00:08 -0700

> and for those really brave:
You probably meant to say "for those who actually want to be able to run
something that exists". For people interested in code I can encourage
hackathon102 participation. We're aiming to got a first interop hello 3-way
up and probably ZTP :-P

Gee, that used to be all "rough consensus and running code". One got
definitiely more contentious and the other gets harder and harder to find
these days ...

Otherwise, on the issue, unsurprisingly, I fully concur with Eric,
especially it maybe quite enlightening to go through a small exercise of
trying to extend the BGP neighbor FSM with the suggested change  ...

thanks

--- tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Jul 2018 00:09:56 +0200

Hey Tony,

Honestly and in the public I do want to state that if given a choice of
keep "enhancing" real BGP focusing on DCs vs running RIFT the latter wins
without any doubt.

As long as RIFT is solid and available to run on most of the OEM vendors
and is supported in any common white box operating systems other then code
maturity I would not see any issues to run it for most DCs that really need
such optimal dynamic routing.

Thx,
R.

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 12 Jul 2018 15:31:09 -0700

> keep "enhancing" real BGP focusing on DCs vs running RIFT the latter wins
First, you saw that my message (as often) was tongue in cheek ;-)

And what you wrote is a somewhat suprising,  interesting (and probably
quite sane ;-) take from you ...

> such optimal dynamic routing.
well, code you can download today publicly from a reputable vendor ;-) runs
on Linux & OSX ;-) so you can imagine lots of stuff is quite easily
possible ;-)

Leaf version is not as eye-wateringly trivial as Babel but very easy for
link-state (unless you run a really poor fabric where you may end up with
lots of disaggregation all the time, that's something no protocol will fix
for you) and we see what comes out the hackathon but I would venture a
public domain python for a small fanout switch or server could do just
fine, maybe with a bit of Cython thrown in ... So I think it's very
approachable contrary to building a full fledged link-state @ high perf
which as we know is a bit of a arcane martial art ;-)

Have a peek @ https://github.com/brunorijsman/rift-fsm otherwise ...

Maturity is always an issue but thankfully the problem is far more
constrained than generic problem @ very large scale like ISIS solved. The
sooner people start to soak it, the better we'll be off ... And to your
point, if you have a very mature, very scalable codebase that you start to
"enhance for the better for a use-case orthgonally opposed to original
protocol design" you may likely end up with a much more interesting problem
of possibly kicking over lots deployed, happy folks. You have much more
experience there than I'll ever care to have ...

And per my perception the selling point of RIFT isn't really "optimal"
[whichever optimal we mean here] in first place but zero OPEX, that's the
real problem most organizations are solving building fabrics (that I see)
rather than the few industry giants equiped with almost infinite resources
and belaguered by hoards of candidates looking for employment ;-)

well, I don't mean to hijack the thread and did enough promotional plugin
and we do have a list so before the IDR chairs go after me, I'm out ;-)

--- tony

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 12 Jul 2018 18:59:14 -0700

Run RIFT it is!!!
 (Sorry, I’m biased ;-))
From my personal experience - most mid size guys are either running BGP in the underlay already or looking forward to moving to it.
They do need AD functionality, and the proposal being discussed is trying to provide  the solution.

Regards,
Jeff

> On Jul 12, 2018, at 14:34, Robert Raszuk <[email-masked]> wrote:
> 
> 
> One thing however in this entire thread is very blurry and mixed line between what is useful for BGP itself and what is specifically useful for the cases of BGP deployments in MSDCs. 
> 
> The fundamental reason why Petr shared the idea of using BGP in large scale DCs was redundant flooding reduction of native link state protocols as well as lowest common denominator across OEM vendors supporting high speed L3 switches/routers for DC fabric. 
> 
> With that let's face it .. there is perhaps only handful of MSDCs in the world which technically still needs to use BGP as dynamic reachability protocol. Rest of them would be much better using either: 
> 
> * native link state protocols possibly with proposed by Tony Li flooding reduction
> * native link state protocols possibly with proposed by Naiming flooding optimizations for DCs
> If folks having 10 or 100 or 1000 nodes in the spine of their DCs don't want to feel any smaller the FB or MS or Amazon I think they are just fine to either run BGP as is or be most advanced and support fork of BGP to be focused on DCs - call it DC-BGP which would run different code base then real WAN BGP optimized for small and medium data centers fabrics and would includ use of different TCP ports. LSVR could be placed in that category. 
> 
> Thx,
> R.
> 
> PS, Most of configuration tasks in any well operated network is all automated. I am missing the real practical need for any auto-configuration or auto-discovery enhancements for real data centers where provisioning tool is in place. Is this for Wild Wild West type of fabrics where spine or super spine or TORs get mounted and connected at random then someone expects that turning it on is all what is needed to improve the fabric's bandwidth ? 
> 
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 13 Jul 2018 10:04:08 +0800

Occur with Jeff. there are still many MSDCs which will continue to use RFC7938 for a long while. BGP neighbor discovery mechanism is a needed feature in that case.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Jeff Tantsura <[email-masked]>
Send Time:2018年7月13日(星期五) 09:59
To:Robert Raszuk <[email-masked]>
Cc:Jeffrey Haas <[email-masked]>; Eric C Rosen <[email-masked]>; idr wg <[email-masked]>; draft-xu-idr-neighbor-autodiscovery <[email-masked]>; Susan Hares <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Run RIFT it is!!!
 (Sorry, I’m biased ;-))

Regards,
Jeff

* run RIFT

Thx,
R.

 -- Jeff

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 13 Jul 2018 02:08:21 +0000

Hi Eric,

Thanks a lot for your feedback and inputs. Will work with co-authors on addressing the points you raised below – many of them should be clarified by updates which are already in progress.

Regarding the overlap with draft-acee-idr-lldp-peer-discovery, I agree that there needs to be discussion between adopting one of these two drafts.

Thanks,
Ketan

From: Eric C Rosen <[email-masked]>
Sent: 12 July 2018 20:05
To: Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

While I think a BGP neighbor auto-discovery protocol would be useful in certain scenarios, I don't think the WG should adopt this document at the current time.

There is so much overlap with the idr-lldp-peer-discovery draft that I don't see how the WG could adopt both of them.  The idr-neighbor-autodiscovery draft thus should not be adopted unless the intention is to reject the idr-lldp-peer discovery draft. Is that the intention?  I don't recall seeing much discussion comparing and contrasting the two.

For neighbor auto-discovery, I'd think that the biggest issue by far would be security.  All this draft really suggests about security is "don't use this in any environment where it is possible for the Hellos to be spoofed".   A somewhat more detailed set of applicability restrictions would seem to be warraned.

The draft does propose to use the Generalized TTL Security Mechanism on the BGP sessions established as a result of receiving Hellos, but doesn't seem to suggest using the GTSM on the Hellos themselves.  Either way, whether GTSM actually provides any signficant amount of security would have to be examined.

Even if there's no need for security in DC networks, what will happen when someone uses this to auto-discover neighbors on, e.g., an EVPN Broadcast Domain or other overlay.  Also, someone will want to use scoped IP multicast to allow the Hellos go to several hops, in order to auto-discover multi-hop EBGP peers.  (Compare to Targeted LDP Hellos.)  Are these possible use cases supposed to be prohibited?  How?  Is there even an analysis of DC networking security needs?

I'm a little surprised to see LDP Hellos held up as model of something that is proven to work well.  In LDP, the Hello stuff is really a major complication (one might even say "a big mess"), because you have both "Hello adjacencies" and "session adjacencies", and you have to handle all the possible interactions between them.  At least the LDP Hello stuff is an integral part of the LDP state machine; this sort of relationship between state machines is not really discussed in the idr-neighbor-autodiscovery draft.

LDP Hellos are also a known security problem (especially, but not only, when targeted to non-neighboring nodes).  In fact Targeted LDP Hellos provide no value other than to create an attack vector.  However, it is hard to remove the Targeted Hellos because the Hello mechanism is such an integral part of the LDP state machine.  We should make sure we don't drive BGP down the same road.

The competition between BGP keepalives and periodic Hellos for deciding whether to bring the session down is also a potential source of problems that needs to be discussed.

It is interesting that routes are automatically created due to receipt of Hellos.  But the talk of giving these routes a smaller admin distance than certain other routes is a bit scary.  Attempts to adjust the admin distance never seem to work quite right, and frequently have unintended side-effects.  Also, there's very little protection against having several mechanisms that each create routes under the assumption that their own routes will have a smaller admin distance than any other.

I'm surprised to see the Hellos carrying a list of ASNs from which the transmitter will accept connections.  Isn't that a little like saying "I won't let you log in unless you type one of the following passwords"?

Something needs to be said about interaction with existing BGP security measures (TCP-MD5), such as they are.

> 1) Does BGP need to have an autodiscovery mechanism for peers within Data Centers?

An autodiscovery mechanism certainly seems useful.  However, its use needs to be carefully restricted, and the applicability restrictions needs to be very clearly stated.

> 2) Does this mechanism work for other deployments?

Unknown.  It's somewhat surprising that this issue is not even addressed in the draft.

> 3)  If so, should be passed in BGP Hello message?  Or should it be a part of another protocol (e.g. LLDP, BFD, etc).

Unknown.  It's somewhat surprising that this issue is not even addressed in the draft.

BTW, it's not at all clear whether the "BGP Hello" mechanism can be regarded as part of the BGP protocol.  It seems like a brand new UDP-based mechanism, and adding it doesn't seem to be any simpler than adding a more generic neighbor discovery protocol.

In the DC, one could also ask whether whatever procedure is used to tell a node what its IP address is should not also be used to tell it who its BGP  neighbors are.

> 4)   Does this interact with any of the LSVR work?

Unknown.  It's somewhat surprising that this issue is not even addressed in the draft.

I think more work needs to be done on the draft before we can really evaluate whether it is a good basis for future work.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 13 Jul 2018 10:18:00 +0800

Hi Eric,

Thanks a lot for your detailed comments. 

If I understood it correctly, there was an obvious preference of the BGP-based approach over the LLDP-based approach in the IDR community when those two drafts were presented at the past several IETF meetings. Most importantly, co-authors of the latter had realized the shortages associated with the latter and decided to stop that draft.

Anyway, it's just a WG adoption call rather than a WG LC. I believe that the IDR WG and even the security Area has enough time and ability to help address the security concerns raised by you.

Best regards,
Xiaohu  
------------------------------------------------------------------
From:Eric C Rosen <[email-masked]>
Send Time:2018年7月12日(星期四) 23:33
To:Susan Hares <[email-masked]>; idr <[email-masked]>
Cc:draft-xu-idr-neighbor-autodiscovery <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 13 Jul 2018 10:57:31 +0800

Hi Jeff,

Thanks for pointing out that draft. Yes, it's a popular topic indeed :)

I just have a glance at that draft. If I understand it correctly, it was intended to advertise RRs' capabilities and therefore it should be designed for the iBGP scenario.

It seems that RFC7938 recommended to use eBGP rather than iBGP as an IGP within MSDCs (see below). In fact, many MSDCs do follow the EBGP-only design recommendations of RFC7938, AFAIK. The BGP neighbor auto-discovery mechanism as described in draft-xu-idr-neighbor-autodiscovery is applicable to those MSDCs which follows the recommendations of RFC7938.

5.1.  Choosing EBGP as the Routing Protocol

   REQ2 would give preference to the selection of a single routing
   protocol to reduce complexity and interdependencies.  While it is
   common to rely on an IGP in this situation, sometimes with either the
   addition of EBGP at the device bordering the WAN or Internal BGP
   (IBGP) throughout, this document proposes the use of an EBGP-only
   design.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Jeffrey Haas <[email-masked]>
Send Time:2018年7月13日(星期五) 04:03
To:Eric C Rosen <[email-masked]>
Cc:Susan Hares <[email-masked]>; idr <[email-masked]>; draft-xu-idr-neighbor-autodiscovery <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

-- Jeff

---

From: Mach Chen <[email-masked]>
Date: Fri, 13 Jul 2018 03:22:57 +0000

Hi Sue,

I have read the draft and think it's valuable,  support the adoption of it.

Best regards,
Mach

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, July 03, 2018 1:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

This begins a 2 week WG adoption call for draft-xu-idr-neighbor-autodiscovery (July 2 - July 16).

Susan Hares

---

From: Gaurav Dawra <[email-masked]>
Date: Thu, 12 Jul 2018 22:03:09 -0700

Hi,

While I think having a BGP neighbor auto-discovery protocol would be useful
in DCs.
There is a potential scaling issue to process hello messages as a number of
BGP sessions scale increases.
Proper handling of proposed hello messages needs to be addressed first.

Cheers,

Gaurav

---

From: Keyur Patel <[email-masked]>
Date: Fri, 13 Jul 2018 05:44:08 +0000

Hi Sue,

While I think the BGP discovery work is import, I don’t think WG should adopt this document at this time.  My answers are further inlined #Keyur.

Date: Monday, July 2, 2018 at 11:10 AM

Greetings:

#Keyur: Yes.

  1.  Does this mechanism work for other deployments?

#Keyur: Yes.

#Keyur:  It should not be included in BGP (or any BGP Hello messages).  Any such mechanism within BGP  will 1) conflict with existing keepalives and 2) impose scale issues when it comes to supporting large number of BGP peers.

                My suggestion is to implement discovery mechanism outside BGP.

#Keyur: Yes it does.

Regards,
Keyur

Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 13 Jul 2018 14:35:26 +0800

Hi Keyur,

Thanks for your comments. 

For 1), the BGP hello message is used to form Hello adjacency which is different from the BGP adjacency. if it's the following text that causes your concern , we could consider to remove that completely. Anyway, the keep alive timer will expire sooner or latter once there is no Hello adjacency. Does it make sense for you? 

"When the last Hello adjacency for an BGP session is deleted, the BGP peer terminates the BGP session and closing the transport connection."

For 2), if you are concerned about the scaling issue, you are allowed to set the BGP hello timer properly. IMHO, it's a common tradeoff for any peer auto-discovery protocol.

BTW, what makes you believe that the BGP Hello message is within BGP or included in BGP?:)

Best regards,
Xiaohu

---

From: Keyur Patel <[email-masked]>
Date: Fri, 13 Jul 2018 07:12:03 +0000

Hi Xiaohu,

Comments are inlined #Keyur

From: "徐小虎(义先)" <[email-masked]>
Reply-To: "徐小虎(义先)" <[email-masked]>
Date: Friday, July 13, 2018 at 12:35 AM
To: Keyur Patel <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Keyur,

#Keyur: IMHO, the hello adjacency is already present in BGP in form of Keepalives! 😊 We also have BFD to assist fast fail over. 😊 We don’t need  an adjacency setup. We need autodiscovery (stateless if possible)! 😊

#Keyur:  I am not so sure.  Is BGP supposed to track neighbor uptime using hello adjacency and keepalives?

#Keyur: But there will be  more heatbeat + Keepalive messages (on a per session basis) than needed for all BGP neighbors. 😊 that’s the scaling issue.

#Keyur: Then why do it with a BGP (hello) instead of a generic protocol like LLDP

Regards,
Keyur

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Jul 2018 09:18:22 +0200

> BTW, what makes you believe that the BGP Hello message is within BGP or

​Because the proposal is for IDR WG and is being asked for adoption by IDR
WG.

If you move the proposal to RTGWG and not recommend using UDP port 179 I
think it may go smooth as is.

Thx,
R.​

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2018 10:11:49 -0400

a lot of discovery of discovery.  can we get three deep?  :)

seems to me that this partiular approach brings all the chattiness and
scalability problems of igps (which, for example tli is working on) into
bgp.  this may not be a good thing.

randy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 Jul 2018 14:13:26 +0000

Hi Sue, et al,

I don’t think we should settle on this auto-discovery mechanism at this point just because they were the first to ask for adoption.  There are trade-offs  for the various auto-discovery techniques as mentioned in the thread.

Thanks,
Acee

From: Idr <[email-masked]> on behalf of Keyur Patel <[email-masked]>
Date: Friday, July 13, 2018 at 1:44 AM
To: Susan Hares <[email-masked]>, IDR List <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Sue,

Greetings:

#Keyur: Yes.

#Keyur: Yes.

Regards,
Keyur

Susan Hares

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2018 10:34:28 -0400

> I don’t think we should settle on this auto-discovery mechanism at
> this point just because they were the first to ask for adoption.
> There are trade-offs for the various auto-discovery techniques as
> mentioned in the thread.

someone should do a presentation on the dimensions and desiderata in
this space.  maybe schedule it in lsvr.  oh, wait

randy

---

From: John E Drake <[email-masked]>
Date: Fri, 13 Jul 2018 15:05:06 +0000

Hi,

I agree w/ Acee.

Yours Irrespectively,

John

From: Idr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Friday, July 13, 2018 10:13 AM
To: Keyur Patel <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Sue, et al,

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Keyur Patel <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 13, 2018 at 1:44 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Sue,

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 2, 2018 at 11:10 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxu-2Didr-2Dneighbor-2Dautodiscovery_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=USgmyLsyfAswdko9jrmcZSNJjbNrGSg_uAoKrq8hLFs&s=Vc-yzGAGvrxhuu_vajnvNrQTgx6aeEevkiSnG8I22ik&e=>

#Keyur: Yes.

#Keyur: Yes.

Regards,
Keyur

Susan Hares

---

From: Gunter Van De Velde <[email-masked]>
Date: Fri, 13 Jul 2018 19:19:59 +0200

+1

Next week LSVR WG will have a discussion detailing auto-discovery problem-space/requirements. 
Properties as e.g. scaling, simplicity and generic usability are taken into consideration.

imo it seems too early to adopt/settle on a solution, while we have options available ("create something new", "augment something existing" or "reuse something existing")

G/

> On 13 Jul 2018, at 16:13, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> Hi Sue, et al, 
>  
> From: Idr <[email-masked] <mailto:[email-masked]>> on behalf of Keyur Patel <[email-masked] <mailto:[email-masked]>>
> To: Susan Hares <[email-masked] <mailto:[email-masked]>>, IDR List <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: Idr <[email-masked] <mailto:[email-masked]>> on behalf of Susan Hares <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Greetings: <>

---

From: Nikos Triantafillis <[email-masked]>
Date: Fri, 13 Jul 2018 21:16:38 +0300

Responses inline marked #NT

On Fri, Jul 13, 2018 at 8:44 AM, Keyur Patel <[email-masked]> wrote:

> Hi Sue,
>
>
>
> While I think the BGP discovery work is import, I don’t think WG should
> adopt this document at this time.  My answers are further inlined #Keyur.
>
>
>
> *From: *Idr <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date: *Monday, July 2, 2018 at 11:10 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>
> *Subject: *[Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery
>
>
>
> Greetings:
>
>
>
> #Keyur:  It should not be included in BGP (or any BGP Hello messages).
> Any such mechanism within BGP  will 1) conflict with existing keepalives
> and 2) impose scale issues when it comes to supporting large number of BGP
> peers.
>

#NT: Regarding (1) the draft will address this in the next update. (2) is
simply not true :-)

>                 My suggestion is to implement discovery mechanism outside

#NT: This is restrictive and requires those running only BGP, to run yet
another mechanism/protocol IMO needlessly. The added complexity is
certainly not desirable by operators either.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Jul 2018 20:59:11 +0200

Hey Nikos,

#NT: This is restrictive and requires those running only BGP, to run yet
another mechanism/protocol IMO needlessly

When you are designing a data center there is much much more then BGP for
underlay you need to worry about. The choice of what protocol to use from
TORs towards compute nodes and from TORs towards the spine or how to
exchange reachability between spines is just white noise at most (if you
seriously looking at complete data center design).

Then there is orchestration layer to manage the compute or storage
infrastructure etc ... Some DCs use overlays some use only flat host routes
in the underlay etc .. Then there are those DCs still running a lot of
native multicast with expectations to move to BIER soon etc ... So let's
not use such arguments of "single protocol" for DC as this is just not
correct if you consider the full DC architecture.

- - -

Back to your proposal - the way I read it nothing prevents me today to
blasts the BGP Hellos over logical interfaces for any AFI/SAFI you like as
far as I like - correct ? Eric pointed this out as well yesterday. Is that
intentional or accidental? Also can multicast address from "all routes on
the subnet" be modified by the implementation to any other multicast
address ? If so then you can discover bunch of other cool things in your
multicast domain - all with BGP !

Btw in number of deployments UDP is blocked in the fabric or on TORs by
ACLs at the interface level. So to make sure this works folks need to punch
wholes in the ACLs.

Last it is often the case today - when running no overlay - to advertise
dynamically VMs or LXCs addresses to TORs via routing protocol - say BGP.
What happens when now the LXCs or VMs will start sending such BGP Hellos
directly to TORs ? Do you envision that this proposal will automatically
establish BGP sessions with those tenant entities if they happen to be on
the same subnet then compute node itself ?

Bottom line is that we do not know really what complete set of
functionality (both intended and accidental) are we having the WG
acceptance call for. The document is missing so much text that at this
stage IMO it is not eligible for any IETF WG adoption pool.

Thx,
R.

---

From: Nikos Triantafillis <[email-masked]>
Date: Fri, 13 Jul 2018 22:39:03 +0300

Inline marked #NT.

> seriously looking at complete data center design).

#NT: A lot of data centers don't run a protocol from ToRs towards compute
nodes. The DC world comes in many flavors ;-)

> correct if you consider the full DC architecture.

#NT: Please read more carefully what I wrote. I didn't make such a blanket
statement of "single protocol" for all DCs as you are making out my
statement to be:-)  Also, if you have DC architecture examples where the
proposed mechanism fails or is not sufficient, then we should discuss.

> multicast domain - all with BGP !

#NT: Agreed, Eric made some valid points. The draft needs work to spell out
what the intention is in areas of concern and we will do that.

> ACLs at the interface level. So to make sure this works folks need to punch

#NT: IMO this is irrelevant in the context of the draft. It's an
operational issue for those specific deployments and a much simpler one to
address than asking someone to run yet another protocol if the
functionality could be provided by enhancing the existing one they run.
That's my take on that.

> the same subnet then compute node itself ?

#NT: Do you need to enable such functionality on the VMs or LXCs?

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Jul 2018 21:54:41 +0200

> ​> ​
> The draft needs work to spell out what the intention is in areas of
> concern and we will do that.
>

​I don't think this is only about spelling out intentions. It is more about
adding actual mechanisms to prevent not intended by authors accidental use
cases.

​

> functionality could be provided by enhancing the existing one they run.

​Sure you can do that. But perhaps someone could just explain what is so
difficult in configuring your TORs and SPINEs with provisioning tool ? Why
in DC there is need for this automation in BGP ?

Besides if you plan your addressing in the fabric correctly the peering
addresses to use both on direct p2p EBGP sessions or between loopbacks
(including resolving connected routes) can be all easily automated today
without single hello message exchanged.

The BGP Hellos may help those who randomly assign fabric address plan - but
is this really something we need to spend IDR WG time on ?

As stated in vast majority of DC fabrics there is no need for BGP at all,
but if there is group of folks who think otherwise why not to just
carve-out what is necessary for DC-BGP from BGP, write it up in new RFC as
new protocol and deal with it in DC dedicated WGs ?

Thx,
R.

---

From: Abhay Roy <[email-masked]>
Date: Fri, 13 Jul 2018 22:13:23 +0000

+1

I do see it getting a lot of discussion time next week in LSVR agenda:

https://datatracker.ietf.org/meeting/102/materials/agenda-102-lsvr-02

(The subject doc is also on the agenda)

So will vote to wait just a little bit more before deciding the path forward on auto-discovery approach.

Regards,
-Abhay

On Jul 13, 2018, at 10:19 AM, Gunter Van De Velde <guntervandeveldecc=[email-masked]<mailto:guntervandeveldecc=[email-masked]>> wrote:

+1

G/

On 13 Jul 2018, at 16:13, Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>> wrote:

Hi Sue, et al,

Thanks,
Acee

Hi Sue,

Greetings:

#Keyur: Yes.

#Keyur: Yes.

Regards,
Keyur

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

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

---

From: Ahmed Bashandy <[email-masked]>
Date: Fri, 13 Jul 2018 15:17:50 -0700

I concur.

I think we should wait few days for face-to-face meetings

Ahmed

On 7/13/18 3:13 PM, Abhay Roy wrote:
>> On Jul 13, 2018, at 10:19 AM, Gunter Van De Velde 
>> <guntervandeveldecc=[email-masked] 
>> <mailto:guntervandeveldecc=[email-masked]>> wrote:
>>
>> +1
>>
>> imo it seems too early to adopt/settle on a solution, while we have 
>> options available ("create something new", "augment something 
>> existing" or "reuse something existing")
>>
>> G/
>>
>>
>>
>>> On 13 Jul 2018, at 16:13, Acee Lindem (acee) 
>>> <acee=[email-masked] 
>>> <mailto:acee=[email-masked]>> wrote:
>>>
>>> Hi Sue, et al,
>>> *From:*Idr <[email-masked] <mailto:[email-masked]>> on 
>>> behalf of Keyur Patel <[email-masked] <mailto:[email-masked]>>
>>> *Date:*Friday, July 13, 2018 at 1:44 AM
>>> *To:*Susan Hares <[email-masked] <mailto:[email-masked]>>, IDR 
>>> List <[email-masked] <mailto:[email-masked]>>
>>> *Cc:*"[email-masked] 
>>> <mailto:[email-masked]>" 
>>> <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Subject:*Re: [Idr] WG adoption call for 
>>> draft-xu-idr-neighbor-autodiscovery
>>> Hi Sue,
>>> While I think the BGP discovery work is import, I don’t think WG 
>>> should adopt this document at this time.  My answers are further 
>>> inlined #Keyur.
>>> *From:*Idr <[email-masked] <mailto:[email-masked]>> on 
>>> behalf of Susan Hares <[email-masked] <mailto:[email-masked]>>
>>> *Date:*Monday, July 2, 2018 at 11:10 AM
>>> *To:*"[email-masked] <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Cc:*"[email-masked] 
>>> <mailto:[email-masked]>" 
>>> <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Subject:*[Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery
>>> Greetings:
>>> The authors of this draft should send their IPR statements in 
>>> response to this email.  I hope the authors will ihelp their 
>>> vacationing co-authors to respond by July 7^th .
>>> 1)Does BGP need to have an autodiscovery mechanism for peers within 
>>> Data Centers?
>>> #Keyur: Yes.
>>> 2)Does this mechanism work for other deployments?
>>> #Keyur: Yes.
>>> 3)If so, should be passed in BGP Hello message?
>>> #Keyur:  It should not be included in BGP (or any BGP Hello 
>>> messages).  Any such mechanism within BGP will 1) conflict with 
>>> existing keepalives and 2) impose scale issues when it comes to 
>>> supporting large number of BGP peers.
>>> I want to thank the authors for their patience while we sorted 
>>> through some of the WG LC for other drafts.  We decided to wait 
>>> until some of those discussion were cleared up prior to starting a 
>>> new WG Adoption call.
>>> Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Sat, 14 Jul 2018 09:08:20 +0800

Fully agree with Nikos' opinions. The DC world comes in many flavors, I believe the coauthors and contributors of this draft from MSDC operators know well about what they really need.

The BGP neighbor auto-discovery mechanism as described in this draft is mainly intended for the MSDCs following the eBGP-only design as recommended by RFC7938. This eBGP-only design will be kept for a long period of time unless they saw a STRONG and REAL benefit of deploying link-state protocols. Therefore, it's worthwhile to enhance the automation and simplification in the deployment of the eBGP-only MSDC fabric.

It may be useful to consider the applicability in the LSVR provided LSVR had a chance to be widely deployed in future even though there has been many link-state protocol proposals for MSDC CLOS networks which are either built on the proven IS-IS/OSPF protocols or built on totally-new designs for wider purposes.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Nikos Triantafillis <[email-masked]>
Send Time:2018年7月14日(星期六) 03:39
To:Robert Raszuk <[email-masked]>
Cc:Keyur Patel <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Susan Hares <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Inline marked #NT.

Hey Nikos,

#NT: This is restrictive and requires those running only BGP, to run yet another mechanism/protocol IMO needlessly
When you are designing a data center there is much much more then BGP for underlay you need to worry about. The choice of what protocol to use from TORs towards compute nodes and from TORs towards the spine or how to exchange reachability between spines is just white noise at most (if you seriously looking at complete data center design). 

#NT: A lot of data centers don't run a protocol from ToRs towards compute nodes. The DC world comes in many flavors ;-)

Then there is orchestration layer to manage the compute or storage infrastructure etc ... Some DCs use overlays some use only flat host routes in the underlay etc .. Then there are those DCs still running a lot of native multicast with expectations to move to BIER soon etc ... So let's not use such arguments of "single protocol" for DC as this is just not correct if you consider the full DC architecture. 

#NT: Please read more carefully what I wrote. I didn't make such a blanket statement of "single protocol" for all DCs as you are making out my statement to be:-)  Also, if you have DC architecture examples where the proposed mechanism fails or is not sufficient, then we should discuss.

- - - 

Back to your proposal - the way I read it nothing prevents me today to blasts the BGP Hellos over logical interfaces for any AFI/SAFI you like as far as I like - correct ? Eric pointed this out as well yesterday. Is that intentional or accidental? Also can multicast address from "all routes on the subnet" be modified by the implementation to any other multicast address ? If so then you can discover bunch of other cool things in your multicast domain - all with BGP ! 

#NT: Agreed, Eric made some valid points. The draft needs work to spell out what the intention is in areas of concern and we will do that.

Btw in number of deployments UDP is blocked in the fabric or on TORs by ACLs at the interface level. So to make sure this works folks need to punch wholes in the ACLs. 

#NT: IMO this is irrelevant in the context of the draft. It's an operational issue for those specific deployments and a much simpler one to address than asking someone to run yet another protocol if the functionality could be provided by enhancing the existing one they run. That's my take on that.

Last it is often the case today - when running no overlay - to advertise dynamically VMs or LXCs addresses to TORs via routing protocol - say BGP. What happens when now the LXCs or VMs will start sending such BGP Hellos directly to TORs ? Do you envision that this proposal will automatically establish BGP sessions with those tenant entities if they happen to be on the same subnet then compute node itself ? 

Bottom line is that we do not know really what complete set of functionality (both intended and accidental) are we having the WG acceptance call for. The document is missing so much text that at this stage IMO it is not eligible for any IETF WG adoption pool. 

Thx,
R.

---

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

> Fully agree with Nikos' opinions. The DC world comes in many flavors,
> I believe the coauthors and contributors of this draft from MSDC
> operators know well about what they really need.
> 
> The BGP neighbor auto-discovery mechanism as described in this draft
> is mainly intended for the MSDCs following the eBGP-only design as
> recommended by RFC7938. This eBGP-only design will be kept for a long
> period of time unless they saw a STRONG and REAL benefit of deploying
> link-state protocols. Therefore, it's worthwhile to enhance the
> automation and simplification in the deployment of the eBGP-only MSDC
> fabric.
> 
> It may be useful to consider the applicability in the LSVR provided
> LSVR had a chance to be widely deployed in future even though there
> has been many link-state protocol proposals for MSDC CLOS networks
> which are either built on the proven IS-IS/OSPF protocols or built on
> totally-new designs for wider purposes.

ad they do not scale, just as making bgp as noisy as an igp.  i hope all
iij's dc competitors do that.  great idea!

randy

---

From: Abhay Roy <[email-masked]>
Date: Fri, 13 Jul 2018 22:13:23 +0000

+1

Regards,
-Abhay

+1

G/

Hi Sue, et al,

Thanks,
Acee

Hi Sue,

Greetings:

#Keyur: Yes.

#Keyur: Yes.

Regards,
Keyur

Susan Hares

---

From: Nikos Triantafillis <[email-masked]>
Date: Sat, 14 Jul 2018 16:49:46 +0300

Inline.

On Fri, Jul 13, 2018 at 10:54 PM, Robert Raszuk <[email-masked]> wrote:

> ​I don't think this is only about spelling out intentions. It is more
> about adding actual mechanisms to prevent not intended by authors
> accidental use cases.
>

"prevent not intended by authors accidental use cases" - if you have
security concerns, please bring them up for discussion.
 ​

> in DC there is need for this automation in BGP ?

Because different people operate their DCs differently. That should be a
good enough reason and we shouldn't be dictating in this or any other group
how operators should be configuring or provisioning their DCs :-)

> The BGP Hellos may help those who randomly assign fabric address plan -
> but is this really something we need to spend IDR WG time on ?
>

IDR WG shouldn't dictate how operators should run their DCs.

> new protocol and deal with it in DC dedicated WGs ?

That's one view. The other is the ask to enhance what is already out there
and deployed to suit the needs of DC operators.

Regards,

Nikos.-

Thx,

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 16 Jul 2018 11:51:24 -0400

Nikos> a much simpler one to address than asking someone to run yet 
another protocol if the functionality could be provided by enhancing the 
existing one they run.

The proposal is to define a brand new message type that is carried in 
UDP (as a multicast datagram!), rather than being carried on a BGP 
session.   It's hard to see why that is considered to be "enhancing BGP" 
rather than being "yet another protocol".   Taking a new protocol and 
calling it"BGP" does not necessarily result in an opex savings.  
Auto-discovery protocols need to be evaluated on the basis of 
functionality, cost, security, unintended side-effects, etc., not on the 
basis of what name they are given.

Robert> Last it is often the case today - when running no overlay - to 
advertise dynamically VMs or LXCs addresses to TORs via routing protocol 
- say BGP. What happens when now the LXCs or VMs will start sending such 
BGP Hellos directly to TORs ? Do you envision that this proposal will 
automatically establish BGP sessions with those tenant entities if they 
happen to be on the same subnet then compute node itself ?

Nikos> Do you need to enable such functionality on the VMs or LXCs?

One certainly has to deal with the possibility that a Hello will come in 
on an interface that is "DC-facing" rather than "network-facing".

Presumably one wouldn't intentionally enable such functionality on an 
arbitrary tenant VM.  Not intentionally.  Also, is it really 
inconceivable that a malicious tenant may find a way to cause the Hellos 
to be generated even if the functionality has not been enabled?

Something that all the auto-discovery proposals need to make clear is 
how much provisioning has to be done before the auto-discovery protocol 
starts up.  Perhaps the intention is that it is known by provisioning 
that certain interfaces are allowed to lead to EBGP neighbors,  and 
certain interfaces are not?

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Jul 2018 14:13:30 -0400

Eric :

Could you provide a short summary on your opinion on potential auto-discovery protocols based on functionality, cost security, unintended side 

a)      Draft-xu-idr-neighbor-autodiscovery 

b)      Use of LLDP (draft-acee-idr-lldp-peer-discovery) 

c)       A multicast of neighbor information 

I know you’ve mentioned part of this information in other messages --- but I think it would be very useful to advance the discussion on this draft. 

Thank you, 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Monday, July 16, 2018 11:51 AM
To: Nikos Triantafillis; Robert Raszuk
Cc: Keyur Patel; [email-masked]; Susan Hares; [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Nikos> a much simpler one to address than asking someone to run yet another protocol if the functionality could be provided by enhancing the existing one they run. 

The proposal is to define a brand new message type that is carried in UDP (as a multicast datagram!), rather than being carried on a BGP session.   It's hard to see why that is considered to be "enhancing BGP" rather than being "yet another protocol".   Taking a new protocol and calling it"BGP" does not necessarily result in an opex savings.  Auto-discovery protocols need to be evaluated on the basis of functionality, cost, security, unintended side-effects, etc., not on the basis of what name they are given.

Robert> Last it is often the case today - when running no overlay - to advertise dynamically VMs or LXCs addresses to TORs via routing protocol - say BGP. What happens when now the LXCs or VMs will start sending such BGP Hellos directly to TORs ? Do you envision that this proposal will automatically establish BGP sessions with those tenant entities if they happen to be on the same subnet then compute node itself ? 

One certainly has to deal with the possibility that a Hello will come in on an interface that is "DC-facing" rather than "network-facing".  

Presumably one wouldn't intentionally enable such functionality on an arbitrary tenant VM.  Not intentionally.  Also, is it really inconceivable that a malicious tenant may find a way to cause the Hellos to be generated even if the functionality has not been enabled?

Something that all the auto-discovery proposals need to make clear is how much provisioning has to be done before the auto-discovery protocol starts up.  Perhaps the intention is that it is known by provisioning that certain interfaces are allowed to lead to EBGP neighbors,  and certain interfaces are not?

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Jul 2018 14:21:35 -0400

Eric:

If you get time to send details on this analysis, will you include: 

·         draft-raszuk-idr-bgp-auto-session-setup-00

Robert would appreciate the feedback (and so would I). 

Thank you, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, July 16, 2018 2:14 PM
To: 'Eric C Rosen'; 'Nikos Triantafillis'; 'Robert Raszuk'
Cc: 'Keyur Patel'; [email-masked]; [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Eric :

Thank you, 

Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 16 Jul 2018 19:28:02 +0000

Hello Eric/All,

We have updated the document with more details based on the feedback and comments received from the WG. I hope this better describes the proposal and provides clarity on its interactions with the BGP protocol operations.

https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-09

Would request to please review this version and share your inputs/comments.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 16 July 2018 14:22
To: 'Eric C Rosen' <[email-masked]>; 'Nikos Triantafillis' <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Keyur Patel' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Eric:

Thank you, Sue

Cc: 'Keyur Patel'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Eric :

Thank you,

Sue Hares

Cc: Keyur Patel; [email-masked]<mailto:[email-masked]>; Susan Hares; [email-masked]<mailto:[email-masked]>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 16 Jul 2018 20:04:26 +0000

I'm not sure that it matters if the transport for the messages is UDP or LLDP.
AFAIK, LLDP can only go one hop. That might be a good thing.

The hello messages really don't need to go on forever.
LDP sends them forever, because LDP can only set up in one direction.
BGP can set up both ways.
Once on the network, if any new BGP speaker arrives, all existing speakers on that link can find it by its hellos and establish with it.

The hello messages are not necessary for session teardown. Keepalives already do that.

Both draft-xu-idr-neighbor-autodiscovery and draft-acee-idr-lldp-peer-discovery contain valuable TLVs. I would like to adopt a draft that contains TLVs from both drafts.

In addition, I would like a TLV that contains a network name. Every speaker in the same network will have the same network name. This can be used to contain the discovery process within a named network if multiple networks are connected together.

Regards,
Jakob.

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Mon, 16 Jul 2018 20:18:55 +0000

From: Idr <[email-masked]> on behalf of "Jakob Heitz (jheitz)" <jheitz=[email-masked]>
Date: Monday, July 16, 2018 at 1:05 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

>>Section 5: The IP packet (UDP hello) is set to a ttl of 1.

>> Yes, that’s a good point. IIRC earlier versions of the draft had something on this?

Regards,
Jakob.

Thanks,
--Satya

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Jul 2018 16:38:57 -0400

Jakob,

> AFAIK, LLDP can only go one hop. That might be a good thing.

LLDP, however, doesn't transit switches.  This restricts its use case
considerably.  (Somewhat intentionally.)

As I mentioned in my own comments earlier, auto-discovery is worth working
on.  Exactly which transport(s) we choose will be much of the interesting
discussion.

> The hello messages are not necessary for session teardown. Keepalives already do that.

I think the general concern is what we do with the BGP FSM if we start doing
LDP-like things.  LDP has some ugly FSM implications we likely wouldn't want
in BGP.

> In addition, I would like a TLV that contains a network name. Every speaker in the same network will have the same network name. This can be used to contain the discovery process within a named net…

I'm not sure I follow your use case, but prior discussion about names over
BGP capabilities that help with the link local case definitely fit into this
rough space.

-- Jeff

---

From: Derek Yeung <[email-masked]>
Date: Tue, 17 Jul 2018 01:08:16 +0000

Agree the WG should wait till the issues raised in these threads, in particular which auto-discovery approach to take, are resolved.

Thanks,
Derek

From: Idr <[email-masked]> on behalf of Abhay Roy <[email-masked]>
Date: Friday, July 13, 2018 at 3:13 PM
To: Gunter Van De Velde <guntervandeveldecc=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Keyur Patel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

+1

Regards,
-Abhay

+1

G/

Hi Sue, et al,

Thanks,
Acee

Hi Sue,

Greetings:

#Keyur: Yes.

#Keyur: Yes.

Regards,
Keyur

Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 09:15:38 +0800

Sound interesting:) What's the difference between proposing a draft to RTGWG and proposing the same draft to IDR?  Has UDP port 179 been booked? 

Best regards,
Xiaohu

------------------------------------------------------------------
From:Robert Raszuk <[email-masked]>
Send Time:2018年7月13日(星期五) 15:18
To:徐小虎(义先) <[email-masked]>
Cc:Keyur Patel <[email-masked]>; Susan Hares <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Because the proposal is for IDR WG and is being asked for adoption by IDR WG. 

If you move the proposal to RTGWG and not recommend using UDP port 179 I think it may go smooth as is. 

Thx,
R.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 09:33:08 +0800

Hi Eric,

------------------------------------------------------------------
From:Eric C Rosen <[email-masked]>
Send Time:2018年7月16日(星期一) 23:51
To:Nikos Triantafillis <[email-masked]>; Robert Raszuk <[email-masked]>
Cc:Keyur Patel <[email-masked]>; [email-masked] <[email-masked]>; Susan Hares <[email-masked]>; [email-masked] <[email-masked]>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

[Xiaohu] Good observation. The intent of this draft is to decouple the BGP peer discovery mechanism and the existing BGP mechanism and therefore introduce changes to the existing BGP mechanism as little as possible. By the way, does this happen to address the concern raised by Keyur in the email responding to the WG adoption call:

[Xiaohu] The Hello messages coming in on an interface where the BGP auto-discovery is disabled would be discarded.

[Xiaohu] The Hello messages coming in on an interface where the BGP auto-discovery is disabled would be discarded.

[Xiaohu] Exactly.

Best regards,
Xiaohu

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 17 Jul 2018 13:39:47 +0000

The main purpose of this draft is to:

a)      Simplify the MACD in terms of adding Leafs/Spines into a DC fabric

b)      Reduce the amount of “human touch” needed for the care and feeding of the above?

Is there more to the ask here?

Why is scripting not sufficient to meet this ask? IOW what is unique here the IP Addresses, number of interface, ASN List etc…

I would like to better understand the trade-off between the added complexity of modifying BGP in the manner proposed and the simplification..

It would be useful to provide more information as to the driver(s) for this draft…

Thanks,
                Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Monday, July 16, 2018 3:28 PM
To: Susan Hares <[email-masked]>; 'Eric C Rosen' <[email-masked]>; 'Nikos Triantafillis' <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Keyur Patel' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hello Eric/All,

https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Didr-2Dneighbor-2Dautodiscovery-2D09&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FT-lCfjgXir4WhnyJwGTkogTDuXBvH0HydO7P6BNBHo&s=8EG10mMq-fhv5rqYctp5jTkVoGvvKq3joBMF4otSw9k&e=>

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: 16 July 2018 14:22
To: 'Eric C Rosen' <[email-masked]<mailto:[email-masked]>>; 'Nikos Triantafillis' <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>
Cc: 'Keyur Patel' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Eric:

Thank you, Sue

Eric :

Thank you,

Sue Hares

---

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

Hi Jim,

It would better if operators like yourself (and others including those on this draft) clarify their operational concerns, experience and requirements that drive this.

From my perspective, when we take BGP and turn it into a hop-by-hop routing protocol (RFC7839), it is not really a big leap from there on to look for some sort of neighbour discovery and automation in the protocol for session setup.

Just to clarify, are you questioning the very requirement of neighbour discovery and automate session setup for BGP in RFC7839 networks OR you agree on this requirement but are questioning the need to do this using BGP (i.e. the proposal in this specific draft)?

It would really help this debate if we get a sense from operators of RFC7839 networks (or those wanting to build them) on (a) the need for neighbour discovery & automated session setup and then we look at (b) how to do this.

Thanks,
Ketan

From: UTTARO, JAMES <[email-masked]>
Sent: 17 July 2018 09:40
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <[email-masked]>; 'Eric C Rosen' <[email-masked]>; 'Nikos Triantafillis' <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Keyur Patel' <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Thanks,
                Jim Uttaro

To: Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Eric C Rosen' <[email-masked]<mailto:[email-masked]>>; 'Nikos Triantafillis' <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>

Hello Eric/All,

Thanks,
Ketan

Eric:

Thank you, Sue

Eric :

Thank you,

Sue Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 22:56:50 +0800

Hi Jim，

For small or even medium-sized DC fabrics, script and even CLI is sufficient. For large-scale DC fabric, automation and simplicity is always needed. For the use of BGP as IGP in MSDC, it's better to borrow the automation of IGP into IGP so as to simplify the configuration. Furthermore, it's desirable to establish BGP sessions over loopback addresses when there are multiple links among a give peer of switches. However, it's not good to introduce static routes to remote loopback addresses from the automation perspective, also not good to introduce another complex routing protocol such as ISIS or OSPF just for advertising the loopback addresses.

Best regards,
Xiaohu 

来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：UTTARO, JAMES<[email-masked]>
日　期：2018年07月17日 21:39:47
收件人：Ketan Talaulikar (ketant)<ketant=[email-masked]>; Susan Hares<[email-masked]>; 'Eric C Rosen'<[email-masked]>; 'Nikos Triantafillis'<[email-masked]>; 'Robert Raszuk'<[email-masked]>
抄　送：'Keyur Patel'<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
主　题：Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

 

 
 
Thanks,
                Jim Uttaro

Hello Eric/All,

 
 
Thanks,
Ketan

Eric:

 
Thank you, Sue 

Eric :

 
Thank you, 
 
Sue Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 22:56:59 +0800

Hi Jim，

Best regards,
Xiaohu 

 

 

Thanks,
                Jim Uttaro

Hello Eric/All,

 
 
Thanks,
Ketan

Eric:

 
Thank you, Sue 

Eric :

 
Thank you, 
 
Sue Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 17 Jul 2018 23:14:08 +0800

By the way, in addition to automate and simplify the use of BGP as IGP in MSDC, the BGP peer auto-discovery mechanism as described in this draft has the potential to be applicable to BGP-SR-TE and LSVR as well. 

Sorry for touching the LSVR cheese unintentionally:)

Best regards,
Xiaohu 

来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：徐小虎(义先)<[email-masked]>
日　期：2018年07月17日 22:56:59
收件人：Idr<[email-masked]>; Ketan Talaulikar (ketant)<ketant=[email-masked]>; Susan Hares<[email-masked]>; Eric C Rosen<[email-masked]>; Nikos Triantafillis<[email-masked]>; Robert Raszuk<[email-masked]>
抄　送：Keyur Patel<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
主　题：[Idr] 回复： WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Jim，

Best regards,
Xiaohu 

 

 

Thanks,
                Jim Uttaro

Hello Eric/All,

 
 
Thanks,
Ketan

Eric:

 
Thank you, Sue 

Eric :

 
Thank you, 
 
Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2018 17:30:43 +0200

>  However, it's not good to introduce static routes to remote loopback
addresses from the automation perspective

It is actually very good if you know how to do it correctly. I think Dino
was asking this question at the LSR WG mic yesterday. And someone
responded: "But the links break" oh .... hint: BFD works fine with static
routes for a long time !

Cheers,
R.

On Tue, Jul 17, 2018 at 4:56 PM, 徐小虎(义先) <[email-masked]> wrote:

> Hi Jim，
>
> For small or even medium-sized DC fabrics, script and even CLI is
> sufficient. For large-scale DC fabric, automation and simplicity is always
> needed. For the use of BGP as IGP in MSDC, it's better to borrow the
> automation of IGP into IGP so as to simplify the configuration.
> Furthermore, it's desirable to establish BGP sessions over loopback
> addresses when there are multiple links among a give peer of switches.
> However, it's not good to introduce static routes to remote loopback
> addresses from the automation perspective, also not good to introduce
> another complex routing protocol such as ISIS or OSPF just for advertising
> the loopback addresses.
>
> Best regards,
> Xiaohu
>
>
>
>
>
> 来自钉钉专属商务邮箱 <http://(null)>
>
> 收件人：Ketan Talaulikar (ketant)<ketant=[email-masked]>; Susan
> Hares<[email-masked]>; 'Eric C Rosen'<[email-masked]>; 'Nikos
> Triantafillis'<[email-masked]>; 'Robert Raszuk'<
> [email-masked]>
> 抄 送：'Keyur Patel'<[email-masked]>; draft-xu-idr-neighbor-
> [email-masked]<[email-masked]>;
> [email-masked]<[email-masked]>
> *The main purpose of this draft is to:*
>
>
>
> *a)      **Simplify the MACD in terms of adding Leafs/Spines into a DC
> fabric*
>
> *b)      **Reduce the amount of “human touch” needed for the care and
> feeding of the above?*
>
>
>
> *Is there more to the ask here? *
>
>
>
> *Why is scripting not sufficient to meet this ask? IOW what is unique here
> the IP Addresses, number of interface, ASN List etc…*
>
>
>
> *I would like to better understand the trade-off between the added
> complexity of modifying BGP in the manner proposed and the simplification..*
>
>
>
> *It would be useful to provide more information as to the driver(s) for
> this draft…*
>
>
>
> *Thanks,*
>
> *                Jim Uttaro*
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Ketan Talaulikar
> (ketant)
> *Sent:* Monday, July 16, 2018 3:28 PM
> *To:* Susan Hares <[email-masked]>; 'Eric C Rosen' <[email-masked]>;
> 'Nikos Triantafillis' <[email-masked]>; 'Robert Raszuk' <
> [email-masked]>
> *Cc:* 'Keyur Patel' <[email-masked]>; draft-xu-idr-neighbor-
> [email-masked]; [email-masked]
> *Subject:* Re: [Idr] WG adoption call for draft-xu-idr-neighbor-
> autodiscovery
>
>
>
> Hello Eric/All,
>
>
>
> We have updated the document with more details based on the feedback and
> comments received from the WG. I hope this better describes the proposal
> and provides clarity on its interactions with the BGP protocol operations.
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Didr-2Dneighbor-2Dautodiscovery-2D09&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FT-lCfjgXir4WhnyJwGTkogTDuXBvH0HydO7P6BNBHo&s=8EG10mMq-fhv5rqYctp5jTkVoGvvKq3joBMF4otSw9k&e=>
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Susan Hares
> *Sent:* 16 July 2018 14:22
> *To:* 'Eric C Rosen' <[email-masked]>; 'Nikos Triantafillis' <
> [email-masked]>; 'Robert Raszuk' <[email-masked]>
> *Cc:* 'Keyur Patel' <[email-masked]>; draft-xu-idr-neighbor-
> [email-masked]; [email-masked]
> *Subject:* Re: [Idr] WG adoption call for draft-xu-idr-neighbor-
> autodiscovery
>
>
>
> Eric:
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares
> *Sent:* Monday, July 16, 2018 2:14 PM
> *To:* 'Eric C Rosen'; 'Nikos Triantafillis'; 'Robert Raszuk'
> *Cc:* 'Keyur Patel'; [email-masked];
> [email-masked]
> *Subject:* Re: [Idr] WG adoption call for draft-xu-idr-neighbor-
> autodiscovery
>
>
>
> Eric :
>
>
>
> Could you provide a short summary on your opinion on potential
> auto-discovery protocols based on functionality, cost security, unintended
> side
>
> I know you’ve mentioned part of this information in other messages --- but
> I think it would be very useful to advance the discussion on this draft.
>
>
>
> Thank you,
>
>
>
> Sue Hares
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Eric C Rosen
> *Sent:* Monday, July 16, 2018 11:51 AM
> *To:* Nikos Triantafillis; Robert Raszuk
> *Cc:* Keyur Patel; [email-masked]; Susan
> Hares; [email-masked]
> *Subject:* Re: [Idr] WG adoption call for draft-xu-idr-neighbor-
> autodiscovery
>
>
>
> The proposal is to define a brand new message type that is carried in UDP
> (as a multicast datagram!), rather than being carried on a BGP session.
> It's hard to see why that is considered to be "enhancing BGP" rather than
> being "yet another protocol".   Taking a new protocol and calling it"BGP"
> does not necessarily result in an opex savings.  Auto-discovery protocols
> need to be evaluated on the basis of functionality, cost, security,
> unintended side-effects, etc., not on the basis of what name they are given.
>
> advertise dynamically VMs or LXCs addresses to TORs via routing protocol -
> say BGP. What happens when now the LXCs or VMs will start sending such BGP
> Hellos directly to TORs ? Do you envision that this proposal will
> arbitrary tenant VM.  Not intentionally.  Also, is it really inconceivable
> that a malicious tenant may find a way to cause the Hellos to be generated
> even if the functionality has not been enabled?
>
> Something that all the auto-discovery proposals need to make clear is how
> much provisioning has to be done before the auto-discovery protocol starts
> up.  Perhaps the intention is that it is known by provisioning that certain
> interfaces are allowed to lead to EBGP neighbors,  and certain interfaces
> are not?
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2018 17:35:17 +0200

>
> By the way, in addition to automate and simplify the use of BGP as IGP in
> MSDC, the BGP peer auto-discovery mechanism as described in this draft has
> the potential to be applicable to BGP-SR-TE and LSVR as well.
>

​And that is precisely the fundamental issue not a feature to be proud
about here. You do not turn BGP into link state protocol because you like
to apply LSVR or BGP-SR-TE in the DCs.

Its completely upside down.

That's why my draft ​
https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-00 is a
simple and short honesty check. Is this discussion about helping to bring
the BGP sessions up in some env. or it is rather a black box which bringing
BGP discovery is just a label on it and content will explode in no time
when its shipped ?

Thx,
R.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 18 Jul 2018 00:06:48 +0800

LOL

来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：Robert Raszuk<[email-masked]>
日　期：2018年07月17日 23:35:17
收件人：徐小虎(义先)<[email-masked]>
抄　送：Idr<[email-masked]>; Ketan Talaulikar (ketant)<ketant=[email-masked]>; Susan Hares<[email-masked]>; Eric C Rosen<[email-masked]>; Nikos Triantafillis<[email-masked]>; Keyur Patel<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
主　题：Re: [Idr] 回复： 回复： WG adoption call for draft-xu-idr-neighbor-autodiscovery

​And that is precisely the fundamental issue not a feature to be proud about here. You do not turn BGP into link state protocol because you like to apply LSVR or BGP-SR-TE in the DCs. 

That's why my draft ​https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-00 is a simple and short honesty check. Is this discussion about helping to bring the BGP sessions up in some env. or it is rather a black box which bringing BGP discovery is just a label on it and content will explode in no time when its shipped ? 

Thx,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 18 Jul 2018 15:17:58 +0000

There may be two network operators that want to auto-discover their own networks.
All their routers speak BGP.
They may peer with each other, but do not want to auto-discover each other.
They may peer with a protocol other than BGP.
They may peer with BGP, but apply different routing policies.
Whatever the case, they will treat the peering neighbor differently to their own neighbors.
A TLV to signal a network name can be used to distinguish these BGP neighbor types.

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Monday, July 16, 2018 1:39 PM

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Jul 2018 17:33:35 +0200

> A TLV to signal a network name can be used to distinguish these BGP

​And how do you protect from spoofing such network name ?

Regards,
Robert.

​

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 18 Jul 2018 15:43:12 +0000

With the keychain TLV in Acee's draft.
I did ask to combine the TLVs from both drafts.
Keychain name and network name have different uses and can change at different times, so both are needed.

Regards,
Jakob.

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, July 18, 2018 8:34 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>; [email-masked]
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Regards,
Robert.

​

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Jul 2018 11:46:58 -0400

Jakob,

> A TLV to signal a network name can be used to distinguish these BGP neighbor types.

Ok.  You're asking after both identity, and potentially some sort of device
class, along with some name spacing.

Reasonable things, although I think we have different ideas about the
specifics right now.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Jul 2018 05:41:46 -0400

This closes the 2 week adoption for draft-xu-idr-neighbor-autodiscovery

(July 2 - July 16). 

The WG chairs conclude on my original questions that: 

1)  There is WG interest to have an auto-discovery mechanism 

that will work for BGP peers in Data Centers

2)  There is some WG  interest having this work

in other deployments. 

3)  There is no consensus on the mechanisms 

(BGP hellos or other mechanisms) 

Or requirements for the mechanisms. 

4)  There is WG consensus and AD Consensus that we should 

collaborate with LSVR. One mechanism for both would 

be good, but it needs to fit the requirements set

by the WG.  

There is no consensus on adoption this draft. 

During today's IDR session (18:10-19:10), we will have a 

discussion on the requirements for the auto-discovery mechanisms. 

We will start by reviewing the LSVR requirement set.

If our discussions today do not come to a clear conclusion, 

the chairs are willing to sponsor an interim on the topic. 

Susan Hares and John Scudder. 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, July 2, 2018 1:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings: 

This begins a 2 week WG adoption call for
draft-xu-idr-neighbor-autodiscovery (July 2 - July 16).  

 

Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 20 Jul 2018 19:12:18 +0800

Hi Sue,

Thanks for launching the WG adoption call for draft-xu-idr-neighbor-autodiscovery.

Hi all,

There has been one implementation developed by a switch vendor. Furthermore at least two additional implementations from other vendors are under construction. If any of you have any concrete and technical concerns on this mechanism, please feel free to tell us and we would like to verify your concerns on the implementation and then give you feedbacks.

Best regards,
Xiaohu
Send Time:2018年7月19日(星期四) 17:59

 (July 2 – July 16). 

During today’s IDR session (18:10-19:10), we will have a 
discussion on the requirements for the auto-discovery mechanisms. 
We will start by reviewing the LSVR requirement set.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Jul 2018 07:17:58 -0400

Xiaohu:

Our next step is to gather requirements for the IDR neighbor discovery from the WG.  We would especially be interested in feedback on requirements from operators of data centers.  If you know of an operators of medium data centers who could send requirements to the IDR chairs or the IDR list, it would be helpful.

Cheerily, Susan Hares 

From: Idr [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Friday, July 20, 2018 7:12 AM
To: Idr; idr
Cc: draft-xu-idr-neighbor-autodiscovery
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Sue,

Hi all,

Best regards,

Xiaohu

To:idr <[email-masked]>

(July 2 – July 16). 

in other deployments. 

by the WG.  

Greetings: 

 

Susan Hares

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 20 Jul 2018 19:49:31 +0800

Hi Sue,

Understood, I will. 

By the way, some authors of this draft are exactly from MSDC operators including Alibaba, Tencent and LinkedIn.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Susan Hares <[email-masked]>
Send Time:2018年7月20日(星期五) 19:18
To:徐小虎(义先) <[email-masked]>; Idr <[email-masked]>; idr <[email-masked]>
Cc:draft-xu-idr-neighbor-autodiscovery <[email-masked]>
Subject:RE: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Xiaohu:

Cheerily, Susan Hares 

Hi Sue,

Hi all,

Best regards,
Xiaohu

Greetings: 

Susan Hares

---

From: [email-masked]
Date: Fri, 20 Jul 2018 12:04:50 +0000 (UTC)

To keep both LSVR and IDR WG in sync , i appreciate to keep LSVR WG in involved. This will allow better understanding of use-case requirement synergies and will aid the framing of most optimal solution space.

G/

Gunter Van de Velde

From: 徐小虎(义先)

Sent: Friday, July 20, 07:51

To: Susan Hares, Idr, idr

Hi Sue,

Understood, I will. 

Best regards,

Xiaohu

Xiaohu:

 

Cheerily, Susan Hares 

To: Idr; idr

 

Hi Sue,

 

Hi all,

 

Best regards,

Xiaohu

To:idr <[email-masked]>

 

(July 2 – July 16). 

 

in other deployments. 

 

by the WG.  

 

 

 

 

To: [email-masked]

 

Greetings: 

 

 

 

 

 

 

 

Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Jul 2018 08:21:21 -0400

Gunter: 

Thank you for mention that fact.  I had my second cup of tea and noticed I missed requesting it be cross-posted to LSVR WG. 

Sue 

From: Lsvr [mailto:[email-masked]] On Behalf Of guntervandeveldecc=[email-masked]
Sent: Friday, July 20, 2018 8:05 AM
To: Susan Hares; Idr; idr; 徐小虎(义先); [email-masked]
Cc: draft-xu-idr-neighbor-autodiscovery
Subject: Re: [Lsvr] [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

G/

Gunter Van de Velde

From: 徐小虎(义先)

Hi Sue,

Understood, I will. 

Best regards,

Xiaohu

Xiaohu:

Cheerily, Susan Hares 

To: Idr; idr

 

Hi Sue,

Hi all,

Best regards,

Xiaohu

To:idr <[email-masked]>

(July 2 – July 16). 

in other deployments. 

by the WG.  

To: [email-masked]

Greetings: 

 

Susan Hares

---

From: Gaurav Dawra <[email-masked]>
Date: Fri, 20 Jul 2018 10:03:19 -0400

Hi Sue,

As I have shared earlier during adoption call. I have specific concerns on this document which we have shared with the authors on thread and offline. There are no authors currently from LinkedIn.

We will continue to provide input once those concerns have been addressed.

Cheers,

Gaurav

Sent from my iPhone

> On Jul 20, 2018, at 7:49 AM, 徐小虎(义先) <[email-masked]> wrote:
> 
> Hi Sue,
> 
> Understood, I will. 
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Jul 2018 10:12:51 -0400

Gaurav:

We need input on requirements rather than solutions at this time.   At this point, we are not considering any solutions until we define the requirements.  Please help us define the requirements. 

Susan Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Gaurav Dawra
Sent: Friday, July 20, 2018 10:03 AM
To: "徐小虎(义先)"
Cc: idr; draft-xu-idr-neighbor-autodiscovery; Idr; Susan Hares
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Hi Sue,

Cheers,

Gaurav

Sent from my iPhone

Hi Sue,

Understood, I will. 

Best regards,

Xiaohu

Xiaohu:

Cheerily, Susan Hares 

 

Hi Sue,

Hi all,

Best regards,

Xiaohu

To:idr <[email-masked]>

(July 2 – July 16). 

in other deployments. 

by the WG.  

From: Idr [mailto:idr-bounces@ietf..org <mailto:[email-masked]> ] On Behalf Of Susan Hares
Sent: Monday, July 2, 2018 1:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings: 

 

Susan Hares

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 20 Jul 2018 13:52:07 +0000

+1

Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, July 20, 2018 7:18 AM
To: '徐小虎(义先)' <[email-masked]>; 'Idr' <[email-masked]>; 'idr' <[email-masked]>
Cc: 'draft-xu-idr-neighbor-autodiscovery' <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Xiaohu:

Cheerily, Susan Hares

Hi Sue,

Hi all,

Best regards,
Xiaohu
Cc:draft-xu-idr-neighbor-autodiscovery <[email-masked]<mailto:[email-masked]>>

in other deployments.

by the WG.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, July 2, 2018 1:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

Greetings:

https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxu-2Didr-2Dneighbor-2Dautodiscovery_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=Zl4EhcjPSHqLNyNtcJo-FqroUcnSMXFT-gveWTjkE8E&s=vYX0R4Lrw-6SDQVv7X44vg0k4CwPipSP04k3ctQLLv8&e=>

Susan Hares

---

From: Gaurav Dawra <[email-masked]>
Date: Fri, 20 Jul 2018 22:38:01 -0400

+1

Sent from my iPhone

> On Jul 20, 2018, at 9:52 AM, UTTARO, JAMES <[email-masked]> wrote:
> 
> +1
>  
> Jim Uttaro
>

---

From: zcjiang(蒋治春) <[email-masked]>
Date: Mon, 23 Jul 2018 13:34:30 +0000

Hi , folks

I am a network architect from Tencent, one of the top 3 China's Internet giants and the largest Chinese social-network service operator, running multiple MSDCs across the world.

In our deployment of DC network, BGP is used as IGP to build the underlay of the DC fabric. Since we think BGP is better from perspective of scale and simplicity(think about the flooding of IGP in a DC fabric.....). We are also looking at the BGP based SR in DC yo achieve better traffic engineering and unified MPLS fabric across the DC/MAN and backbone.

The missing piece of BGP comparing to IGP is the neighbor auto-discovery, you still need to configure the peer address , local- remote AS etc, so the effort to add the auto neighbor discovering mechanism to BGP is highly desired.

We as an web operator and I personally as one of the contributor of the draft would like to advocate the mechanism described on this draft for sure.

Thanks

Zhichun Jiang.

To:徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; Idr <[email-masked]<mailto:[email-masked]>>; idr <[email-masked]<mailto:[email-masked]>>

Xiaohu:

Cheerily, Susan Hares

Hi Sue,

Hi all,

Best regards,
Xiaohu

in other deployments.

by the WG.

Greetings:

Susan Hares

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 31 Jul 2018 22:09:18 +0000

Zhichun,

                We also are heavily invested in BGP at AT&T Domestic and MOW networks.. help me understand the ask here. Are you saying that you want discovery everywhere in your network? Or is this ask specific to the DC and you will continue  with provisioning in the MAN/WAN space..

Thanks,
                Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of zcjiang(???)
Sent: Monday, July 23, 2018 9:35 AM
To: [email-masked]
Subject: Re: [Idr] Fw: WG adoption call for draft-xu-idr-neighbor-autodiscovery(Internet mail)

Hi , folks

Thanks

Zhichun Jiang.

Xiaohu:

Cheerily, Susan Hares

Hi Sue,

Hi all,

Best regards,
Xiaohu

in other deployments.

by the WG.

Greetings:

https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxu-2Didr-2Dneighbor-2Dautodiscovery_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=MU6Gnn4Pl1H3kbngfFfnwWWrIF4eDWqmnSrxG03TYQ8&s=JWVZk-QAfbuLnv3IJNkfcyJDYO-4MUCpjoEGA_s7plY&e=>

Susan Hares