Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 6 Jun 2019 16:58:56 +0000

Hi Med,

I am working on your comments and would like to get some clarity on a few. Please see below:

<Med> You may add some text saying that SF availability can be about the availability of SF in a given SFC-enabled domain (think about stateless SFs) or a given SF instance. Both should be in scope.

<Nagendra> Can you help understand more about what you mean by stateless SF?. Did you meant the ability to check if the SF is up (where the SF can be a cluster running multiple instances of the function for load balancing or resiliency) vs a specific SF instance (within the cluster) is up?.
<Med> Isn’t this deployment-specific? Or you assume that an SFC-aware node can initiate OAM operations for its local needs? Are there any authorization to be granted, etc.?

<Nagendra> As defined in section 3.2.2, if the PM is to be performed for a specific segment of service function, the relevant SFC-aware node should have the ability to initiate OAM. Since they all belongs to the same domain, I don’t we need any additional authorization.

Are you seeing any issues here?.

<Med> Orchestration is not defined here. Consider introducing it to..
<Nagendra> Just like other fields, in the table, it looks self-explanatory to me ☺. Scanning through the other drafts, I don’t see any reference. If you have any pointers, please share.

I will share the updated draft soon.

Thanks,
Nagendra

From: sfc <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, May 29, 2019 at 7:50 AM
To: James Guichard <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Hi all,

The draft is almost ready.

FWIW, some inputs/comments/nits are available at:

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-sfc-oam-framework-06-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-sfc-oam-framework-06-rev%20Med.doc

Nagendra, feel free to share on the list points that you think need further discussion/clarification.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James Guichard
Envoyé : mardi 28 mai 2019 16:30
À : [email-masked]
Objet : [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear WG:

This message starts a new two week WG Last Call on advancing https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Ce47e5eb13f224f18c46408d6e378b2f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636946504868870205&sdata=lkKvAgmKik7lkqGANQpnIvBRdbjKAqYtzTUdTfB9f3Y%3D&reserved=0> for publication as an Informational RFC.

Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors.  This last call will end on 11th June 2019.

Thanks!

Jim & Joel

---

From: <[email-masked]>
Date: Fri, 7 Jun 2019 06:37:03 +0000

Hi Nagendra,

Please see inline.

Cheers,
Med

De : Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
Envoyé : jeudi 6 juin 2019 18:59
À : BOUCADAIR Mohamed TGI/OLN; James Guichard; [email-masked]
Objet : Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Hi Med,

<Nagendra> Can you help understand more about what you mean by stateless SF?

[Med] By stateless SF, I meant a service function that does not maintain any state for handling a flow/packet (e.g., MAP BR defined in RFC 7597). For such SFs, any instance of the SF can provide the service.

. Did you meant the ability to check if the SF is up (where the SF can be a cluster running multiple instances of the function for load balancing or resiliency) vs a specific SF instance (within the cluster) is up?.

[Med] Yes, that is one dimension. More practically, the SFC OAM should be able to assess the availability of an SF in the following cases:

* only an SF identifier is provided as input.

* both an SF identifier and a locator are provided.
<Med> Isn’t this deployment-specific? Or you assume that an SFC-aware node can initiate OAM operations for its local needs? Are there any authorization to be granted, etc.?

[Med] The use of “must” is not motivated in your text:
==
   Any SFC-aware network device must have the ability to perform loss
   and delay measurements over the service function chain as a unit
   (i.e. end-to-end) or to a specific segment of service function
   through the SFC.
==

It is not clear from the text why ** any ** node can initiate PM on ** any ** chain and how obtained information will be used by that node.

An alternate deployment scheme would be that such PM can be instructed by a control element which will in turn instruct the underlying SFs as a function of gathered results.

That section should be worked out further, IMO.

[Med] You can add a pointer to RFC8309. You may clarify whether you refer to “Service Orchestration” or “Network Orchestration”. Actually, my hidden comment was: why you only cite, under orchestration column, CLI/NETCONF for the first items but only CLI for SF and SFC? I didn’t made that comment because I don’t know how “orchestration” is defined by this draft.

Thanks,
Nagendra

Hi all,

Cheers,
Med

Dear WG:

Thanks!

Jim & Joel

________________________________