Re: [Idr] [spring] New draft for data center gateways

[Robert Raszuk <[e-mail]>]

John, Adrian & Eric,

Btw .. indirection I am suggesting may not only be realized by choice of a
new overlay system.

Alternative design would be to only encode a given's DC "COLOR" or "ID"
into the tunnel encapsulation attribute which would not change for each X
then to establish full mesh EBGP multihop sessions between interesting GWs
with each again carrying the tunnel attribute with same set of "IDs" or
"COLORS" as would do atomic prefixes.

- If such full eBGP mesh would be getting large use of stock BGP Route
Server may be used at any DC or in the backbone.

- Over such sessions single prefixes would be exchanged - something what
you refer to auto discovery routes in current document but those would be
only send over EBGP not IBGP.

- This would also remove any need to run intra-DC auto discovery.

- The connectivity restoration time would be significantly reduced as
multihop BFD may be used (directly or to RS).


The above described proposal changes your current architecture however I
believe it significantly simplifies things, removes the concern of scale
and simplifies or even eliminates any new development needed to deploy it
today provided that given's vendor policy already allows to match routes
with specific attribute payload.

Cheers,
R.

PS. If this game is under same administration (which I think it is based on
the requirements) then to mark the routes use of standard or extended
community can be used instead of tunnel encapsulation attribute.










On Tue, May 24, 2016 at 11:27 PM, Robert Raszuk <[e-mail]> wrote:

> Hi John,
>
> *[JD]  We were assuming that a) GW/backbone links would be advertised in
>> BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the
>> backbone does not advertise an auto-discovery route.  This will be made
>> explicit in the next revision.  *
>>
>
> ​Ad a) - EPE works fine with next hop self on the ASBRs of the bacbone. So
> if your proposal requires external links to be passive in the backbone IGP
> then the draft needs to state it well. Besides it may not be sufficient if
> more then one backbone instance is used to interconnect DCs.
>
> Ad b) - The current set of procedures described in section 2 for
> constructing auto discovery routes is not sufficient. GW may be
> interconnected to more then one backbone each serving different set of
> prefixes within each DC (you call it X). So much more would need to go into
> the auto-discovery to make this work in practice. And even if you would go
> that way it will be slow to re-advertise all prefixes with different tunnel
> attribute content.
>
> *[JD]   Are you simply repeating the opinion you expressed when the
>> tunnel-encaps draft first came out, or do you have a scalability concern
>> that hasn't already been discussed?*
>>
>>
> ​I am expressing the observation that tunnel-encaps may work well to pass
> static information or information which may change by configiration.
>
> Here you are using it to pass remote reachability info embedded into it. I
> find it far from optimal which as combined with possible DC prefix scale is
> likely to cause more issues then benefits.
>
> That's why I suggest use of indirection layer to solve this overall
> problem. As mentioned one could be LISP or any other SD-WAN solutions.
>
> Thx,
> R.
>
>