Subject: [i2rs] Thoughts on draft-bitar-i2rs-service-chaining-01

From: "Russ White" <[email-masked]>
Date: Fri, 25 Apr 2014 09:46:28 -0400

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