Subject: Re: [v6ops] Operational Headache: Multi Attached Data Center Host configuration

From: Joel Jaeggli <[email-masked]>
Date: Mon, 1 Apr 2019 10:34:33 -0700

> On Mar 29, 2019, at 17:31, Brian E Carpenter <[email-masked]> wrote:
> 
> Another question before starting to discuss: would this problem be helped by universal deployment of https://tools.ietf.org/html/rfc8028 ? And if not,
> why not?
> 
> Regards
>   Brian Carpenter
> 
> On 29-Mar-19 18:37, Fred Baker wrote:
>> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/, slide 6
>> 
>> What do we want to say on this topic? There are a number of screwball interactions, and vendor product seems to vary. This seems to call for an draft named might call for a draft draft-ietf-v6ops-operational-thoughts-on-multi-attached-hosts-in-data-centers or something like that. Is there a person or set of people that would be interested to form a design team around that topic?

One of the obvious questions for me from the outset is, are we going about this completely wrong especially with respect to data-centers?

DHCP/DHCPv6/RA/DHCPv6PD are basic configuration mechanisms for devices to attach to networks with which they have arms length relationships. 

Their use for initial attachment and boot-strapping network connectivity is straight-forward in datacenters. To suppose that they are therefore the appropriate to have a host configure what prefixes it might expose to the outside word, how it should configure it's internal topology, how it should manage sub-delegation and so forth seems like it ignores most of the work done in the IETF on management and routing.

If you need to configure a  host  in a managed environment once it's first network interface is up you can:

* use netconf
* incorporate your collection of nfv/sdx control functions into hosts
* roll your own 

if you need to express to a network what prefixes should be sent to you and on what interface

* use a routing protocol

This is what people do today, and I wouldn't call them screwball.

in datacenters I've run or worked in the last decade we have followed largely similar playbooks:

DHCP/DHCPv6 for bootstrap configuration of management interfaces.

We use a provisioning system  and a backing database to apply network configuration to ports / loopbacks / multiple kernel routing tables / VRFS / internal bridges / nat-translators / tunnels and so forth. When the configuration changes, agents are used to insure that this system converges in timely fashion. There's no concept of a lease, lifetime or ttl here, nor are those appropriate, a resource or configuration is in place until it is removed, waiting for a timer on a resource to expire in order to assume that hosts will change their behavior isn't an appropiate way to reallocate resources...

A configured host can signal the network for the purpose of programing the forwarding plane of it's availability as well as address usage using a routing protocol. the most common used for these purposes these days is probably ebgp.  convergence of forwarding is bounded by bgp signaling rather than by lease / lifetime / ttl with the upper bound being defined by the keep-alive rate or in some cases by BFD. expressive controls on the host  path selection may also be exposed through routing when the host engages in next hop selection, or path selection  if mols or some other overlay topology is present, when it is not that function is abrogated to an upstream network device (which may in fact have to resort to policy based routing in order to place the right sources on the right networks.

>> --------------------------------------------------------------------------------
>> The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>