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

[" 徐小虎(义先) " <[e-mail]>]

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


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

Xiaohu,

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

Best,
R.
On Thu, Jul 12, 2018, 12:18 徐小虎(义先) <[e-mail]> wrote:

Robert,

Please see my response inline.

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



On Thu, Jul 12, 2018 at 11:32 AM, 徐小虎(义先) <[e-mail]> wrote:
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. 

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


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

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

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


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, 徐小虎(义先) <[e-mail]> 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

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


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, 徐小虎(义先) <[e-mail]> 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. 

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

Best regards,
Xiaohu

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

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 <[e-mail]> wrote:
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 <[e-mail]> wrote:
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 
_______________________________________________
 Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr



_______________________________________________
 Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr