Subject: Re: [sfc] Mail regarding draft-aldrin-sfc-oam-framework

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 3 Dec 2014 22:53:38 +0000

Hi Deepak,

Thanks for providing comments and apologies for this very delayed response.

Please see in-line with [NOBO].

> -----Original Message-----
> From: Deepak Kumar (dekumar)
> Sent: Tuesday, November 11, 2014 3:32 PM
> To: [email-masked]; [email-masked]
> Subject: Mail regarding draft-aldrin-sfc-oam-framework
> 
> Hi,
> 
> In section 2. SFC Layering Model
> 
> We have Service Layer which can also be broken down in the layers as
> within a service Function chain we can have multiple SFPs due to one of the
> SFF changing the classifier.

[NOBO] You rightfully pointed out the absence of re-classification from the document. This is a topic that needs to be covered as part of this document and the Authors have been discussing this. Two approaches:

(1) Classification point initiates the OAM to test the original SFP, and re-classification point initiates the OAM to test the altered SFP.
(2) Classification point initiates the OAM to test the SFP and the re-classification is simply treated as a branch (thus branch discovery/traversal will be able to exercise the altered SFP).

Authors are leaning towards (1) as the model we should pursue, but we can use some input from the WG on this topic.

> 
> In Section 3.1 we are mentioning Availability which I am not sure is right
> term as performance management has concept of Availability also as a SLA,
> as for customer finding loss is not that important SLA but important SLA is
> availability and unavailability of the flow over time as that's the SLA that can
> be sold.

[NOBO] The usage of term will be made coherent with terminology of RFC7276. Additionally, you've highlighted the potential benefit of this document having the terminology section.

[NOBO] With that said, the statement "... customer finding loss is not that important" from above is something that we should discuss. A complete outage (i.e. lack of reachability) is obviously bad, but random/sporadic/intermittent packet losses can also be bad. However, I don't the it's the job of this document to describe how bad they are, but to describe the framework of how they can be detected. So unless you think something is not important at all to the SFC OAM, this document should describe the framework for it. Thoughts?

> 
> To find faults in real time Alarm Indication Signal technique or notification
> should also be considered, eg:- within a service function chain, one of the
> SFF/SF is restarted and this belong to multiple SFC chain.

[NOBO] The Continuity Check of the SFF/SF will allow SFC-aware entities to detect the outage, this will allow the classifier to select another SFP or the upstream SFF to select another NHOP SF. When you say "real time Alarm Indication", can you clarify which do you mean:

(a) An SFC-aware entity to detect an outage and notify the outage alarm to other SFC-aware entities.
(b) An SFC-aware entity to detect an outage and notify the outage alarm to the upper layer on the same entity (i.e., management layer).

> 
> In section 3.1.2 - This should be extended to say that protocol should be
> able to provide the SLAs instead of delay, and loss calculation. Just loss
> calculation is not enough to determine availability of circuit.

[NOBO] Hopefully this comment will be addressed by adding the terminology section in this document. What we (Authors) are trying to achieve is to describe the SFC OAM Framework for Continuity Check (CC), Connectivity Verification (CV) and Performance Measurement (PM). CC is responsible for detecting the complete outage. PM is responsible for detecting loss/delay measurements.

> 
> In section 4.1
> 
> We should also add verify packet re-ordering and corruption in
> unidrirectional connection.
> Also we should say "Proactively and on-demand" test alternate or protected
> paths to ensure reliability of network configuration.

[NOBO] Proactive and on demand are continuity and connectivity functions. As far as packet re-ordering etc, these are different mechanisms or toolset which could be built on top of the 'SFC OAM'. I do not see any need to re-define things like OWAMP/TWAMP mechanisms here, as they could be used here as well.

> 
> On Section 4.4 same Performance has to be extended.
> Even for Performance we should have both proactive and on-demain
> support from the protocool to be developer later.

[NOBO] Same comment as above.

> 
> Most of the time Performance Measurement fails because OAM packet
> doesn't take the same path as data path and also where the timestamping or
> delay is measured. As "O" bit is in the header protocol has to be defined
> such that "o" bit is not checked in middle of network.

[NOBO] Yes agree, and this is what we specified in the slide presented at the IETF91. We will be porting some contents from the slide to the document in the next revision. In essence:

- If there is ECMP at the service layer, then the OAM must be able to reliably verify each and all the ECMP paths that data packets take
- The SFF load balancing logic applied to both types of packets (OAM and data) should be the same to preserve the in-band characteristics of OAM

> 
> Framework should atleast talk about Measurement Point.

[NOBO] ACK.

Thanks!

-Nobo, on behalf of authors

> Thanks,
> Deepak