Hi, again:
Regarding Issue of OAM information Gathering from Service Function described in 
section 4.6,
“
   When the service packets is steered through a set of service nodes
   distributed in the network, each service node work at different
   layers above layer 3 and may have several SFs collocated with itself.
   When OAM mechanism is applied, it is necessary to allow OAM packet
   exchanged between these service nodes or service function at
   different layers. when Service function involved in the SFC doesn't
   support OAM capability(e.g., SF is SFC-unaware service function),
   Service node should be responsible for monitor and diagnose the
   Service function and check service availability to these service
   function.  It is more desirable to allow service function register to
   service node.  Either service function report status to service node
   or service node perform live check to these service function.

   In addition, service functions usually don't have Layer 2-3 switching/
   routing capability and therefore are not aware of any OAM function at
   layer 2-3.  Also when there is no OAM functions at service layers at
   top of layer 3, it is hard to identify layer that can be used to
   gather OAM information when it comes to a fault situation or
   degradation of performance.  For example, when a data packet is
   transmitted from one service function to another service function and
   the data packet may be lost between two service functions or
   discarded by either of service function, assume two service functions
   are embedded in two different service nodes, how to detect the fault
   between them and how to isolate problem to that layer?
”
As you said, The above text can be presented as an example to illustrate a 
problem not a problem per section.
I agree it is too much specific to SFC case. I am expecting to cover overlay 
OAM case as well.

In the overlay OAM, When any Overlay Segment fails to deliver user traffic, 
there is a
need to provide a tool that would enable users to detect such
failures, and a mechanism to isolate faults.  It may also be
desirable to test the data path before mapping user traffic to the
Overlay Segment.

I will see how to abstract common issue from both SFC case and Overlay OAM case.
Yes, we really need a use case draft to discuss what these use case look like 
and provide high-level requirements
To support various use cases.

Regards!
-Qin
发件人: [email protected]<mailto:[email protected]> 
[mailto:[email protected]]
发送时间: 2014年6月24日 22:13
收件人: Qin Wu
主题: RE: Unified oam BOF proposal request in IETF 90

Hi Qin,

Please find attached a first set of comments.

Cheers,
Med
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to