VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
... ATTRIBUTE VasExperts-Acct-Traffic 16 tlv ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16.1 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 16.2 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 16.3 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 16.4 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 16.5 integer64 ...
These attributes will be packed into one parent attribute: VasExperts-Acct-Traffic. And ordering of THAT attribute is guaranteed.
I am slightly confused. At the moment the sub-attribtues are grouped into parent attributes of type Vendor-Specific (26) and presumably the ordering of this attribute is preserved (as the numnber 26 is the same).
Yes, the sort takes into account all levels of the hierarchy, so VSAs contained within RFC attribute 26 will occur consecutively in the final list, and their ordering will be preserved.
As I understand it the important thing is that the ordering of the sub-attributes is preserved after flattening.
For example I receive two VSAs:
Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class1" , VasExperts-Acct-Traffic-Class-Output-Octets = 10] Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class2" , VasExperts-Acct-Traffic-Class-Output-Octets = 20]
Here 10 bytes of "class1" data were downloaded and 20 bytes of "class2" data.
After flattening I would like:
VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Name = "class2 VasExperts-Acct-Traffic-Class-Output-Octets = 20
The following variations would also be kind of OK:
VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20
or
VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2"
or
...
However any variation where the ordering of VasExperts-Acct-Traffic-Class-Name is not the same as the ordering of VasExperts-Acct-Traffic-Class-Output-Octets after flattening would be a problem:
VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20
But as far as I can see this can't happen so there is actually no problem at all
Correct. With the current code you'll get alike SubTLVs occurring consecutively in the packed VSA/TLV attribute so you'd end up with one of those two variations. The reason why this happens is the encoder performs a merge sort on the attribute list prior to attempting to encode the attributes. This makes efficient packing of SubTLV attributes into VSAs/TLVs much easier, because you can just look at the next attribute to see if it's in the same parent TLV, or see if there's a common nesting level. Because merge sort is a stable sort, you should find the ordering of attributes of the same number and lineage don't change. -Arran