+------------+-----------/--------+
| header     |  label 1 / label n |
+------------+---------/----------+

- header 
  -  8 bits TTL
  -  3 bits TC
  - 20 bits flow_label
  -  1 bit flag, 32 bits extension header follows (unset, label follows):
      - 9 bits, type
      - 1 bit flag, optional-transitive (unset, may not forward unless understood):
      - 1 bit flag, extended value follows
      - 1 bit flag, extention header follows value (unset, label follows)
      - 20 bit value
 
      extended value:
         1 bit flag, extended value follows
        31 bit value

- label
  - 22 bits label value
  -  1 bit flag, activity pointer
  -  1 bit flag, label follows


Questions
  1) how much entropy we need for ECMP? (flow_label + TC + labels)
  2) EH, should value lenght be implied from type? With standard allowing up-to X
  3) EH, is 9 bits sufficient for type?
  4) should EH chain be limited to X
  5) should EH appear afer labels? (if it's most optional/transitive, might be good)

1 label, 3B overhead
2 label, 2B overhead
3 label, 1B overhead
4 label, MPLSv1 equality
5 label, -1B overhead
...


ethertype1 == MPLSv2, IP
ethertype2 == MPLSv2, ETH
ethertype3 == MPLSv2, unspecified

Same device can support MPLSv1 and MPLSv2 in same interface, as long as
'ethertype' or comparable differntiator exists in L2.


a) retaining label history
b) low byte overhead (this is MPLS's major selling point against IP tunnels. Our TTL and COS are redundant repeated information for majority of use-cases)
c) remove need for transit P duck-typing/guessing payload (this makes P more complex than it must be)
d) extendable by design (today we essentially need 8B for every 1-4B we want to add)
e) increased label space
f) coexistance with MPLSv1 for gradual/partial deployment