Network Connectivity Use Case Modeling and YAML Syntax

Use Cases 1.Client to Server connectivity a.Single L4 port b.Multiple network L4 ports or protocols required to realize the connectivity c.Network connection in opposite direction than Req/Cap relationship 2.Symmetric connectivity a.Both A and B can connect to each other in any order 2

1(a) Client Server, Single L4 port Already supported with specific syntax – Server-side port specified – Client-side port not specified, assumed ephemeral Do we want to keep special syntax for this case or support only a more general syntax which expresses any number of ports? 3 port: type: integer constraints: - greater_or_equal: 1 - less_or_equal: 65535

1(b,c) Client Server, Multiple L4 ports 4 initiator: *consumer| provider | symmetric port_specs: - nfsd_udp: ip_proto: udp dest_port: nfsd_tcp: ip_proto: tcp dest_port: 2049 … - lockd_tcp: ip_proto: tcp dest_port: Initiator indicates which side of the connectsTo relationship initiates the connection. Symmetric means either side (any order). Consumer is default matching today’s semantic. 2.Any combination of ports can be specified. 3.‘src_port’ specifies client side 4.‘dest_port’ specifies server side 5.‘src_from’ and ‘src_to’ specify client port range 6.‘dest_from’ and ‘dest_to’ specify server port range

2(a) Symmetric connectivity 5 initiator: symmetric port_specs: - jgroups_multicast: ip_proto: igmp dest_port: All providers can initiate in any order. This means the orchestrator can ignore order. 2.connectsTo is about order. This means we cannot allow connectsTo with end points with symmetric initiation. I.e. this is a completely different relationship type. 3.For servers derived from same compute node we don’t need to say more. 4.For different compute nodes we need a relation to denote the members of the symmetric connectivity group. This is an n-ary relation if we want to support 3 or more compute nodes in the same symmetric group.

2(a) Symmetric connectivity Binary relation with group name property. All providers targeted by the relation with same name belong to same group. – Pros Allows us to continue to use binary relation syntax – Cons Still implies directionality. For every pair of nodes need relation in both directions because it is the server which denotes symmetric connectivity unless we make an exception this for this relation – Explore a non-directional relation. Not obvious since Requirement/Capabilities, the meta construct for relations, is currently fundamentally directional (asymmetric) 6

Backup Slides

Requires/Provides Component AComponent B Connector Requires (E1) Provides (E1) EndPoints are Capabilities Component A requires and endpoint E1 which B provides Component A resolves to B (and its subclasses) at assembly time

ConnectsTo (thus far) Component AComponent B ConnectsTo Requires (E1) Provides (E1) Component A connectsTo Component B i.e. Component A requires a connection to Component B Connection has been assumed to be a single network connection, e.g. Client connection of TCP to MySQL at well known port 3306 over one network connection. Client side of connection is assumed to be the requiring side of the relationship. ClientServer Connection

Additional Use Cases Multiple network L4 ports or protocols required to realize the connectivity Network connection in opposite direction than Req/Cap relationship Symmetric connectivity – Both A and B can connect to each other in any order 10

Multiple network L4 ports or protocols Consider NFS – TCP or UDP: 2049(nfsd), 111(rpcbind), 892(mountd), 662(statd) – TCP (lockd) – UDP (lockd) We must be able to express – Multiple ports – Connection direction (see opposite direction use case) Consider firewall filter tuple syntax and treat as directional flow Use white-listing (assume everything is disabled by default) NOT black-listing (we don’t know what is open by default!) 11

Network connection in opposite direction than Req/Cap A DB is deployed – It requires needs monitoring implemented by an additional monitoring node – Monitoring node connects to DB node via SSH (could be any protocol, it is the direction that is important here) to collect metrics Need to be able to express this 12 Component AComponent B Requires (E1) Provides (E1) Client Server Connection

Symmetric connectivity Consider a cluster – They may know each others’ IP address and connect to each other via the same well known port over TCP – They may use a multi-cast cluster discovery/group membership protocol This is peer-to-peer – Any member can initiate communication – Expresses membership – Order is not important (for orchestration) 13

2(a) Symmetric connectivity Options for denoting groups – N-ary membership relation Pros – Concisely captures the required semantics Cons – New construct placed in a top level element which references the end endpoints in the member nodes Need to explore syntax details – *Binary relation with group name property. All providers targeted by the relation with same name belong to same group. Pros – Allows us to continue to use binary relation syntax Cons – Still implies directionality. For every pair of nodes need relation in both directions because it is the server which denotes symmetric connectivity unless we make an exception this for this relation Explore a non-directional relation. Not obvious since Requirement/Capabilities, the meta construct for relations, is currently fundamentally directional (asymmetric) – Add a group name to the endpoint properties Pros – Sounds simple and is – The name implies membership Cons – Has implications in composability but not worse than cross document relations – Not a real relationship so tooling needs a special understanding of this 14

1(b) Client Server, Multiple L4 ports It’s useful to define sets of port_specs and refer to them by name, e.g. nfs_udp, nfs_tcp and compose them: 15 port_specs: - nfs_tcp - nfs_udp 1.‘port_spec_defs’ should be scoped by namespace 2.They can be provided at the root level of documents and implicitly as part of the environment 3.They could be generalized as part of a more general ‘connectivity spec’ port_spec_ defs: - nfs_udp - nfsd_udp: ip_proto: udp dest_port: 2049 …