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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Feb 2014 21:50:38 -0500

A very cleanly written draft, thank you.

One question I had was prompted by section 3.2 - monitoring information.  In
this case, the ability to take actions during service node failure or
notification that capacity has been exceeded was mentioned.  Is part of the
use case potentially replicating necessary state to the new and/or backup
nodes to be able to attempt to handle such failover hitlessly?  If so, that
would potentially expand the information being monitored.

The section following that covers a set of information that may be monitored
at the physical server level.  One obvious component in the list that seems
to be missing would be temperature.  That does beg the question as to
whether your parameters requiring monitoring should be generally expanded to
many of the same things already covered by various physical monitoring
mechanisms already deployed.  For another example, fan speeds.  Perhaps
instead it might be suggested that server physical/electrical
characteristics should be part of the monitoring information and not worry
about enumerating them directly?

Section 3.2 also somewhat hints at the ability to migrate functionality for
service nodes as a general purpose behavior.  While I suspect it's a bit out
of scope for this use case document, making use of i2rs to help handle
virtual server migration seems an obvious related use case.

Section 3.3 makes me want to ask the following question to the authors of
this draft and the authors of draft-chen-i2rs-ts-use-case: While the use
cases are very targeted in the servicing chaining draft, there appears to be
significant overlap in the underlying requirements for traffic steering.
Should these drafts potentially have their use cases merged?

-- Jeff

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 26 Feb 2014 20:24:17 +0000

Nabil,

In section 3.2 there is a typo 

Packet rate utilization per Cos		s/Cos/CoS

it makes it consistent with rest of the document

In section 3.3 Traffic Redirection, Fwd and Service Chaining, it would be interesting to see how it can be used with use cases below

Subscriber Awareness - how to apply per subscriber policies by keeping the contextual information that is not locally available
Fine-Grained Policies - support fine grained policies without having many chains (routing packets differently through service topology)
Application Awareness - avoiding repetition of expensive operations (once the flow is identified, don't send it to DPI anymore)

I was able to go through top 2 scenarios, but had some trouble with the last scenario. 

Also in the same section, 

In all cases, if
        the state is not kept in a persistent storage on the forwarding
        system(s), system reboot actions will trigger the need for a
        high provisioning rate, on the order at few thousands per
        second.
That is to be expected, as device coming up with previous state, it can't know if the policies are still valid. Example, two subscribers with different policies have updated their IP address port combinations and wrong policies are applied to their traffic.

Dean
             
On Feb 25, 2014, at 9:50 PM, Jeffrey Haas <[email-masked]> wrote:

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
> 
>