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

[Robert Raszuk <[e-mail]>]

>  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, 徐小虎(义先) <[e-mail]> 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)>
>
> ------------------------------------------------------------------
> 发件人：UTTARO, JAMES<[e-mail]>
> 日 期：2018年07月17日 21:39:47
> 收件人：Ketan Talaulikar (ketant)<ketant=[e-mail]>; Susan
> Hares<[e-mail]>; 'Eric C Rosen'<[e-mail]>; 'Nikos
> Triantafillis'<[e-mail]>; 'Robert Raszuk'<
> [e-mail]>
> 抄 送：'Keyur Patel'<[e-mail]>; draft-xu-idr-neighbor-
> [e-mail]<[e-mail]>;
> [e-mail]<[e-mail]>
> 主 题：Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery
>
>
> *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:[e-mail]] *On Behalf Of *Ketan Talaulikar
> (ketant)
> *Sent:* Monday, July 16, 2018 3:28 PM
> *To:* Susan Hares <[e-mail]>; 'Eric C Rosen' <[e-mail]>;
> 'Nikos Triantafillis' <[e-mail]>; 'Robert Raszuk' <
> [e-mail]>
> *Cc:* 'Keyur Patel' <[e-mail]>; draft-xu-idr-neighbor-
> [e-mail]; [e-mail]
> *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://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=>
>
>
>
> Would request to please review this version and share your inputs/comments.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Susan Hares
> *Sent:* 16 July 2018 14:22
> *To:* 'Eric C Rosen' <[e-mail]>; 'Nikos Triantafillis' <
> [e-mail]>; 'Robert Raszuk' <[e-mail]>
> *Cc:* 'Keyur Patel' <[e-mail]>; draft-xu-idr-neighbor-
> [e-mail]; [e-mail]
> *Subject:* Re: [Idr] WG adoption call for draft-xu-idr-neighbor-
> autodiscovery
>
>
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Susan Hares
> *Sent:* Monday, July 16, 2018 2:14 PM
> *To:* 'Eric C Rosen'; 'Nikos Triantafillis'; 'Robert Raszuk'
> *Cc:* 'Keyur Patel'; [e-mail];
> [e-mail]
> *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
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Eric C Rosen
> *Sent:* Monday, July 16, 2018 11:51 AM
> *To:* Nikos Triantafillis; Robert Raszuk
> *Cc:* Keyur Patel; [e-mail]; Susan
> Hares; [e-mail]
> *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 ?
>
>
>
> 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?
>
>