Subject: Re: [sfc] OAM discussion....

From: Sam Aldrin <[email-masked]>
Date: Wed, 3 Dec 2014 10:15:53 -0800

Hi Dave,

Thanks for your comments, both at the mic and recap via email. Sorry for the delay in responding to your email. Please find responses inline.

> On Nov 11, 2014, at 1:21 PM, David Allan I <[email-masked]> wrote:
> 
> 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.
There are two aspects, w.r.t. SFC.
1. Describing the SFC OAM framework aspects and requirements and
2. (to your point), what should/could be achieved by explicit protocol design. 

Whether one could achieve with actual traffic or synthetic traffic will be part of the solution and this document is not proscribing it. This is one aspect, we as a WG should ensure the SFC architecture and protocol design work is coherent with SFC OAM requirements. Agree to your concern and we do understand the implications with mimicing traffic to test SF.
>  
> 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.

I do hope the document is not creating any incorrect presumption of what SFC OAM is pretending to be. If so, we welcome suggestion for changes and will be happy to accommodate it. As presented at IETF, SFC OAM only care whether SF is ‘up' or not.
>  
> 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.

This is fundamental design of all OAM protocols within IETF and SFC OAM doesn’t change the definition either. Intact, MPLS OAM uses lot more, not just local host address, so as not to leak beyond the boundary. VCCV is also another example.
>  
> 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”. 

Nod. Will definitely confirm to the RFC7276, which specifies the OAM terminology, in the next version.
>  
> 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.

If it requires interoperability across vendor land, definitely worth deliberating. If not, we could leave it to ‘winter vendor land :D

Cheers
-sam

>  
> That’s the view from here
> Dave
> _______________________________________________
> sfc mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>

---

From: David Allan I <[email-masked]>
Date: Wed, 3 Dec 2014 18:46:32 +0000

HI Sam:

You wrote….

Thanks for the reply, comments in line

Whether one could achieve with actual traffic or synthetic traffic will be part of the solution and this document is not proscribing it.
This is one aspect, we as a WG should ensure the SFC architecture and protocol design work is coherent with SFC OAM requirements. Agree to your concern and we do understand the implications with mimicing traffic to test SF.

My concern is ensuring the requirements are realistic. And as a framework, I would presume the overall solution space would need to be explored to some degree.

At this point I’m not sure that without synthetic traffic, any representation as to the state of an SF can be made. Any OAM specific protocol can only detect gross defects and (for example) trace SFF hops in any path that does not modify the SFP information (else all bets are off).

Any synthetic traffic may require a complex and “SF-unique” series of steps to verify SF function, to the point where other than being an “on-demand” tool, it may not be practical in a production environment. (which gets to my comment on availability measurements).

Agreed…

OK, great.

I’m not sure interoperability is the correct term, …. A multi-vendor environment would place the onus on verifying system integrity on the deploying entity, and thus would likely benefit from some kind of agreed scripting language/model (oh dear, here we go…..), but then existing test sets are probably capable of this such that the SFC operator may simply dictate the requirement to their suppliers (I’ve insufficient knowledge to authoritatively comment).

BR Dave

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 4 Dec 2014 23:20:45 -0800

Hi Dave,

Thanks.
Response inline with %sam.
> On Dec 3, 2014, at 10:46 AM, David Allan I <[email-masked]> wrote:
> 
> HI Sam:
>  
> You wrote….
%sam - Will try to improve upon text in the next version. Would welcome any suggested text to refine the draft.
> At this point I’m not sure that without synthetic traffic, any representation as to the state of an SF can be made. Any OAM specific protocol can only detect gross defects and (for example) trace S…
I may agree, but may not 100%, reason being, the SFC protocol itself is not defined, yet. If there are mechanisms available within the header or metadata or something else, SFC OAM could leverage that.

> Any synthetic traffic may require a complex and “SF-unique” series of steps to verify SF function, to the point where other than being an “on-demand” tool, it may not be practical in a production e…
On-demand is part of the SFC OAM tool set. One could model the solution along the lines of how MPLS OAM on-demand tooling did.
Other than that, I agree that it is complex. If it is that simple, we could have created solution before the problem itself  </jk> :D
> I’m not sure interoperability is the correct term, …. A multi-vendor environment would place the onus on verifying system integrity on the deploying entity, and thus would likely benefit from some…
From SFC perspective, the chain has to be verified and validated. This document may not be able to mandate any to SF as such. One thing we could do is to document the text on what could help SFC operators in order to ensure the chained services perform as configured. The only concern I have in that case is, where to draw the line. Hope we could get some input from WG as well.

-sam