Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Tue, Jan 08, 2019 at 05:09:01PM +0100, Peter Psenak wrote:
> 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" <[e-mail]> 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?

Well, there's a few options, and I don't want to try to dictate my
preferences onto your document.  What seems simplest to me would be to just
bite the bullet and establish an IANA registry for these AF values, but if
you wanted to do something else like saying that they are "beyond the scope
of this specification but may occur in future standards-track work" that
would also be fine.  I'm just trying to avoid some reader seeing "beyond
the scope of this specification" and thinking they can do whatever they
want and pick their own codepoint value to squat on.

> >
> > (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.

Okay, thanks for confirming.

-Benjamin