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

[<[e-mail]>]

Hi Nagendra,

Please see inline.

Cheers,
Med

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

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?

[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.?

<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.

[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.

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.

[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.

I will share the updated draft soon.

Thanks,
Nagendra

From: sfc <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Wednesday, May 29, 2019 at 7:50 AM
To: James Guichard <[e-mail]>, "[e-mail]" <[e-mail]>
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:[e-mail]] De la part de James Guichard
Envoyé : mardi 28 mai 2019 16:30
À : [e-mail]
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





________________________________