add system mac leaf at path /system/mac-address/state/system-mac

[paurushmani1]

Change Scope

• Add system-mac config and state to system/mac-address
• The previous PR Add base-mac-address #716 introduced /components/component/state/base-mac-address with the intention of mapping to the system mac address. However, this seems incorrect as mac addresses in the component level has their own burned in mac addresses while the system mac address is generally configurable. This PR addresses the system mac address by adding the mac address leaf as a configurable leaf under /system/mac-address/
• This change is backwards compatible

Platform Implementations

• Arista show command-(show version)
• Arista config command-(system mac-address)

Tree Output

module: openconfig-system
  +--rw system
     +--rw mac-address
        +--rw config
        |  +--rw routing-mac?   oc-yang:mac-address
        |  +--rw system-mac?    oc-yang:mac-address
        +--ro state
           +--ro routing-mac?   oc-yang:mac-address
           +--ro system-mac?    oc-yang:mac-address

[dplore]

Thanks for this PR. So I think we could add a config leaf companion to /components/component/state/base-mac-address and make it configurable.

The only requirement is we need to show that there is an ability to configure base-mac-address on multiple implementations.

Looking at Juniper, I only see JunOS - show chassis mac address. @earies for any guidance.

For Nokia SRL - show version @hellt for any guidance here.

For Cisco IOS XR, I am not finding documentation on setting a base or system mac address. @rgwilton and @aaronmillisor for comment.

[paurushmani1]

Hey Darren,
I don't think the base-mac-address leaf was intended to be configureable, the base-mac is the same as what is on the sticker for each component and is unique to each component and can be used for inventory. This functionality should be independent of configuring the system mac

[OpenConfigBot]

Major YANG version changes in commit 4586160:

[OpenConfigBot]

Compatibility Report for commit 4586160:
✅ pyangbind@6b85c2b

[earies]

The 2nd URL is behind a walled garden - can you point to public accessible documentation or explain the full intention of what a system-mac entails and how it would have different treatment from the routing-mac ?

When and how this MAC address is used? Source MAC used in controller card communications of any kind? Destination address handling?

In addition, please provide pointers to other implementations handling and expectations, otherwise this is just a native vendor proprietary feature submission

[hellt]

@dplore For jericho-based platforms we have a special optional mac address, namely secondary-mac-address - https://github.com/nokia/srlinux-yang-models/blob/a19163258abd4f2de47406db9ed4d45932bba1b4/srlinux-yang-models/srl_nokia/models/platform/srl_nokia-platform-chassis.yang#L145-L153

MAC address programmed as a secondary terminating MAC address on every IP interface, across all network instances
If an IP packet is received on a routed subinterface and it arrives with a DMAC equal to the secondary-mac-address then it is terminated and forwarded exactly the same way it would be forwarded if it had arrived on this subinterface with a DMAC equal to the subinterface MAC address.

[dplore]

Community requests a more detailed explanation of what the function of the system-mac is so it can be compared better against multiple implementations.

[LimeHat]

Re: nokia srlinux

@dplore For jericho-based platforms we have a special optional mac address, namely secondary-mac-address - https://github.com/nokia/srlinux-yang-models/blob/a19163258abd4f2de47406db9ed4d45932bba1b4/srlinux-yang-models/srl_nokia/models/platform/srl_nokia-platform-chassis.yang#L145-L153

This is a routing mac; we don't have a config option to customize the system mac at this time.

We have configurable base-mac-address in virtual (vm-based) Nokia SROS platforms only (doc ref)

[earies]

To add additional commentary from the JUNOS/EVO side - we also do not have any system-mac outside of the routing-mac

This is also entirely different than base-mac-address which is not-configurable on physical/virtual platforms

Since there hasn't been any detailed explanation or proper multi-references/use-cases, I would suggest dropping the PR

[rszarecki]

@paurushmani1

As PR author, could you explain difference between proposed 'system-mac' leaf and existing 'routing-mac` leaf?

[paurushmani1]

The system MAC address is not specific to a given hardware component (unlike the base hardware MAC address for different hardware component types). The broad semantics are vendor-specific and implementation-dependent. In general, a change in system MAC address affects both link-local and routed traffic-forwarding aspects and the use of MAC address as a system identifier in control and management protocols like LLDP and SNMP. As an example, with a change of system MAC address, one can expect a) LLDP, STP, LACP, and other link-local frames to be sourced with the configured system MAC address b) L3 packets to be forwarded with a source MAC corresponding to the system MAC address and c) ARP/ND response messages to use the configured system MAC address.

[dplore]

Ok, so a similar, but different behavior is described by routing-mac. Routing-mac requires 'listen-only' behavior and is not to be used as a source mac-address.

Is this source vs. listen behavior the difference? Or are there other differences?

[rgwilton]

AFAIK, we don't support a system MAC address in IOS XR - it feels somewhat like a layer violation to me. If from Paul's description, the semantics are "vendor-specific and implementation-dependent", and if no-one else is implementing this, then perhaps this would be best modelled as a vendor specific augmentation, where its precise behaviour could be accurately documented?