Re: [Idr] New draft for data center gateways

Dear Authors,

Question 1:

Assume that prefix X has been advertised with tunnel attribute as described
in the draft with both GW1 and GW2 entry points to Egress DC site.

So remote GW in Ingress DC site receives at least one such advertisement
and as each contains both GW1 and GW2 entries it can engineer flows to
those.

So far so good ... but what happens when link between PE (on left side) and
GW1 goes down ?

BGP will after some time remove that path via all ASes, but GW2 will keep
advertsing prefix X as still reachable via both GW1 and GW2 within tunnel
encapsulation attribute as from his perspective nothing will be wrong.

How remote GW in Ingress DC site is now supposed to know that GW1 link to
PE in AS2 went down and stop pushing traffic towards it ?

- - -

Question 2:

What happens if all L3 DC CLOS IP Fabrics use eBGP not IGP ?

- - -

Question 3:

Is per prefix tunnel attribute where say /32 routes may be exchanges flat
(ref calico approach - https://www.projectcalico.org/) really a scalable
solution ?

Best,
Robert.

PS. Just purely as information your inter DC traffic steering problem
description is easily solved already today with one level of indirection -
Example: LISP. Not sure if we need additional flat protocol extensions
here.

On Mon, May 23, 2016 at 8:14 PM, Robert Raszuk <robert@raszuk.net> wrote:

> Hi Adrian,
>
> Many thx for sharing the document. Just starting to read it one assertion
> repeated at least twice got my attention:
>
> "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular
> protocol mechanism for operating within a DC"
>
> By "popular protocol mechanism" when building non blocking L3 CLOS IP
> fabric are you referring to the below proposal or something else ?
>
>
> https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02
>
> Also by "popular" do you mean something which is perhaps deployed in
> production to any level or author's definition of "popular" refers to
> something real deployment are yet to see ?
>
> Honestly having been involved in building large scale data centers for the
> last few years I have not see SR being anywhere close to be used there.
> Especially MPLS flavor of it :)
>
> If anything within DCs draft-lapukhov-bgp-sdn-00 is easy to use and
> provides more then sufficient flexibility within properly constructed
> intra-dc fabric in terms of traffic engineering.
>
> Many thx,
> Robert.
>
>
> On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel <adrian@olddog.co.uk>
> wrote:
>
>> Hi,
>>
>> Just posted
>> https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/
>>
>> We think this covers an important hole. The document defines a mechanism
>> using
>> the BGP Tunnel Encapsulation attribute to allow each gateway router to
>> advertise
>> the routes to the prefixes in the data center site to which it provides
>> access,
>> and also to advertise on behalf of each other gateway to the same data
>> center
>> site.
>>
>> We posted this as  BESS draft, so discussion there, please until such
>> time that
>> the various chairs tell us to move the discussion somewhere else.
>>
>> Thanks,
>> Adrian
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>