> Wrt this draft, the text is very clear as it has been implemented by several > major vendors. Now if you are wondering what would be the application for > variable length, that is outside of the scope of this draft as the draft clearly > says that. However, if variable length is used, the length field is basically the > length of subnet address within the 6 octets w/ remaining bits set to zero. > This may not be clear to you but that doesn¹t make the existing text > inaccurate.
The way I read the draft and the figures -- and what John has said -- is this -- the field is fixed at 6 octets, but the address could be shorter, though what you would do with a shorter address is outside the scope of the draft. IMHO, the draft should either say -- - The field is variable length with a single option for a 6 octet address in the first instance. - The field is fixed to 6 octets -- in which case I'm not certain what the length field is for. > Russ, if you don't like John's response, then you should probably take a look > at your email. You didn¹t ask your question(s) but rather asserting that "the > solution is not elegant². > >Now -- to return to the actual topic at hand -- I find the idea of > >binding things together tightly, and then creating an "alias," rather > >than creating a looser bind and map in the first place, is worse. That > >might not fit what you think, but it's still something worth mentioning. Again -- the idea of an "alias" is less elegant than simply making a loose binding or a "grouping," of like things with similar attributes. I understand this may (sadly) already be implemented, so I'm not asking for a change -- just pointing out that this isn't an ideal way of going about building such things, and that we should avoid them in the future. :-) Russ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
