-
Notifications
You must be signed in to change notification settings - Fork 17
Dynamically add/delete flows or protocol elements to existing applied configuration. #410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
items: | ||
$ref: '../device/device.yaml#/components/schemas/Device' | ||
x-field-uid: 2 | ||
ethernets: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is only ethernets? why not IPs too as basic & essential Ethernet & IP for most protocols to run. Or once new device append control is given, why append ethernets to be exposed separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is only ethernets?
This is just provided as an example on how this model could potentially handle addition of new config items at any level in the config which was missing earlier. This could be BGP peer or ISIS route range or even a VLAN, depending on the requirements for addition of config outside of flows. ( These need a parent ) .
Or once new device append control is given, why append ethernets to be exposed separately?
Since it is very possible I want to add another emulated interface on a device which is already created just like I might want to add another 10000 route replays within a BGP peer ; use-cases can come up at any level . I could also need to add a new port altogether. Attempt here is to have a model which can handle all of these unknown future needs for device configurations or capture or anything else in a generic form.
Note: Final PR ( probably a different PR with link to this for showing how generic add/delete can be done with this design ) for external review/merge/implementation will only have choice of adding/deleting flows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was added as an example of how we can extend the support for other resource type,
@@ -0,0 +1,80 @@ | |||
components: | |||
schemas: | |||
Config.Append: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be Append/Add.Config is more matching with subsequent "AppendXxx"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added AppendResource node (reference from Append node)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Issue #409
Redocly View:
Config:
https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/open-traffic-generator/models/dev-multi-endpoint/artifacts/openapi.yaml&nocors#tag/Configuration/operation/append_config
Objectives:
There is a long pending request for support for appending and deleting configuration resources to existing configuration.
One such end use case is when we want to provide support for multiple endpoint for traffic. At present, due to maximum stream limitation per port, we can not support RSVP traffic with 64K LSPs. With multiple endpoint support in same flow configuration, we can pack multiple LSPs into one stream.
Furthermore, in such a scenario, resolving "auto" mode for LSP fields for multiple sub-streams, which involves learning LSP data and then internally crafting all the sub-streams into a composite data pattern. This becomes complex to implement and difficult for end user to follow and have control over. The complexities and potential solutions are outlined in the document, in details.
The simplest approach is to be able to allow user to configure and start protocol, then collect control plane parameters
like MPLS label, DHCP IPs etc. Finally these learned information can then be used to define and configure the sub-flows,
likely for a full mesh traffic endpoints. User can then append the traffic portion of the configuration and start the traffic.
Another use case is to provide flexibility to user to configure and run batches traffic streams one after another, after
removing the previous batch of streams for the same running protocol endpoints. Append config in conjunction with delete
config can be used as outlined in the examples below.
Note: This PR outlines how we would like to add model support for appending and deleting config of various type, but
for initial delivery we start with config type flow only.
Sample Code Snippet