doc-json-config-example

[mmiele]

This is WIP to start a discussion on this topic and gather relevant information and feedback.

[chrispsommers]

It's not clear to me where this schema fits in. I get that it represents a bunch of DASH service configs, but...

Does it relate to the gNMI northbound API schema? In other words, is it a faithful representation of the expected gNMI config objects?

Is it merely an informal conceptual sketch of eventual config objects seen on the gNMI northbound?

Or does it relate to some other domain, e.g. inside an SDN controller's DB?

Alternatively, is it a JSON representation of DASH_APP_DB objects? In this case, shouldn't the JSON schema be derived from sonic-cfggen?

IMO there should be a definitive (JSON and/or YAML) schema which is 1:1 tied to an existing schema, e.g. gNMI YANG <-> JSON or CONFIG/APP_DB <-> JSON. We should avoid yet another schema which is unrelated to anything else.

I've created #94 with a figure to more clearly show what I mean.

[mmiele]

@chrispsommers I think @KrisNey-MSFT, @prsunny and @mzms could address some of your questions. Obviously, any suggestions from the community are welcome. Really, to the best of my knowledge, one of the intents of this PR (document) is to have a discussion on this important matter and come to an agreement. Obviously, you are already doing it, and thank you for that.
To everyone, please look at the related PR #94 created by @chrispsommers.
Thank you

[prsunny]

It's not clear to me where this schema fits in. I get that it represents a bunch of DASH service configs, but...

Does it relate to the gNMI northbound API schema? In other words, is it a faithful representation of the expected gNMI config objects?

Is it merely an informal conceptual sketch of eventual config objects seen on the gNMI northbound?

Or does it relate to some other domain, e.g. inside an SDN controller's DB?

Alternatively, is it a JSON representation of DASH_APP_DB objects? In this case, shouldn't the JSON schema be derived from sonic-cfggen?

IMO there should be a definitive (JSON and/or YAML) schema which is 1:1 tied to an existing schema, e.g. gNMI YANG <-> JSON or CONFIG/APP_DB <-> JSON. We should avoid yet another schema which is unrelated to anything else.

I've created #94 with a figure to more clearly show what I mean.

@chrispsommers , this is a reference model and forms the basis for generating the DASH APP_DB schema. However this is not a complete one-one representation and we have made many modifications to be aligned with Sonic model for the schema.

[chrispsommers]

@prsunny Thanks for responding. If I understand you, it will eventually correspond exactly to the schema as sonic-cfggen would use for import-export? Was the diagram in #94 useful? Thanks.

[lisahnguyen]

I have a few questions for the examples. I am not able to add them to the corresponding of the document. Hence, I will list them all here

1. For the per-ENI’s “qos_settings”, what is the expected behavior when the limit is reached? For example,

• When CPS rate is reached, is it expected that new connections won’t be learned even though the overall CPS per DPU has not maxed out?
• When CPS or max flows are reached, should a per ENI counter be incremented to track the number of dropped flows due to max limit? Should all or a subset of the dropped flows be sent to the Control Plane/Controller?

2. There is a reference to per DPU initial configuration in the routing action comment “list of active modules impacts memory and needs to be configured as part of initial card config”. What other per DPU initial configurations should be expected (e.g. global connection aging time, etc.)?

3. For each routing type, please help list a set of valid actions associated with it and any expected action orders in addition to the max number of actions. This info is helpful in writing test cases to validate expected behavior not explicitly listed in the sample json file.

4. In term of routing action combinations, Is “maprouting” action the only exception or it is just one example and there are more exception?

5. For the “drop” routing-type, what are the other two action types that can be associated with “drop” action-type?

6. Please help add more info on what objects can be modified and the expected behaviors. For example, what is the expected behavior for existing connections when ACL rules change from “allow” to “deny” that impacts those connections?

[mmiele]

@lisahnguyen I fixed some issues related to the JSON example. I added the actual file DASH.json into the PR. Now you can review it directly. Would you mind to add your comments into the file itself under the appropriate lines. I appreciate your help. Thanks

[lisahnguyen]

What is the expected behavior when the CPS or max flow limit is reached? For example,

• When CPS rate is reached, is it expected that new connections won’t be learned even though the overall CPS per DPU has not maxed out?
• When CPS or max flows are reached, should a per ENI counter be incremented to track the number of dropped flows due to max limit? Should all or a subset of the dropped flows be sent to the Control Plane/Controller?

[lisahnguyen]

What other per DPU initial configurations should be expected (e.g. global connection aging time, etc.)?

[lisahnguyen]

For each routing type, please help list a set of valid actions associated with it and any expected action orders in addition to the max number of actions. This info is helpful in writing test cases to validate expected behavior not explicitly listed in the sample json file.

[lisahnguyen]

In term of routing action combinations, Is “maprouting” action the only exception or it is just one example and there are more exception? Please help elaborate if there are more exceptions

[lisahnguyen]

For routing-type "drop", what are the other two action types that can be associated with “drop” action-type?

[lisahnguyen]

Please help add more info on what objects can be modified and the expected behaviors. For ACL specifically, what is the expected behavior for existing connections when ACL rules change from “allow” to “deny” that impacts those connections?

[KrisNey-MSFT]

@lisahnguyen - I've spoken with Engineering regarding your questions...right now the resourcing focus in on delivering our Private and Public preview - I'll get with them next week to obtain answers, or have SDN Eng attend the Wednesday meeting.

[lisahnguyen]

@mmiele Thanks for providing the DASH.json file. I have moved my comment to the appropriate section as you suggested

[mmiele]

@lisahnguyen Great feedback by distributing your comments in the JSON file.

[mmiele]

2. n

I have a few questions for the examples. I am not able to add them to the corresponding of the document. Hence, I will list them all here

1. For the per-ENI’s “qos_settings”, what is the expected behavior when the limit is reached? For example,

• When CPS rate is reached, is it expected that new connections won’t be learned even though the overall CPS per DPU has not maxed out?
• When CPS or max flows are reached, should a per ENI counter be incremented to track the number of dropped flows due to max limit? Should all or a subset of the dropped flows be sent to the Control Plane/Controller?

2. There is a reference to per DPU initial configuration in the routing action comment “list of active modules impacts memory and needs to be configured as part of initial card config”. What other per DPU initial configurations should be expected (e.g. global connection aging time, etc.)?
3. For each routing type, please help list a set of valid actions associated with it and any expected action orders in addition to the max number of actions. This info is helpful in writing test cases to validate expected behavior not explicitly listed in the sample json file.
4. In term of routing action combinations, Is “maprouting” action the only exception or it is just one example and there are more exception?
5. For the “drop” routing-type, what are the other two action types that can be associated with “drop” action-type?
6. Please help add more info on what objects can be modified and the expected behaviors. For example, what is the expected behavior for existing connections when ACL rules change from “allow” to “deny” that impacts those connections?

@lisahnguyen Moved comments to the correct places in the JSON file.

[mmiele]

2. n

I have a few questions for the examples. I am not able to add them to the corresponding of the document. Hence, I will list them all here

1. For the per-ENI’s “qos_settings”, what is the expected behavior when the limit is reached? For example,

• When CPS rate is reached, is it expected that new connections won’t be learned even though the overall CPS per DPU has not maxed out?
• When CPS or max flows are reached, should a per ENI counter be incremented to track the number of dropped flows due to max limit? Should all or a subset of the dropped flows be sent to the Control Plane/Controller?

2. There is a reference to per DPU initial configuration in the routing action comment “list of active modules impacts memory and needs to be configured as part of initial card config”. What other per DPU initial configurations should be expected (e.g. global connection aging time, etc.)?
3. For each routing type, please help list a set of valid actions associated with it and any expected action orders in addition to the max number of actions. This info is helpful in writing test cases to validate expected behavior not explicitly listed in the sample json file.
4. In term of routing action combinations, Is “maprouting” action the only exception or it is just one example and there are more exception?
5. For the “drop” routing-type, what are the other two action types that can be associated with “drop” action-type?
6. Please help add more info on what objects can be modified and the expected behaviors. For example, what is the expected behavior for existing connections when ACL rules change from “allow” to “deny” that impacts those connections?

@lisahnguyen Moved comments to the correct places in the JSON file.

[mmiele]

@lisahnguyen Doing some housekeeping and my apologies for the delay. Did the related and merged PR: #94 answer your questions? If that doesn't, please let me know.
Thanks

[mgheorghe]

can we add all elements needed to have the config working please:

• i see interfaces portion missing, where we configure the ip on each interface of the dpu
• Layer 1 settings are missing also
• loopback interface for vtep is missing also

[mmiele]

@mgheorghe This PR used a JSON file as an example. You may want to refer to the current document SONiC-DASH HLD. Thank you