Hi Benjamin,
Happy New Year!
Please see inline:
On 08/01/2019 15:33 , Benjamin Kaduk wrote:
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.
The document says:
"Prefix encoding for other address families is beyond the scope
of this specification."
So we do allow new specification to define a new AF if needed for the
Range TLV. Although we do not see that happening very likely.
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.
so what exactly would help to resolve the discuss?
(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.)
We are not precluding future extensions to AF if they happen.
thanks,
Peter
-Benjamin
.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
