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

From: Qin Wu <[email-masked]>
Date: Wed, 5 Mar 2014 22:19:07 +0000

One additional comments I have is it looks what you specified is not service chaining info but per service function info,
Also the terminology specified in the draft is not consistent with what is specified in the sfc documents. E.g., is service node referred to as service function node or service function?
One trouble I have shall we bake the service chaining info into service topo?
In my understanding, service function can be discovered by using service topo, service function chaining can also be created or composed by using service topo.
Baking service chaining info into service topo may cause lots of update to service topo when any change happens to one or many service chains.

Regards!
-Qin
-----邮件原件-----
发件人: i2rs [mailto:[email-masked]] 代表 Dean Bogdanovic
发送时间: 2014年2月27日 4:24
收件人: Jeffrey Haas
抄送: <[email-masked]>; <[email-masked]>; <[email-masked]>
主题: Re: [i2rs] Comments on draft-bitar-i2rs-service-chaining-01

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:

> 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-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> 

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