Subject: Re: Routing in DC RTGWG interim - updated

From: Jeff Tantsura <[email-masked]>
Date: Tue, 10 Jan 2017 13:19:10 -0800

Hi,

Please find updated agenda for 25th’s interim

Presenters:

Problem statements:

Petr Lapukhov - FB

Dmitry Afanasiev - YANDEX

Russ White/ Shawn Zandi - LinkedIn

Solutions proposed:

Keyur Patel, Arrcus  - Shortest Path Routing Extensions for BGP Protocol, draft-keyupate-idr-bgp-spf

Naiming Shen , Cisco  - IS-IS Routing for Spine-Leaf Topology, draft-shen-isis-spine-leaf-ext

Tony Przygienda, Juniper - RIFT: Routing in Fat Trees, draft-przygienda-rift  (draft to be published later this week)

Bhumip Khasnabish, ZTE - Generic Fault-avoidance Routing Protocol for Data Center Networks, draft-sl-rtgwg-far-dcn

Thanks!

Cheers,

Jeff & Chris

From: Jeff Tantsura <[email-masked]>
Date: Saturday, December 17, 2016 at 06:10
To: RTGWG <[email-masked]>
Cc: 'rtgwg-chairs' <[email-masked]>, Idr <[email-masked]>, Isis-wg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Routing in DC RTGWG interim

Hi Routing Protocols wg’s,

There have been number of recently published drafts and discussions on the topic

As discussed in Seoul, we’d like to have a RTGWG interim to provide the platform for both, draft authors and implementers to talk about what and why.

The date we have set is January 25, 9:00AM PST.

We will be reaching out to you.

Based on our preliminary discussion in Seoul we are planning to have the following presenters:

drafts:

draft-keyupate-idr-bgp-spf – Keyur to present

draft-shen-isis-spine-leaf-ext – Naiming?

draft-sl-rtgwg-far-dcn -?

Tony P?

DC network designers:

LinkedIn – Shawn Z./Russ

Yandex - Dmitry Afanasiev

More to be announced

Thanks,

Jeff & Chris

---

From: prz <[email-masked]>
Date: Wed, 11 Jan 2017 15:22:52 -0800

On Tue, 10 Jan 2017 13:19:10 -0800, Jeff Tantsura  wrote:  

...

Presenters: 

... 

Tony Przygienda, Juniper - RIFT: Routing in Fat
Trees, draft-przygienda-rift (draft to be published later this week)

https://datatracker.ietf.org/doc/draft-przygienda-rift/ 

--- tony

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 24 Jan 2017 15:32:37 -0800

Hi,

Agenda and webex details for the upcoming interim have been posted at https://datatracker.ietf.org/meeting/interim-2017-rtgwg-01/agenda/rtgwg/

Presentations are available (partially) at https://datatracker.ietf.org/meeting/interim-2017-rtgwg-01/session/rtgwg

Looking forward to seeing you all at the interim, coming Wednesday, January 25 at 9:00AM PST.

Cheers,

Jeff and Chris

From: Jeff Tantsura <[email-masked]>
Date: Tuesday, January 10, 2017 at 13:19
To: RTGWG <[email-masked]>
Cc: 'rtgwg-chairs' <[email-masked]>, Idr <[email-masked]>, Isis-wg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Routing in DC RTGWG interim - updated

Hi,

Presenters:

Problem statements:

Petr Lapukhov - FB

Solutions proposed:

 

Thanks!

Cheers,

Jeff & Chris

drafts:

Tony P?

DC network designers:

LinkedIn – Shawn Z./Russ

More to be announced

Thanks,

Jeff & Chris

---

From: Chris Bowers <[email-masked]>
Date: Wed, 25 Jan 2017 16:27:08 +0000

Wednesday, January 25, 2017 | 12:00 pm Eastern Standard Time (GMT-05:00) | 2 hours 30 minutes |

Webex details:

JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m7b7af612f14bf1c397d5c2424e7d709b
Meeting number (access code): 649 161 321
Host key: 878366
Meeting password: px3Gk22M

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)

Toll-free dialing restrictions:
https://www.webex.com/pdf/tollfree_restrictions.pdf

Agenda:

Problem statements:
-Petr Lapukhov - FB
-Dmitry Afanasiev - YANDEX
-Russ White/ Shawn Zandi - LinkedIn

Solutions proposed:
-Keyur Patel, Arrcus - Shortest Path Routing Extensions for BGP Protocol, draft-keyupate-idr-bgp-spf
-Naiming Shen, Cisco - ISIS Routing for Spine-Leaf Topology, draft-shen-isis-spine-leaf-ext
-Tony Przygienda, Juniper - RIFT: Routing in Fat Trees, draft-przygienda-rift
-Bhumip Khasnabish, ZTE - Generic Fault-avoidance Routing Protocol for Data Center Networks, draft-sl- rtgwg-far-dcn

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Tuesday, January 24, 2017 5:33 PM
To: RTGWG <[email-masked]>
Cc: 'rtgwg-chairs' <[email-masked]>; Idr <[email-masked]>; Isis-wg <[email-masked]>; [email-masked]
Subject: Re: Routing in DC RTGWG interim - updated

Hi,

Cheers,
Jeff and Chris

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 10, 2017 at 13:19
To: RTGWG <[email-masked]<mailto:[email-masked]>>
Cc: 'rtgwg-chairs' <[email-masked]<mailto:[email-masked]>>, Idr <[email-masked]<mailto:[email-masked]>>, Isis-wg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Routing in DC RTGWG interim - updated

Hi,

Presenters:
Problem statements:
Petr Lapukhov - FB

Solutions proposed:

Thanks!

Cheers,
Jeff & Chris

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Saturday, December 17, 2016 at 06:10
To: RTGWG <[email-masked]<mailto:[email-masked]>>
Cc: 'rtgwg-chairs' <[email-masked]<mailto:[email-masked]>>, Idr <[email-masked]<mailto:[email-masked]>>, Isis-wg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Routing in DC RTGWG interim

drafts:

DC network designers:
LinkedIn – Shawn Z./Russ

More to be announced

Thanks,
Jeff & Chris

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 25 Jan 2017 19:26:48 +0000

One quick suggestion for the solution presenters:

Perhaps it’s good to have a section in respective documents how the proposal can bring operational simplicity (if at all)  than existing deployments (say than RFC 7938 based..).
--
Uma C.

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, January 25, 2017 8:27 AM
To: RTGWG <[email-masked]>
Cc: Isis-wg <[email-masked]>; 'rtgwg-chairs' <[email-masked]>; Idr <[email-masked]>; [email-masked]
Subject: RE: Routing in DC RTGWG interim - updated

Webex details:

JOIN WEBEX MEETING

JOIN BY PHONE

Agenda:

Problem statements:
-Petr Lapukhov - FB

Solutions proposed:

Cc: 'rtgwg-chairs' <[email-masked]<mailto:[email-masked]>>; Idr <[email-masked]<mailto:[email-masked]>>; Isis-wg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi,

Cheers,
Jeff and Chris

Hi,

Presenters:
Problem statements:
Petr Lapukhov - FB

Solutions proposed:

Thanks!

Cheers,
Jeff & Chris

drafts:

DC network designers:
LinkedIn – Shawn Z./Russ

More to be announced

Thanks,
Jeff & Chris

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jan 2017 20:40:09 +0100

/* Trimming the lists a bit */

Hi Uma,

Well I would actually start with common understanding and agreement as to
what's wrong with RFC7938 based deployments in the first place ? Is there
some document or draft which describes it well ?

Is BGP local auto discovery an issue ? Then let's solve it .. it is simple
problem. Some already solved it with auto BGP peering to link local
addresses.

To perhaps restate Keyur's question ... Do we all agree with the
requirements as presented by Tony P which are triggering RIFT ?

Cheers,
R.

On Wed, Jan 25, 2017 at 8:26 PM, Uma Chunduri <[email-masked]>
wrote:

> Perhaps it’s good to have a section in respective documents how the
> proposal can bring operational simplicity (if at all)  than existing
> deployments (say than RFC 7938 based..).
>
> --
>
> Uma C.
>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 25 Jan 2017 21:04:23 +0000

Hi Robert,

In-line [Uma]:
--
Uma C.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, January 25, 2017 11:40 AM
To: Uma Chunduri <[email-masked]>
Cc: RTGWG <[email-masked]>
Subject: Re: Routing in DC RTGWG interim - updated

Hi Uma,

Well I would actually start with common understanding and agreement as to what's wrong with RFC7938 based deployments in the first place ? Is there some document or draft which describes it well ?
[Uma]: Great question.  Am not aware of any and was asking this question to myself back when I was reviewing/going-through one of the proposals..
               But AFAIS an inclination to use TE in the fabric with a controller and hence you need a full topology view at your disposal. Also link (you have massive ECMP any ways in the CLOS) and node protection?? May be more….

Is BGP local auto discovery an issue ? Then let's solve it .. it is simple problem. Some already solved it with auto BGP peering to link local addresses.
[Uma]: Possible.
               I am not sure this is the central issue ..but for SPF based approaches to have the topology view this could be one part of it (and hence in bgp-spf,  usage of BGP-LS to advertise the TCP peering as a Link NLRI with new TLVs distinguishing itself from IGP adj representation).
             Again, am not fully sure how auto discovery would be critical if it is EBGP  single-hop peering sessions.

To perhaps restate Keyur's question ... Do we all agree with the requirements as presented by Tony P which are triggering RIFT ?
[Uma]: Have few questions .. but some other day.

Cheers,
R.

On Wed, Jan 25, 2017 at 8:26 PM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
One quick suggestion for the solution presenters:

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jan 2017 22:34:16 +0100

> I am not sure this is the central issue ..but for SPF based approaches to
> have the topology view this could be one part of it (and hence in bgp-spf,
>  usage of BGP-LS to advertise the TCP peering as a Link NLRI with new TLVs
> distinguishing itself from IGP adj representation).
>

​Well on BGP SPF proposal I see number of advantage .. but very honestly I
do not buy into how it is being "sold" here.

If folks talking about it would say ... our proposal is to run BGP SPF ​on
controller only to optimize and augment things while you still run normal
eBGP in CLOS I would be perhaps very interested in seriously supporting
this work.

But if I hear that this is to replace eBGP and push routes left and right
"centrally computed" this goes way over the max level of gain vs
drawback/risk level one is to accept.

Best,
R.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 25 Jan 2017 21:46:41 +0000

Sent: Wednesday, January 25, 2017 1:34 PM

​Well on BGP SPF proposal I see number of advantage .. but very honestly I do not buy into how it is being "sold" here.

If folks talking about it would say ... our proposal is to run BGP SPF ​on controller only to optimize and augment things while you still run normal eBGP in CLOS I would be perhaps very interested in seriously supporting this work.

But if I hear that this is to replace eBGP and push routes left and right "centrally computed" this goes way over the max level of gain vs drawback/risk level one is to accept.

[Uma]: This is one of the reasons I asked if node protection is critical during  one of the problem presentations.
              You don’t need link protection in CLOS nodes  (your ECMP is indeed a link protection alternative) but if one is seeking node protection in any CLOS node RFC 7938 won’t help but bgp-spf potentially would  and as you pointed gain vs drawback/risk..

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 Jan 2017 22:09:15 +0000

Hi Robert,

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 25, 2017 at 4:34 PM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Routing in DC RTGWG interim - updated

We are really not intending the controller deployment to follow either of the above. The SPF route computation is distributed in each BGP switch and hierarchal reflectors are used to allow for a spare mesh of BGP sessions. This overcomes the many copies issue that Tony alluded to when BGP is used for <key, value> distribution.  The controller or route reflectors (dependent on the use case) could subset the scoping on the BGP-LS information or inject NLRI to influence the SPF.

My fellow authors can chime in as well.

Thanks,
Acee

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jan 2017 23:20:26 +0100

Hi AC,

My point was to indicate that running SPF regardless if it happens in
central controller or at each switch would be perhaps fine as a add-on not
as replacement of basic 7938.

As simple as this. Please think about it :) IMHO such positioning is a
smoothest way to move forward. And if someone later thinks that BGP-SPF is
cool and works great they can at their will decommission vanilla 7938. But
this should be an option to the user and BGP-SPF architecture should be
written from day one with a notion of augmentation not a clean slate
proposal.

Cheers,
R.

On Wed, Jan 25, 2017 at 11:09 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> From: rtgwg <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> Cc: Routing WG <[email-masked]>
> We are really not intending the controller deployment to follow either of
> the above. The SPF route computation is distributed in each BGP switch and
> hierarchal reflectors are used to allow for a spare mesh of BGP sessions.
> This overcomes the many copies issue that Tony alluded to when BGP is used
> for <key, value> distribution.  The controller or route reflectors
> (dependent on the use case) could subset the scoping on the BGP-LS
> information or inject NLRI to influence the SPF.
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 Jan 2017 22:46:11 +0000

Hi Robert, et al,

Great question!!! I want to assure the WG that Robert and I have had no prior collusion and he asked this independently…

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 25, 2017 at 5:20 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Uma Chunduri <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Routing in DC RTGWG interim - updated

Hi AC,

My point was to indicate that running SPF regardless if it happens in central controller or at each switch would be perhaps fine as a add-on not as replacement of basic 7938.

As simple as this. Please think about it :) IMHO such positioning is a smoothest way to move forward. And if someone later thinks that BGP-SPF is cool and works great they can at their will decommission vanilla 7938. But this should be an option to the user and BGP-SPF architecture should be written from day one with a notion of augmentation not a clean slate proposal.

We have thought about that. The beauty of BGP SPF is that you can use it solely for the underlay and maintain the services (e.g., RFC 4364) in the overlay.

Additionally, it is very easy to migrate only a portion of your data center to BGP SPF. Routers operating in both domains (BGP SPF and RFC 7938) can perform the interworking by advertising AF IPv4 unicast routes into the BGP-SPF domain as BGP-LS Prefix NLRI and reachable BGP-SPF prefixes into the normal BGP IPv4 or IPv6 unicast domain as reachable NLRI.

Thanks,
Acee

Cheers,
R.

On Wed, Jan 25, 2017 at 11:09 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks,
Acee

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jan 2017 23:51:40 +0100

> Great question!!! I want to assure the WG that Robert and I have had no
> prior collusion and he asked this independently…
>

​LOL .. Like the RTGWG would not know alreasy that I do not play such setup
games ???​ ;-) Come on AC !

> We have thought about that. The beauty of BGP SPF is that you can use it
> solely for the underlay and maintain the services (e.g., RFC 4364) in the
> overlay.
>
> Additionally, it is very easy to migrate only a portion of your data
> center to BGP SPF. Routers operating in both domains (BGP SPF and RFC 7938)
> can perform the interworking by advertising AF IPv4 unicast routes into the
> BGP-SPF domain as BGP-LS Prefix NLRI and reachable BGP-SPF prefixes into
> the normal BGP IPv4 or IPv6 unicast domain as reachable NLRI.
>

​That's not what I am talking about ... I am talking of running both in
parallel not interworking at the boundary. Think outside of the box pls.

Just to translate to your world is like running ISIS and OSPF together if
for nothing else then for routing with OSPF and using ISIS only to compute
your LFAs (if really needed and OSPF does not support it yet on your boxes)
:) ​.

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 Jan 2017 22:57:42 +0000

Date: Wednesday, January 25, 2017 at 5:51 PM

​LOL .. Like the RTGWG would not know alreasy that I do not play such setup games ???​ ;-) Come on AC !

All in fun… ;^)

​That's not what I am talking about ... I am talking of running both in parallel not interworking at the boundary. Think outside of the box pls.

Just to translate to your world is like running ISIS and OSPF together if for nothing else then for routing with OSPF and using ISIS only to compute your LFAs (if really needed and OSPF does not support it yet on your boxes) :) ​.

Yes – the could be done and the next-hops could be resolved recursively anywhere in the BGP-SPF domain. However, what advantage would this bring over advertising attached prefixes as BGP-LS Prefix NLRI?

Thanks,
Acee

Best,
R.