Hi Peter, Happy new year, and my apologies to all for the heavy overlap between this message and the reply to Acee sent just a few moments ago. (inline)
On Tue, Jan 08, 2019 at 09:13:52AM +0100, Peter Psenak wrote: > Hi Benjamin, > > please see inline: > > > On 22/12/2018 15:34 , Acee Lindem (acee) wrote: > > Hi Ben, > > > > See inline. > > > > On 12/21/18, 11:29 PM, "Benjamin Kaduk" <[email protected]> wrote: > > > > On Thu, Dec 20, 2018 at 01:07:59PM +0100, Peter Psenak wrote: > > > Hi Benjamin, > > > > > > are you ok with my responses and proposed changed text for the range? > > > > > > thanks, > > > Peter > > > > > > On 17/12/2018 12:32 , Peter Psenak wrote: > > > > Hi Benjamin, > > > > > > > > please see inline (##PP): > > > > > > > > On 17/12/2018 06:53 , Benjamin Kaduk wrote: > > > >> Sorry for the slow reply -- you caught me right as I was leaving > > for > > > >> vacation. > > > >> > > > >> On Wed, Dec 05, 2018 at 09:53:20AM +0100, Peter Psenak wrote: > > > >>> Hi Benjamin, > > > >>> > > > >>> please see inline: > > > >>> > > > >>> On 05/12/18 04:44 , Benjamin Kaduk wrote: > > > >>>> > > ---------------------------------------------------------------------- > > > >>>> DISCUSS: > > > >>>> > > ---------------------------------------------------------------------- > > > >>>> > > > >>>> What is the extensibility model for the "AF" (address family) > > field > > > >>>> in the > > > >>>> OSPFv3 Extended Prefix Range TLV? That is, what do we need to > > say > > > >>>> about > > > >>>> current implementations' behavior to allow future changes? (I > > also a > > > >>>> little bit wonder if we really need a full eight bits, but that's > > > >>>> basically > > > >>>> aesthetic.) > > > >>> > > > >>> I don't think OSPFv3 will ever support other then IPv6 or IPv4 > > AF. Also > > > >>> the text says: > > > >>> > > > >>> "Prefix encoding for other address families is beyond the scope > > > >>> of this specification." > > > >> > > > >> Perhaps it would be better encoded in a 1-bit field (rather than > > an 8-bit > > > >> one), then? That would at least make the (lack of) semantics of > > the > > > >> other > > > >> 7 bits more clear, as the usual "MUST set to zero on transmit and > > > >> ignore on > > > >> receipt". > > > > > > > > ##PP > > > > it's too late now to change the encoding. This draft has several > > years > > > > of history and there are implementation shipping. Changing the > > encoding > > > > would cause the backward compatibility issues. > > > > I didn't think I was suggesting changing the bits on the wire -- in an > > 8-octet field, we're encoding the values 0 and 1 as: > > > > 00000000 > > 00000001 > > > > I'm proposing to change the eight bits to be specified as "the first > > seven > > bits are always set to 0 but should be ignored on receipt; the eighth > > bit > > represents the 0 or 1 value". This makes it clear what needs to happen > > if > > there's a need to use any of those seven bits (an Update to this > > document) > > and also makes it more clear that there are not expected to be any > > additional AFs defined anytime soon. > > currently the draft only supports 0 and 1. It says: > > "Prefix encoding for other address families is beyond the scope of this > specification." Well, that would seem to imply that even though this specification doesn't touch them, there is a possibility of using this for future additional address families. So I think you need to say more about where it would be in scope to do that work; this could involve making a registration in an IANA registry for new family types, or a future IETF document that updates this one, or probably some other mechanisms that I'm not thinking of right now. > Given that we have other RFCs where 8-bit field is used for AF, can we > leave it as we have it please? There are ways to resolve my discuss position that do not involve changing the encoding or its description, yes. But see above. (And it would make the discussion of how to proceed easier if we had a clear and solid answer about whether future extensions should be permitted or not.) -Benjamin _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
