Some thoughts on draft-bitar-i2rs-service-chaining-01... == This document describes use cases and I2RS (Information to the Rousting System) requirements for the discovery and maintenance of services topology and resources. ==
Rousting/Routing == Several networking scenarios involve applying a set of services to a packet or flow. For instance, when a host in a protected zone initiates a session to a server outside the zone, the session may be directed to a chain of a Wide Area Network (WAN) application acceleration service, a network address and port translation (NAPT) service, and a firewall. On the server side, another set of services may also be applied. Such a sequence of services applied to a packet or flow is referred to as a service chain. Services in the chain may include deep packet inspection (DPI), load-balancing, firewalling, intrusion prevention, and routing among others. == I found this paragraph confusing... Maybe something more like: Several network designs require flows to be processed through a set of services located in different locations. For instance, when a host in a protected zone initiates a session to a server outside that protected zone, the flow might need to pass through an application acceleration service, a network address translation service, and a stateful (or deep packet) inspection service. The corresponding flow from the server to the initiating host might be required to pass through another set of services, such as load balancing, stateful inspection, and intrusion prevention. == The tuple (service node IP address, hosting system IP address). This applies when there is need to identify the system hosting the service node or when the service node IP address is only reachable within the hosting system. == "there is need" should be "there is a need" I'm not certain about the two IP addresses here. Which "hosting system IP address?" Do you mean the address of the hypervisor, or the physical interface (if it has one), or... ?? This might need clarification. == For each service node, virtual context and service type, the following information may be specified, depending on the service resource requirement. That is, some of the information listed here may not be relevant for some services. == You might want to add stretch and utilization (both network and per link) here. Both of these are impacted by/rely on traffic engineering. == The following is a set of parameters that needs be monitored per service node per virtual context, and per service type as applicable. It should be noted that some services may not require all the parameters listed here to be monitored. == For which section of the network? The smallest link between the source and the destination, the link between the service and the default gateway, or first hop device (router or switch), the bandwidth of the fabric, etc. ... ? I think this probably needs some clarification. == Service Chaining via BGP-based Redirection == I'm really confused by this section. Why should BGP flow spec be specifically called out here? Either cover all of the different options (flowspec, YANG, etc.), or justify including one and not the others, I think. HTH :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
