Lldp intf defaults

[rszarecki]

Change Scope

This change is adding container where LLDP attributes can be configured for all interfaces in system.
The system may have 1000's of interfaces, and operator may need to enable LLDP on all of them exept a few. Or oppodite. Depending on network design.

The default value of enabled is defined as TRUE. This matches industry common behaviour.

module: openconfig-lldp
  +--rw lldp
     +--rw interface-defaults
        +--rw config
        |  +--rw enabled?   boolean
        +--ro state
           +--ro enabled?   boolean

Platform Implementations

• Arista LLDP Configuration Procedures
  "When enabling LLDP, it is enabled on all interfaces by default..."
• Cisco XR: lldp
  "When you enable LLDP globally using the lldp command, LLDP is not enabled on subinterfaces or bundle subinterfaces by default." - hence is enabled on interfaces and bundles.

RP/0/RP0/CPU0:df1cs4n4b1.lam11#sh run interface | Include lldp
Fri Feb 28 18:51:33.091 UTC
RP/0/RP0/CPU0:df1cs4n4b1.lam11#sh run lldp
Fri Feb 28 18:51:40.238 UTC
lldp
!
RP/0/RP0/CPU0:df1cs4n4b1.lam11#sh lldp interface
Fri Feb 28 18:53:43.934 UTC


GigabitEthernet0/0/0/0:
       Tx: enabled
       Rx: enabled
       Tx state: IDLE
       Rx state: WAIT FOR FRAME


GigabitEthernet0/0/0/1:
       Tx: enabled
       Rx: enabled
       Tx state: IDLE
       Rx state: WAIT FOR FRAME


GigabitEthernet0/0/0/2:
       Tx: enabled
       Rx: enabled
       Tx state: IDLE
       Rx state: WAIT FOR FRAME
...

• Juniper lldp interface all
  Note: Junos implicit default is disabled lldp on all interfaces - in contrast to OpenConfig and other vendors.

[earies]

What you are describing in this change-set I believe should be discussed in a wider context as it is not unique to LLDP and can relate to the realm of templating.

It would be good to drive a consistent approach as this can apply in quite a few protocol domains not only in this fashion but also as template expansion, apply-group like scenarios, etc... something that has not been focused much in OpenConfig as the assumption is full expansion all the time vs. device behavior expansion.

You are also selecting a default here that not all implementations support equally so either a YANG deviation is acceptable or there is an underlying ask to change each implementations default behavior to comply.

[LimeHat]

Two questions:

1. isn't the "default enabled" behavior already implied by the current openconfig model?
   

   public/release/models/lldp/openconfig-lldp.yang

   Lines 514 to 520 in b0d7b80

   	leaf enabled {
   	type boolean;
   	default "true";
   	description
   	"Enable or disable the LLDP protocol on the interface.";
   	}
   	}

or is the assumption that the /lldp/interfaces/ list by default is empty and this leaf is supposed to populate it?

2. what problem are we trying to solve? is this specifically for the use case "i want to disable LLDP on all interfaces except a select few"?

[rszarecki]

I try to solve 2 problems.

1. Since LLDP/config/interfaces/* is not mandatory, it is legal to leave it empty. But what would be a behavior? At least 2 implementations enables LLDP on all interfaces implicitly. The 3rd not, but it can easily map OpenConfig to "LLDP {interface all}". Also considering function of LLDP it kind of have sense to enable on all.

2. 16-slot chassis w/ 36x800G ports broken to 100GE makes over 4000 phy ports.
   Config expansion goes to ~MB just for LLDP. We have some challenging experiences with large configs.

3. I agree that this is not only LLDP issue. And industry has invented interface ranges, templates, etc to address it. Many complex and fragile options. I think default-for-all is simple enough. It is better disable all and enable 1000 interfaces. Then have to explicitly disable 3000 and explicitly enable 1000 to get unambiguous OpenConfig config.

[rszarecki]

@LimeHat

1. I understand that as per OPenConfig LLDP is enabled by default (what is not case in many implementations). But does it mean is enabled on all interfaces? Or it means LLDP process is running but no interface is part of it?

I try to make it clear in description.

2. Yes. If LLDP is enabled, but interface list is empty - what it mean? Is enabled or disabled on all?
   Let assume it mean enabled. But in given network LLDP shall run only on very few interfaces. Can I would like to flip bit and change default.

[LimeHat]

I understand that as per OPenConfig LLDP is enabled by default (what is not case in many implementations). But does it mean is enabled on all interfaces? Or it means LLDP process is running but no interface is part of it?

There are two defaults.

1. protocol (system) level enabled
2. interface level enabled

The reference above shows p.2.

Yes. If LLDP is enabled, but interface list is empty - what it mean? Is enabled or disabled on all?

Since LLDP/config/interfaces/* is not mandatory, it is legal to leave it empty. But what would be a behavior? At least 2 implementations enables LLDP on all interfaces implicitly. The 3rd not, but it can easily map OpenConfig to "LLDP {interface all}". Also considering function of LLDP it kind of have sense to enable on all.

My interpretation is that interface state should follow the yang defaults (which is enabled), when LLDP enabled on a protocol level. And the third implementation just doesn't support that default. I'm not convinced that we need to change the OC LLDP yang by creating new data structures to accommodate for that.

But in given network LLDP shall run only on very few interfaces. Can I would like to flip bit and change default.

Yes, that is a potential scenario where this might be useful. To me it feels a bit superficial (trying to find justifications for the proposed solution), but maybe operator community will give different feedback.

16-slot chassis w/ 36x800G ports broken to 100GE makes over 4000 phy ports.
Config expansion goes to ~MB just for LLDP. We have some challenging experiences with large configs.

If that's the issue we're trying to solve, then point made by @earies even more important. LLDP is just one thing, but OC uses /interfaces/ subtree in many contexts: acl, qos, lacp, sampling.

Any decisions in this area require thorough planning and will have a strategic impact on the OC model design as a whole.

cc @robshakir @nokia1adam

[rgwilton]

My reading, as the OC model is currently defined, is that you need to explicitly list all of the interfaces that you want LLDP to run over.

You can add an entry lldp/interfaces/interface list and set enabled to false, but that would be the same as just not having it in the list at all.

I think that this would also end up being a breaking change because you are modifying the global default.

[LimeHat]

My reading, as the OC model is currently defined, is that you need to explicitly list all of the interfaces that you want LLDP to run over.

IMO there are a few possible scenarios, depending on the implementation.

1. an implementation doesn't have and doesn't use system-controlled (in IETF terms) interface state:

• all /interfaces containers (config and state) are empty by default. each and every interface has to be explicitly defined in order to work even with basic state (starting with /interfaces/interface, then /qos/interfaces/interface to apply any QoS policies, ...)
• i don't think that's a common case, but happy to hear feedback from others

2. an implementation does use system-controlled interfaces, but inconsistently (e.g. populates interfaces only to /interfaces and /qos, but not to /lldp)
3. an implementation uses system-controlled interfaces consistently

• in that case, all /interfaces/state subcontexts should be populated as needed (e.g. to /lldp/interfaces when LLDP is enabled globally).
• but the applied per-interface state will depend on the default value used by a specific vendor (per OC spec, it should be enabled)

I'd argue that the proposed PR is conceptually aligned only with implementations that follow p.3 but have a different default value (disabled). For implementations that follow p.1 or p.2 (if there are any), I would agree with @rgwilton's point above.