-
Notifications
You must be signed in to change notification settings - Fork 658
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
network-instance protocol identifier/name effects on other domains #287
Comments
Thanks for pointing this out -- it's indeed a gap in the current model. After discussion in the group, we'll need to think a bit more about the impact of this change to model compatibility (it did not seem to be a common use case). |
Hi, I also ran into the same issue. For example, if you take Cisco redistribute command for OSPF: router bgp 100 The table-connections equivalent does not mention bgp AS (100) or the OSPF ID (10). In my current project, we only have one instance of BGP, but there are more instances of OSPF. It would be nice if we could have the name key in tables and table-connections to be able to reflect this. |
I see 2 issues with current "table-connections" redistribution model, if we assume existence of multiple instances of given protocol.
Finally entire container
Here is quick proposal:
I still do not see much value, but ...
I personally do not like string "table-connections". Network engineers would rather understand "redistribition", "route exporting". But "table-connections" sounds odd and ambigous with forwarding table chaining. I keep "table-connections" because this make change non-breaking. |
See #1114 for suggested update |
This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days. |
The protocol list defined at
/network-instances/network-instance/protocols/protocol
has 2 keys:identifier
to represent the protocol -oc-pol-types:INSTALL_PROTOCOL_TYPE
(e.g. ISIS, BGP, STATIC, etc..)name
to represent a unique "name" for the protocol instance which could be a separate process name, etc..Now, the model allows for and if an implementation permits that > 1 protocol instance can run within the same network-instance.
e.g.
/network-instances/network-instance[name='default']/protocols/protocol[identifier='oc-pol-types:ISIS' and name='p1']
/network-instances/network-instance[name='default']/protocols/protocol[identifier='oc-pol-types:ISIS' and name='p2']
This might mean that you have 2 processes of ISIS running in the same NI, each completely separate from each other.
Now, when we look to things such as:
table-connections
install-protocol-eq
There is no level of granularity down to the protocol
name
but only theINSTALL_PROTOCOL_TYPE
. If NI protocols support multiple "instances" then other domains need to be adjusted to be able to handle this precision as matching on the install protocol only does not sufficeThe text was updated successfully, but these errors were encountered: