Replies: 4 comments
-
No problem with that |
Beta Was this translation helpful? Give feedback.
-
Turns out I do have another preference, as SR OS does not support the VLAN-aware bundle service - only the VLAN bundle service Can we add a feature flag for vlan-bundle and vlan-aware-bundle services, and support both models in the data model? |
Beta Was this translation helpful? Give feedback.
-
Well, if I was stupid enough to implement VLAN-aware bundle service that's supported on two platforms, I don't have the high moral ground to say NO because VLAN bundle service is supported only on one platform ;)... but who knows, we might add Junos and IOS XR in the future ;)) Explore how much the data model would have to change and we'll go from there. |
Beta Was this translation helpful? Give feedback.
-
I think we should model what each device supports ( e.g. EOS vlan-aware-bundle, SROS vlan-bundle, JUNOS both ). Proposal:
|
Beta Was this translation helpful? Give feedback.
-
I encountered an interesting challenge while refactoring EVPN code: what attributes do we want to see on VLANs in a VLAN bundle.
The refactored code assumes that every EVPN-managed object should have evpn.evi which is then used to generate rd (when not already generated). In the case of individual VLANs, evpn.evi is set to vlan.id, in the case of VLAN bundle, all VLANs are in the same MAC-VRF, so evpn.evi is set to the vrf.id. For VLANs in the bundle, the code also sets evpn.bundle which points to the VRF.
The existing EVPN templates assume that the presence of evpn.evi in a VLAN indicates it uses VLAN-based service interface. When trying to configure that service, the template fails because the VLAN does not have evpn.import or evpn.export attributes (because it's part of a bundle).
I would prefer to fix the configuration templates (EOS and SR Linux) to check evpn.bundle, and keep evpn.evi in the VLAN data. Any other preferences @jbemmel?
Beta Was this translation helpful? Give feedback.
All reactions