Unspecified usage of Affinities mask

[carloperocchio]

Questions and answers discussion: Italo Busi, Sergio Belotti, Daniele Ceccarelli, Francesco Lazzeri, Gianmarco Bruno, Carlo Perocchio Monday, December 05, 2016

Q: Affinities in value style has a mask but usage of the mask is not specified

Context: TE tunnel

R: the syntax of affinities is choice can be done (values or named). In values it is not clear what the mask is. In the named field there is the “usage field” which does not appear in the vales branch, it would make sense to have it also there.

[tsaad-dev]

The mask there with values style: | | | | +--rw path-affinities {named-path-affinities}? | | | | | +--rw (style)? | | | | | +--:(values) | | | | | | +--rw value? uint32 | | | | | | +--rw mask? uint32

[carloperocchio]

I don’t think that a single mask is enough to represent affinities operations; in my understanding required operations for affinities are:

Exclude-Any (link.affinities & exclude-any.mask == 0) ? True : False "A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link unacceptable"

Include-Any ((include-any.mask == 0) || (link.affinities & include-any.mask != 0)) ? True : False "A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes."

Include-All ((include-all.mask == 0) || (link.affinities & include-all.mask == include-all.mask)) ? True : False Or: ((include-all.mask == 0) || ((link.affinities & include-all.mask) ^ include-all.mask == 0)) ? True : False "A 32-bit vector representing a set of attribute filters associated with a tunnel all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes."

[tsaad-dev]

Preface: Links: have link attributes, so Link.attributes Tunnels: have affinities (value and mask)

Summary: We are missing a knob to turn validity check function 1) or function 2) below.

Validity check functions: 1) Link.attributes & Tunnel.affinity_mask == Tunnel.affinity_value for include-all and exclude-any 2) Link.attributes & Tunnel.affinity_mask != Tunnel.affinity_value for include-any and exclude-all

Example: Link1.attributes = 0x3 (bit0, bit1 are ON) Link2.attributes = 0x7 (bit0, bit1, bit2 are ON) Link3.attributes = 0x4 (bit2 is ON) Link4.attributes = 0x1 (bit0 is ON)

include-all(bit0, bit1): Tunnel.affinity_mask = 0x3 Tunnel.affinity_value = 0x3 Link.attributes & Tunnel.affinity_mask == Tunnel.affinity_value pass 0x3 & 0x3 = 0x3 Link1 pass 0x7 & 0x3 = 0x3 Link2 pass 0x4 & 0x3 = 0x0 Link3 NOT pass 0x1 & 0x3 = 0x1 Link4 NOT pass

Exclude-any (bit0, bit1): Tunnel.affinity_mask = 0x3 Tunnel.affinity_value = 0x0 Link.attributes & Tunnel.affinity_mask == Tunnel.affinity_value pass 0x3 & 0x3 = 0x3 Link1 NOT pass 0x7 & 0x3 = 0x3 Link2 NOT pass 0x4 & 0x3 = 0x0 Link3 pass 0x1 & 0x3 = 0x1 Link4 NOT pass

Include-any (bit0, bit1): Link.attributes & Tunnel.affinity_mask != Tunnel.affinity_value Tunnel.affinity_mask = 0x3 Tunnel.affinity_value = 0x0 0x3 & 0x3 = 0x3 Link1 pass 0x7 & 0x3 = 0x3 Link2 pass 0x4 & 0x3 = 0x0 Link3 NOT pass 0x1 & 0x3 = 0x1 Link4 pass

[italobusi]

@ietf-mpls-yang : Looking at the current YANG tree, I see the following:

       |  |     |  +--rw path-affinities
       |  |     |  |  +--rw (style)?
       |  |     |  |     +--:(values)
       |  |     |  |     |  +--rw value?         uint32
       |  |     |  |     |  +--rw mask?          uint32
       |  |     |  |     +--:(named)
       |  |     |  |        +--rw constraints* [usage]
       |  |     |  |           +--rw usage         identityref
       |  |     |  |           +--rw constraint
       |  |     |  |              +--rw affinity-names* [name]
       |  |     |  |                 +--rw name    string

I am wondering whether this change would not be quite simple to resolve this issue:

       |  |     |  +--rw path-affinities* [usage]
       |  |     |  |  +--rw usage         identityref
       |  |     |  |  +--rw (style)?
       |  |     |  |     +--:(values)
       |  |     |  |     |  +--rw value?         uint32
       |  |     |  |     +--:(named)
       |  |     |  |        +--rw affinity-names* [name]
       |  |     |  |           +--rw name    string

What do you think?

[carloperocchio]

+1

[sergiobelotti]

After discussion with tunnel model guys proposed modification: container path-affinities { description "Path affinities container"; list constraints { key "usage"; description "List of named affinity constraints"; leaf usage { type identityref { base resource-affinities-type; } description "Affinities usage"; } leaf value { type admin-groups; description "Affinity value"; } } }

This would solve the issue . Closed for me.

[carloperocchio]

rpc to be updated

[italobusi]

We have the following tree now:

       |  |  +---- path-affinities
       |  |  |  +---- constraint* [usage]
       |  |  |     +---- usage    identityref
       |  |  |     +---- value?   admin-groups

I think the issue is closed

@carloperocchio : please check