Subject: [sfc] OAM discussion....

From: David Allan I <[email-masked]>
Date: Tue, 11 Nov 2014 21:21:44 +0000

Hi

A recap of my comments stated and unstated at the mike.....

1)      We need to sort out and document the difference between what can be achieved by explicit protocol design, and what requires impersonation of application traffic by a "golden customer" or similar concept. The latter requiring some larger wrapper that encapsulates the SFC infrastructure and can inject and measure non-OAM application impersonating traffic.

IMO there is nothing about an SF can be usefully tested by a specific OAM protocol as it will not fate share with any aspect of the function as the SF will be application specific and the OAM won't be. So there is no point in trying/pretending. IMO a specific OAM protocol should be able to verify the service graph for a given SFP and that is about it, and we should focus on what aspects of the infrastructure that can be tested via explicit protocol design. IMO that would be limited to aspects of path configuration and fault management. Performance measurement being impossible.

2)      As for the Golden Customer concept, Luca raised a good point that such traffic should not be able to leak into the larger network. MPLS OAM uses the 127/8 prefix to do this. So solutions exist.

3)      The language needs a bit of work. At first I found it incomprehensible, primary because of the abuse of the term "availability". To an OAM guy, availability is a "metric" (e.g. 99.993% uptime), and not a "state". Reading the document suggests that "availability" is really referring to a "state".

That being said I highly suspect that it will provide impossible to define an availability metric or set of metrics for a service function path (purpose being customer facing) or an individual service function (purpose being supplier auditing) although I could see a business rationale for trying ;-)...

4)      What we could consider would be a framework whereby vendors could offer test scripts for the "golden customer" (treating the chain as a black box DUT) IF the group believes such functionality is ultimately required. I'm not sure we would really want to standardize this vs. simply suggest the possibility and leave it to SF providers to sort out.

That's the view from here
Dave