MAC-VRF and L2 fdb/l2rib mac-table and mac-ip-table lists corrections

[adeepika31]

• (M) release/models/network-instance/openconfig-network-instance.yang
• (M) release/models/network-instance/openconfig-network-instance-types.yang
  • Add support for MAC_VRF network-instance type
  • Permit fdb hierarchy for the MAC_VRF instance type
• (M) release/models/network-instance/openconfig-network-instance-l2.yang
  • Refactor L2 fdb/l2rib mac-table and mac-ip-table lists to have vlan in their key
  • Correct types imports to use OpenConfig types vs. IETF types

Per previous PR https://github.com/openconfig/public/pull/527 and the comments in https://github.com/openconfig/public/pull/527#pullrequestreview-891658236, there was an initial proposal to have vlan as part of the key list for l2rib's mac-ip-table and mac-table entries. However it was reverted per the comments listed above prior to merge.

First, it is generally not the intention that a VLAN maps to a network-instance 1:1 in all cases as suggested in the comments and carried in the network-instance name. Per RFC7432, there can be 'VLAN-Based Service Interfaces' (Section 6.1) and 'VLAN-Aware Bundle Service Interfaces' (Section 6.3). In order to support both, the model structure actually does need to encompass a VLAN as key in addition to a mac-address and host-ip into the mac-ip-table list as well as in addition to mac-address in mac-table list much like how the fdb/mac-table is constructed. Leaving this omitted is a shortfall of the model and the model cannot represent > 1 VLAN per network-instance.

In addition, a new network-instance type of MAC_VRF has been introduced to distinguish between other L2 instance types that already map to existing L2 instance types among implementations.

References:

• https://datatracker.ietf.org/doc/html/rfc7432#section-6.1
• https://datatracker.ietf.org/doc/html/rfc7432#section-6.3

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[OpenConfigBot]

Compatibility Report for commit 3552afcaf76448a74713fa1c31802f12c865684e: ⛔ yanglint@SO 1.10.17

[robshakir]

Hi!

Please can you provide links to implementations that support the feature described.

I'm not familiar with implementations of these features, but would be interested to hear how the network instance for an input packet is selected if there is >1 NI associated with a VLAN. What is the selection criteria for which NI handles an input packet on a specific interface with an 802.1q tag?

Thanks, r.

[mikewiebe]

Adding a new network-instance type MAC_VRF makes sense and I would support that. I would like to recommend we do an evaluation of the other service types VLAN Bundle and VLAN-Aware Bundle to make sure these updates are sufficient to capture the changes that are needed to support those service types.

[adeepika31]

Rob: I think you misunderstood my changes. I don't intend to introduce a case to support >1 NI associated with a VLAN. I have added vlan in the key to support the case where there is >1 VLAN for 1 NI and each vlan has its own bridge table which is the case in vlan aware mode.

[adeepika31]

@Mike: I see that you had initially introduced vlan in the key and then later removed it based on a review comment. Quoting the comment below:

"We want to remove vlan here as a key and just make it a property. The vlan (mac-vrf) for these entries is specified by the network-instance name key so it does not make sense to include vlan as a key here."

This holds true only in vlan based mode. But for vlan aware scenario, same MAC can be learnt in more than one VLAN in the the same VRF. So vlan in the key is needed.

Also I wanted to ask about the leaf evi. Type shows as vni-id. But there is already another leaf for l2-vni. What is the need for evi?

[adeepika31]

@mikewiebe waiting for your review. Also please let me know if nexthop list was meant to be inside the mac-table/mac-ip-table list entry. The description says "List of next hop attributes for each MAC or MAC-IP". It should be within the mac/mac-ip entry in that case. Currently its outside. Can we move in within mac/mac-ip entry?

[mikewiebe]

@adeepika31 Sorry for the delayed reply. I did not see a notification that you had replied.

Answering your questions:

Question: Also I wanted to ask about the leaf evi. Type shows as vni-id. But there is already another leaf for l2-vni. What is the need for evi? * Let me get back to you on this question. There are some implementations where we need to represent both evi and vni but I will respond with specifics.

Question: Was the nexthop list was meant to be inside the mac-table/mac-ip-table list entry * The nexthop list is referenced by the entry * /network-instances/network-instance/fdb/l2rib/mac-table/entries/entry/producers/producer/state/next-hop is a leaf reference back to the next-hop index

We could consider moving the next-hop list structure under the l2rib container directly so that the same structure can be referenced by both mac and mac-ip entries.

The goal was to use a similar stucture to AFTS where the next-hop-groups and next-hops are shared by the ipv4/ipv6/ethernet entries

[adeepika31]

Adding a new network-instance type MAC_VRF makes sense and I would support that. I would like to recommend we do an evaluation of the other service types VLAN Bundle and VLAN-Aware Bundle to make sure these updates are sufficient to capture the changes that are needed to support those service types.

Hi @mikewiebe, restarting this thread to take this change forward. We need vlan in the key for Mac and MacIP entries to support Vlan aware service type. As per rfc, bridge table is per vlan in this case.

https://www.rfc-editor.org/rfc/inline-errata/rfc7432.html (section 6.3) With this service interface, an EVPN instance consists of multiple broadcast domains (e.g., multiple VLANs) with each VLAN having its own bridge table -- i.e., multiple bridge tables (one per VLAN) are maintained by a single MAC-VRF corresponding to the EVPN instance.

Please ack so that we can take this change in ASAP. Other changes can come in as part of another pull request and we can discuss more on it. Vlan in the key is priority here.