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

[Robert Raszuk <[e-mail]>]

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.

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.


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 <draft-xu-idr-neighbor-
> [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 <draft-xu-idr-neighbor-
> [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 <draft-xu-idr-neighbor-
> [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
>
>
>
>
>
>