x
/
telcowg-usecases
Code Issues Proposed changes
telcowg-usecases/4ead597e2bc6731799000a5c088...

179 lines
8.1 KiB
Plaintext
Raw Blame History

{
"comments": [
{
"key": {
"uuid": "3acd31a7_609806c1",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 9,
"author": {
"id": 15481
},
"writtenOn": "2015-05-02T20:55:18Z",
"side": 1,
"message": "I wonder, if \"Session Border Controller\" is a good title for this use case. It is misleading. The goal of this use case is not to specify a SBC, the goal is to list the requirements for high performance networking (packet processing)\n\nIt seems to me, that \"High Performance Networking\" would be a better title.",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3afb71cf_7764e8b7",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 9,
"author": {
"id": 8711
},
"writtenOn": "2015-06-10T17:24:36Z",
"side": 1,
"message": "Yes and no. The goal is to draw out all the requirements of this particular implementation of an SBC - which happen to be fairly generic requirements for high perf packet processing apps. But it doesn\u0027t claim to be an exhaustive list of the latter, so am leaving it with SBC in the title for now.",
"parentUuid": "3acd31a7_609806c1",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3acd31a7_b18680d9",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 175,
"author": {
"id": 10707
},
"writtenOn": "2015-05-01T17:37:03Z",
"side": 1,
"message": "Gratuitous ARP does not apply for IPv6, add IPv6-related protocol references",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3afb71cf_570e8ce5",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 175,
"author": {
"id": 8711
},
"writtenOn": "2015-06-10T17:24:36Z",
"side": 1,
"message": "Added.",
"parentUuid": "3acd31a7_b18680d9",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3acd31a7_54ba7a24",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 176,
"author": {
"id": 10707
},
"writtenOn": "2015-05-01T17:37:03Z",
"side": 1,
"message": "Taking ownership of the virtual IP address implies fencing of the previously active VM, so that the formerly active VM may need to be disabled, or it cannot be disabled, that the host that it is on be fenced by rebooting or disabling of its network link, with associated impact to other VMs on the same host. Otherwise, split-brain affects may allow multiple VMs to believe they own the IP address, with poor service availability impacts.",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3afb71cf_770aa88b",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 176,
"author": {
"id": 8711
},
"writtenOn": "2015-06-10T17:24:36Z",
"side": 1,
"message": "We want the previously active VM to still be running, as it is now performing the standby role, consuming live state from the newly active VM. Perimeta uses HA heartbeats on both a dedicated HA and management network plus election mechanisms to minimise risk of split brains \u0026 IP flapping. Adding VM-controlled fencing would not help, as it would result in both trying to fence the other, leaving nothing running. A VNFM detecting a split brain could fence by using existing the OpenStack terminate VM API calls. Attempting to fence an entire host because of a single VM is surely unacceptable.",
"parentUuid": "3acd31a7_54ba7a24",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3acd31a7_b45aee28",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 181,
"author": {
"id": 10707
},
"writtenOn": "2015-05-01T17:37:03Z",
"side": 1,
"message": "To avoid network SPOF when using SRIOV, multiple SRIOV endpoints in the VM are needed, and the IP address must be movable to the endpoints. Failure detection in this case requires that the VM must have an identifiable endpoint to query to determine which of the two SRIOV interfaces to use. Several methods are available, with differing impact on infrastructure. Bidirectional Forwarding Detection (BFD) implies that the router endpoint will also query the SRIOV endpoints in the VM. Configuring that router endpoint would require OpenStack to initiate that configuration. BFD also has implications on the number of IP addresses and networks associated with the VM, as it is primarily a routing solution. Other solutions such as ARP or Neighbor Discovery can be used, with differing impacts on Router performance.",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3afb71cf_a25c6019",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 181,
"author": {
"id": 8711
},
"writtenOn": "2015-06-10T17:24:36Z",
"side": 1,
"message": "Perimeta has application level redundancy, so failure of a single SR-IOV endpoint doesn\u0027t impact service. But it can take advantage of multiple ones via bonding, though for this to be useful the different endpoints need to be on different pNICS, for which there is an active blueprint which I\u0027ve added.",
"parentUuid": "3acd31a7_b45aee28",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3acd31a7_b4cd4eb9",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 193,
"author": {
"id": 10707
},
"writtenOn": "2015-05-01T17:37:03Z",
"side": 1,
"message": "VLANs are unlikely to be the only segregation mechanism. VXLAN and NVGRE are other options, especially since NICs support these directly. In any case, unless the cloud can validate VLAN or other encapsulation on egress, this could have a security impact.",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "3afb71cf_c2751c32",
"filename": "usecases/sbc.rst",
"patchSetId": 2
},
"lineNbr": 193,
"author": {
"id": 8711
},
"writtenOn": "2015-06-10T17:24:36Z",
"side": 1,
"message": "This is fundamentally a point about there being a requirement for some scalable scheme to present a large number of networks to a VM - of order hundreds or thousands, so far in excess of the vNIC mechanism. A very common scheme, and the one Perimeta uses, is VLANs, hence requirement for VLAN trunking. Have amended text accordingly.\n\nPerimeta is itself a security product whose function is to police the traffic on the networks it serves, so bypassing normal OpenStack security group processing is not a problem in this case (though clearly may be for other applications using VLAN trunking).",
"parentUuid": "3acd31a7_b4cd4eb9",
"revId": "4ead597e2bc6731799000a5c088e2efece69441e",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
}
]
}
View Git Blame Copy Permalink