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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/idr >> > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
