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 protected]> wrote:
> 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
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
