Subject: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 4 Aug 2015 00:11:46 +0000

Greetings WG:

This message begins a 2 week call for WG adoption of the document https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/ ending 17th August 2015.

Please respond to the SFC mailing list with any statements of approval or disapproval.

As always please note the following:

  1.  This is not a WG last call. The document is not final, and the WG is expected to modify the document’s content until there is WG consensus that the content is solid. Therefore, please do not oppose adoption just because you want to see changes to its content.
  2.  If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
  3.  If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.

Jim & Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 3 Aug 2015 20:15:08 -0400

I support adoption of this draft.  We are getting a lot of piece-part 
proposals toward OAM.  Without a big-picture document, it is extremely 
likely that the pieces will not work together, and that some imnportant 
aspects will be missed.

(And yes, I helped write earlier drafts that went into this one.)

Yours,
Joel

On 8/3/15 8:11 PM, Jim Guichard (jguichar) wrote:
> Greetings WG:
>
> This message begins a 2 week call for WG adoption of the document
> https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/ ending
> 17th August 2015.
>
>  1. This is not a WG last call. The document is not final, and the WG is
>     expected to modify the document’s content until there is WG
>     consensus that the content is solid. Therefore, please do not oppose
>     adoption just because you want to see changes to its content.
>  2. If you have objections to adoption of the document, please state
>     your reasons why, and explain what it would take to address your
>     concerns.
>  3. If you have issues with the content, by all means raise those issues
>     and we can begin a dialog about how best to address them.
>
> Finally, now is also a good time to poll for knowledge of any IPR that
> applies to this draft, in line with the IPR disclosure obligations for
> WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as a document author please respond to this email (to
> the chairs) whether or not you are aware of any relevant IPR.
>
> Jim & Thomas
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 4 Aug 2015 08:14:49 +0000

Hi,

Being in the same position as Joel (in terms of having contributed to earlier versions) I share his opinion on the need of an OAM big-picture document, and support adoption.

Be goode,

On 4 Aug 2015, at 02:15 , Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

I support adoption of this draft.  We are getting a lot of piece-part proposals toward OAM.  Without a big-picture document, it is extremely likely that the pieces will not work together, and that some imnportant aspects will be missed.

Yours,
Joel

Please respond to the SFC mailing list with any statements of approval
or disapproval.

Jim & Thomas

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: [email-masked]
Date: Tue, 4 Aug 2015 16:36:40 +0800

I support adoption of this draft. 

But I have an issue, maybe the authors can help me out about the following 
issue:)

In the (1. Service function) paragraph of section 3, it mentions that SFC 
OAM must be able to 
monitor the SFF associated with a given SF. In fact, I totally agree with 
this consideration:
SFFs should be monitored in SFC OAM. But, this consideration is not 
properly illustrated in the Figure 2. 
By the way, another document of mine (
https://tools.ietf.org/id/draft-wang-sfc-multi-layer-oam-02.txt)
also mentioned the SFC OAM between SFFs. 

And also, I saw there is a SFC OAM between Controller and SF3. Could you 
explain this kind of 
SFC OAM in this document? 

Thanks very much:)

Best Regards,
Linda Wang

"sfc" <[email-masked]> 写于 2015-08-04 08:11:46:

> "Jim Guichard (jguichar)" <[email-masked]> 
> 发件人:  "sfc" <[email-masked]>
> 
> 2015-08-04 08:11
> 
> 收件人
> 
> "[email-masked]" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> [sfc] WG adoption of draft-aldrin-sfc-oam-framework
> 
> Greetings WG:
> 
> https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/ 
> ending 17th August 2015.
> 
> 1. This is not a WG last call. The document is not final, and the WG
> is expected to modify the document’s content until there is WG 
concerns.
> 3. If you have issues with the content, by all means raise those 
> issues and we can begin a dialog about how best to address them.
> Finally, now is also a good time to poll for knowledge of any IPR 
> that applies to this draft, in line with the IPR disclosure 
> obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 
> for more details). If you are listed as a document author please 
> respond to this email (to the chairs) whether or not you are aware 
> of any relevant IPR.
> 
> Jim & Thomas_______________________________________________
> sfc mailing list
> [email-masked]

---

From: Ron Parker <[email-masked]>
Date: Tue, 4 Aug 2015 13:34:43 +0000

Conditionally approve adoption, but with significant and editorial issues that should be addressed first.

   Ron

1.       Regarding the following excerpt, SFF's should be explicitly mentioned.   The text, "from one SF to the next" can not be contextualized without the SFF.

 o  The service layer, refered to as the "Service Layer" in Figure 1,
      consists of classifiers and SFs, and uses the
      transport network, which could be an overlay network, from a
      classifier to SF and from one SF to the next.

2.      Regarding the following text, SFF needs to be worked in.

The network overlay transport layer, refer to as the "Network",
      "Transport" and layers below in Figure 1, extends between the
      various SFs and is mostly transparent to the SFs themselves.  It
      can leverage various overlay network technologies
      interconnecting SFs and allows establishment of
      service function paths (SFPs).

3.      In figure 1, the SFF needs to be worked in.

4.      In section 3, subpoint 1, the following text is incorrect wrt SFF - there should not be a supposition that an SFC aware SF is co-resident with an SFF

An SFC-aware SF is one that
   understands the SFC encapsulation has the SFF component co-resident with
   the SF sub-component .

5.      Also in section 3, suppoint 1, the following text is making an incorrect distinction about SFC-unaware SF wrt SFF and is stating that an SFC proxy MAY be required but in reality the architecture holds that an SFC proxy MUST be utilized
An SFC-unware SF is one that does not understand
   the SFC encapsulation (i.e. a legacy SF) and has to be accessed via an
   separate SFF and potentially an SFC proxy function.

6.      Figure 2 must work in the SFFs.

7.      Section 3.1.1 states that SF's are monitored indirectly by monitoring their SFF's.   Does this mean that the SFF's necessarily forward OAM packets to SF's or does it mean that the SFF's are performing some higher level summarization/aggregation of SF health and intercepting OAM packets?   In other words, would SFC-aware SF's ever directly process OAM packets?    Additionally, how do you handle cases where an SFC-aware SF is multiply homed to more than one SFF?

8.      Section 3.1.2 Service Function Performance - this states that loss and delay are checked at an individual SF.   Can we expand this to include SFF's, too?   Is this loss/delay characterization at an RSP level (thus accounting for multiply homed SF's)?   Also, consider adding misordering characterization.

9.      Section 3.2.2 - suggest adding misordering, too.

10.   In section 4, please clarify the following sentence

In order to
   support SFC and SF's, these functions have to be enhanced to operate
   a single SF to multiple SF's in an SFC and also multiple SFC's.

11.   In section 4.1, the requirement to probe MTU size - what is the motivation for including this vs. simply relying on layer 3 PMTU procedures?   Is the supposition that transport will not always be IP-layer?

12.   In section 4.1, "verify the packet re-ordering and corruption" - Is this stating that OAM packets should be able to retrieve counts of corrupted non-OAM packets from SF's and SFF's or that OAM packets can directly discern corruption?    Does it imply that a hash mac or similar must be applied to every OAM packet?   Every non-OAM packet?

13.   In section 4.2, please clarify the following sentence:

   o  Notifying the failure upon failure detection for other OAM
      functions to take appropriate action.

14.   Section 4.4, Performance measurement.   Suggest including SFF in the descriptive text.

15.   In section 5.1, table 1, suggest including SFF and classifier.

16.   In section 5.3, the following statement implies that management of SFC functions is different when these functions are virtualized.   This isn't strictly true.

With
   virtualized SF and SFC, manageability of these functions has to be
   done programmatically.

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, August 3, 2015 8:12 PM
To: [email-masked]
Subject: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Greetings WG:

  1.  This is not a WG last call. The document is not final, and the WG is expected to modify the document's content until there is WG consensus that the content is solid. Therefore, please do not oppose adoption just because you want to see changes to its content.
  2.  If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
  3.  If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.
Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.

Jim & Thomas

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 6 Aug 2015 10:02:09 +0000

Jim, Thomas,

I support adoption, as co-author.

I am not aware of any IPR related to draft-aldrin-sfc-oam-framework.

I believe we still need to work out some terminology usage in this draft, but nothing better than WG adoption to focus on it. This document presents a solid start for the WG to compile all the OAM threads in a reference framework.

Thanks,

— Carlos.

> On Aug 4, 2015, at 2:11 AM, Jim Guichard (jguichar) <[email-masked]> wrote:
> 
> Greetings WG:
> 
> This message begins a 2 week call for WG adoption of the document https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/ <https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/> ending 17th August 2015.
> 
> This is not a WG last call. The document is not final, and the WG is expected to modify the document’s content until there is WG consensus that the content is solid. Therefore, please do not oppose adoption just because you want to see changes to its content.
> If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
> If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

---

From: <[email-masked]>
Date: Thu, 6 Aug 2015 22:45:30 -0500

I also support as co-author. I am not aware of any related IPR.

Thanks,
Ramki

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, August 06, 2015 3:02 AM
To: Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Jim, Thomas,

Thanks,

- Carlos.

On Aug 4, 2015, at 2:11 AM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Greetings WG:

Jim & Thomas

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Fri, 7 Aug 2015 08:27:13 +0000

Hello,
I read the draft and I support the adoption of this document as a WG document.

I have a question on section 3.3 "Monitoring the Classifier":

"SFC OAM must be able to test the definition of
   flows and the mapping functionality to expected SFCs"

Is testing the mapping of flows to SFCs an OAM function?
As far as I know there are no classical/standard tools to perform such test.
In  my opinion if you consider the monitoring of classifier an OAM function, it should be included in the gap analysis as missing functions in section 5.

Thanks
Roberta

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 04, 2015 2:12 AM
To: [email-masked]
Subject: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Greetings WG:

Jim & Thomas

---

From: Loa Andersson <[email-masked]>
Date: Fri, 07 Aug 2015 11:29:33 +0200

WG,

Read the draft and support the adoption as a wg document.

/Loa

On 2015-08-07 10:27, Roberta Maglione (robmgl) wrote:
> I have a question on section 3.3 “Monitoring the Classifier”:
>
> “SFC OAM must be able to test the definition of
>
>     flows and the mapping functionality to expected SFCs”
>
> In  my opinion if you consider the monitoring of classifier an OAM
> function, it should be included in the gap analysis as missing functions
> in section 5.
>
> Thanks
>
> Roberta
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* Tuesday, August 04, 2015 2:12 AM
> *To:* [email-masked]
> *Subject:* [sfc] WG adoption of draft-aldrin-sfc-oam-framework
>
> Greetings WG:
>

---

From: "Zhulei (MBB Research)" <[email-masked]>
Date: Fri, 7 Aug 2015 09:41:27 +0000

Apologize not to reply earlier. Will support to adoption of this document.

As what we discussed, SFC OAM is a problem to address within SFC architecture. What even mentioned it in SFC architecture document, there are still architectural issues for OAM problems to illustrate in an aspect document. So, a support to adoption of document is the essential step to move on the works to content.

Best regards,
Zhu Lei
Huawei Technologies.

发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2015年8月4日 8:12
收件人: [email-masked]
主题: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Greetings WG:

Jim & Thomas

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 7 Aug 2015 13:16:51 +0000

Hi,

I support the adoption as WG document.

Thanks,
Nagendra

发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2015年8月4日 8:12
收件人: [email-masked]<mailto:[email-masked]>
主题: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Greetings WG:

Jim & Thomas

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 7 Aug 2015 08:00:48 -0700

This document provides a framework for the solution document, which were already being published.
Hence, I support this document to be adopted as WG document.
I am a co-author on this and not aware of any IPR related to this document.

cheers
-sam

> On Aug 3, 2015, at 5:11 PM, Jim Guichard (jguichar) <[email-masked]> wrote:
> 
> Greetings WG:
>

---

From: Qin Wu <[email-masked]>
Date: Sat, 8 Aug 2015 02:24:28 +0000

Support. I believe this draft will lay foundation for solution work.

-Qin
On Aug 3, 2015, at 5:11 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Greetings WG:

Jim & Thomas

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 9 Aug 2015 17:07:38 -0700

Support (as co-author) and I'm not aware of any IPR.

Anoop

On Mon, Aug 3, 2015 at 5:11 PM, Jim Guichard (jguichar) <[email-masked]>
wrote:

>    is expected to modify the document’s content until there is WG consensus
>    that the content is solid. Therefore, please do not oppose adoption just
>    because you want to see changes to its content.
>    your reasons why, and explain what it would take to address your concerns.
> applies to this draft, in line with the IPR disclosure obligations for WG
> participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you
> are listed as a document author please respond to this email (to the
> chairs) whether or not you are aware of any relevant IPR.
>
> Jim & Thomas
>

---

From: Georgios Karagiannis <[email-masked]>
Date: Mon, 10 Aug 2015 08:31:46 +0000

Hi all,

Please note that I have read the document and I support the SFC WG adoption of this draft.

Best regards,
Georgios

From: sfc [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: 07 August 2015 17:01
To: Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

cheers
-sam

Greetings WG:

Jim & Thomas

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Aug 2015 20:07:29 +0000

I'm having trouble understanding what is being proposed as the framework.
Currently it seems to be a list of requirements for a framework, not a framework.
Is that the intention? Rename it to "Requirements for OAM Frameworks" or "Terminology for OAM Frameworks" ?

There are also some inconsistencies that confuse me about the purpose of the document:
On one hand, it says SFP operation needs to be monitored (including performance and packet loss/reordering), but on the other hand it says monitoring "operation of an SF is beyond the scope of SFC OAM". How could monitoring be meaningful without involving the SFs?
So it isn't clear whether the framework is intended to use in-band packets or a control plane, since in-band packets would surely traverse the SFs.
Other language indicates all ECMP paths must be traversed, which sounds like in-band.

SFs are claimed to be out of scope; however, figure 2 seems to show a control-plane protocol (SFCOAM) speaking directly to SFs.

If this document is just about requirements, I could support adoption assuming the above issues can be clarified; otherwise as a framework I don't see anything concrete yet, so I can't figure out where this is going.

E.g., if the framework is intended to provide in-band testing, concrete language would talk about where packets are injected, what the packet format is, what each type of element is expected to do with the packet (count, forward, reflect, append trace-route info).

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, August 03, 2015 8:12 PM
To: [email-masked]
Subject: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Greetings WG:

Jim & Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Aug 2015 16:22:40 -0400

It is not necessarily the case that in-band OAM packets will traverse 
the Service Functions.
In fact, arranging things so that OAM packets will pass through service 
functions successfully is hard, and would place a significant new 
requirement on NSH aware service functions.
In addition, by virtue of that requirement, the packets would probably 
not test the important parts of the service functions.

Thus, in my view, it is much better to leave the determination of what 
it means to test service functions, and how to achieve that, to at least 
a separate document, and probably separate mechanisms from those 
concerned with testing the service function paths.

Yours,
Joel M. Halpern

On 8/12/15 4:07 PM, Dave Dolson wrote:
...
> On one hand, it says SFP operation needs to be monitored (including
> performance and packet loss/reordering), but on the other hand it says
> monitoring “operation of an SF is beyond the scope of SFC OAM”. How
> could monitoring be meaningful without involving the SFs?
>
> So it isn’t clear whether the framework is intended to use in-band
> packets or a control plane, since in-band packets would surely traverse
> the SFs.
...

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Aug 2015 20:31:10 +0000

I agree if the in-band packet is, for example, a TCP packet. Behavior would be entirely SF-dependent (firewall drop, NAT modify, ...)

However, if an NSH OAM packet (with O-flag set) is received by an SF, the defined behavior could be to forward it (along with count, reflect, append trace-route info, etc.) The NSH OAM packet doesn't even need to include an IP packet within it. This could provide valuable connectivity and liveliness information.

A framework could define such behavior as mandatory. But the document doesn't say anything like that.

-Dave

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2015 4:23 PM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Yours,
Joel M. Halpern

> monitoring "operation of an SF is beyond the scope of SFC OAM". How
> So it isn't clear whether the framework is intended to use in-band
...

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 12 Aug 2015 16:34:15 -0400

We could define that.  We may even have to define that sort of service 
function behavior.  (I hope not.)
I would not consider that to be testing the service function.  It tests 
that some part of the software is alive, but does not tell you anything 
more than that.

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 12 Aug 2015 20:40:04 +0000

We did that in the SFC traceroute draft and its associated implementation. I agree it does not test specific 'rules' inside SF but otherwise it became an indispensable tool. 

> On Aug 12, 2015, at 10:34 AM, Joel Halpern Direct <[email-masked]> wrote:
> 
> We could define that.  We may even have to define that sort of service function behavior.  (I hope not.)
> I would not consider that to be testing the service function.  It tests that some part of the software is alive, but does not tell you anything more than that.
> 
> Yours,
> Joel
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Aug 2015 20:42:36 +0000

I think it is useful to test the paths between SFF and SF. There are definitely some failures and overload situations that could be detected.

Actually, I think the NSH document is the correct place to define the OAM behaviors as part of the protocol.

The framework document should discuss how this tool should be used to monitor a network.

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2015 4:34 PM
To: Dave Dolson; Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Aug 2015 16:45:57 -0400

The distinction I am trying to draw is between testing connectivity to 
and between service functions, which does seem appropriate; and testing 
the proper functioning of the service functions in the path, which I 
believe should be out of scope.

If you can propose better wording to make that clear, that would be helpful.

Note that even connectivity to the SF may be monitored better by other 
means.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Aug 2015 20:48:00 +0000

I agree that is a useful distinction of scope.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2015 4:46 PM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 13 Aug 2015 09:36:56 +0000

Hi Dave,

FWIW, there is an open ticket for this issue in the nsh draft. See http://trac.tools.ietf.org/wg/sfc/trac/ticket/10 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Dave Dolson
> Envoyé : mercredi 12 août 2015 22:43
> À : Joel Halpern Direct; Joel M. Halpern
> Cc : [email-masked]
> Objet : Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework
> 
> I think it is useful to test the paths between SFF and SF. There are
> definitely some failures and overload situations that could be detected.
> 
> > I agree if the in-band packet is, for example, a TCP packet. Behavior
> would be entirely SF-dependent (firewall drop, NAT modify, ...)
> >
> > However, if an NSH OAM packet (with O-flag set) is received by an SF,
> the defined behavior could be to forward it (along with count, reflect,
> append trace-route info, etc.) The NSH OAM packet doesn't even need to
> include an IP packet within it. This could provide valuable connectivity
> and liveliness information.
> >

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Aug 2015 23:45:09 +0000

Joel, 

Agree that testing the connectivity to and from Service Functions is appropriate. 
 
Will "testing connectivity between Service Functions" be included? It might require all those deployed service functions to be upgraded. 

Linda 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, August 12, 2015 3:46 PM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

The distinction I am trying to draw is between testing connectivity to and between service functions, which does seem appropriate; and testing the proper functioning of the service functions in the path, which I believe should be out of scope.

Note that even connectivity to the SF may be monitored better by other means.

Yours,
Joel

On 8/12/15 4:42 PM, Dave Dolson wrote:
> function behavior.  (I hope not.) I would not consider that to be 
> testing the service function.  It tests that some part of the software 
> is alive, but does not tell you anything more than that.
>
> Yours,
> Joel
>
>> In fact, arranging things so that OAM packets will pass through 
>> service functions successfully is hard, and would place a significant 
>> new requirement on NSH aware service functions.
>> In addition, by virtue of that requirement, the packets would 
>> probably not test the important parts of the service functions.
>>
>> Thus, in my view, it is much better to leave the determination of 
>> what it means to test service functions, and how to achieve that, to 
>> at least a separate document, and probably separate mechanisms from 
>> those concerned with testing the service function paths.
>>
>> Yours,
>> Joel M. Halpern
>>
>>> performance and packet loss/reordering), but on the other hand it 
>>> says monitoring "operation of an SF is beyond the scope of SFC OAM". 
>>> How could monitoring be meaningful without involving the SFs?
>>>
>>> packets or a control plane, since in-band packets would surely 
>>> traverse the SFs.
>> ...
>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 14 Aug 2015 19:47:35 -0400

I am not sure what you are asking Linda.  The whole point of testing the 
SFP is to test the forwarding that runs between service functions.
Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Aug 2015 23:59:31 +0000

Joel, 

Based on the SFC architecture, multiple SFs are connected to SFFs. So the connectivity testing is between SFF and SFs, instead between SFs. 
So the SFP connectivity is from the angle that SFF is connected to the SFs, and the SFFs are connected, instead of testing if the SFs are connected. That is how I look at it. 

Linda
 
-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Friday, August 14, 2015 6:48 PM
To: Linda Dunbar; Joel M. Halpern; Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

I am not sure what you are asking Linda.  The whole point of testing the SFP is to test the forwarding that runs between service functions.
Yours,
Joel

On 8/14/15 7:45 PM, Linda Dunbar wrote:
>> We could define that.  We may even have to define that sort of 
>> service function behavior.  (I hope not.) I would not consider that 
>> to be testing the service function.  It tests that some part of the 
>> software is alive, but does not tell you anything more than that.
>>
>> Yours,
>> Joel
>>
>>> I agree if the in-band packet is, for example, a TCP packet. 
>>> Behavior would be entirely SF-dependent (firewall drop, NAT modify, 
>>> ...)
>>>
>>> It is not necessarily the case that in-band OAM packets will 
>>> traverse the Service Functions.
>>> service functions successfully is hard, and would place a 
>>> significant new requirement on NSH aware service functions.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Aug 2015 20:08:00 -0400

What we have been discussing is testing the Service Function path 
forwarding, including finding means to test the connectivity between the 
SF and the SFF.  (There are a couple of approaches to the later, 
depending upon what one is willing to assume, particularly with regard 
to proxy forwarders.)

You asked about forwarding between SF, which seems to be covered.

Yours,
Joel

---

From: "Bottorff, Paul" <[email-masked]>
Date: Sat, 15 Aug 2015 00:24:40 +0000

Support WG adoption

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, August 03, 2015 5:12 PM
To: [email-masked]
Subject: [sfc] WG adoption of draft-aldrin-sfc-oam-framework

Greetings WG:

Jim & Thomas

---

From: Nobo Akiya <[email-masked]>
Date: Sun, 16 Aug 2015 12:37:32 +0900

Hi JIm, Thomas,

Support, I believe this document is a good start for the WG to adopt and
continue its work.

I am not aware of any IPR related to this document.

Regards,
Nobo