Re: [Lsr] AD review of draft-ietf-lsr-ospfv3-srv6-extensions-09

[Ketan Talaulikar <[e-mail]>]

Hi John,

Please check inline for responses with KT2.

On Mon, May 1, 2023 at 9:55 PM John Scudder <[e-mail]> wrote:

> Hi Ketan,
>
> Thanks for your careful answers.
>
> > On Apr 27, 2023, at 12:35 PM, Ketan Talaulikar <[e-mail]>
> wrote:
>
> …
>
> > @@ -245,6 +260,12 @@
> >
> >     The SRv6 Capabilities TLV may contain optional Sub-TLVs.  No Sub-TLVs
> >     are defined in this specification.
> > +---
> > +jgs: Thank you for setting up registry creation for this flags field.
> > +However, I noticed that the registry says the O-flag has value 0x0001,
> > +whereas in the diagram you show it as having value 0x4000. Please
> > +correct one or the other, to be consistent.
> > +---
> >
> > KT> Thanks for catching that. We've switched from using "value" to using
> "bit positions" in the IANA section.
>
> Thanks. Specifying these as hex “values” rather than bit positions
> triggered my inner pedant since they are *not* values per se… but I noticed
> that other OSPF RFCs do the same thing so I figured the ship has sailed and
> they’re sufficiently clear in context. But I’m happy with ‘bit position’.
> That having been said, in Section 13.3 (and Section 6) you still have a hex
> value,
>
>    *  Value 0x80: AC-bit: Refer to Section 6 of this document.
>
> Should this be made consistent?
>

KT2> I've changed to the use of bit positions for the new IANA registry.
OSPFv3 Prefix Options are existing ones and so I've kept things aligned to
the existing convention for the new bit - otherwise things would get
complicated.


>
> > +---
> > +jgs: Congratulations on getting 42, the best number, assigned for your
> > +code point. :-)
> > +---
> >
> > KT> I think I am missing something significant with this number -
> perhaps you will share what that is? ;-)
>
> This is a pop-culture reference to Douglas Adams’ Hitchhiker’s Guide to
> the Galaxy series, wherein 42 is the answer to “life, the universe, and
> everything.” Too many references to cite, including of course the novels
> themselves, but here’s one:
> https://www.theguardian.com/books/2011/feb/03/douglas-adams-42-hitchhiker


KT2> Ahh ok ... that 42! :-)


>
>
> > KT> Fixed the ordering of fields. We don't want to call this as a
> reserved field since even though we don't yet have flags identified we know
> they would be needed at some point. We have these SRv6 SID flags that are
> the same in ISIS and BGP as well. Possibly we can share the same registry -
> though not sure. Best to do this down the line when we start using the
> flags.
>
> Normally I’d be more insistent on creating the empty registry, but if you
> think it might be shareable, I guess that could be a reason to defer. Is
> this really not a call we can make now? Will it really be more obvious
> later?


KT2> We've put out RFC9352 for ISIS already without this. I think it is
better to defer this one on first use. It could either go into IGP
Parameters (shared between OSPF and ISIS) or even Segment Routing
Parameters (if also shared by BGP).


>
>
> > @@ -825,6 +988,9 @@
> >     one neighbor.  Thus multiple instances of the SRv6 End.X SID and SRv6
> >     LAN End.X SID Sub-TLVs MAY be advertised within the E-Router-Link TLV
> >     for a single link.
> > +---
> > +jgs: why is the SHOULD above not a MUST?
> > +---
> >
> > KT> It is an implementation choice based on the use-case. We don't
> mandatorily need adjacency SIDs. However, for many common use-cases like
> TI-LFA and SR-TE, the adjacency SIDs are required and hence the SHOULD.
>
> That sounds to me more like ’should’ than ’SHOULD’; as my own rule of
> thumb I generally think of ’SHOULD’ as ‘MUST… unless’, or to go to the
> source (RFC 2119):
>
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>
> Alternately, you could qualify the SHOULD with some words about under what
> circumstances it would be OK to disregard, as in
>
>    Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one
>    unique SRv6 End.X SID corresponding to each of its neighbors, unless
>    it is known a priori that [… I’m actually not sure how best to word the
>    caveat based on your comment above.]
>
> I won’t insist on this, but I think it’s worth fixing and if you don’t
> make changes, I think you’ll likely receive additional questions about it
> in IESG review.
>

KT2> How about we change to the following?

Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one unique
SRv6 End.X SID corresponding to each of its neighbors unless features like
traffic engineering or Topology-Independent Loop Free Alternate (TI-LFA)
that requires it are not in use.


>
> > @@ -887,6 +1053,9 @@
> >              +-+-+-+-+-+-+-+-+
> >              |B|S|P| Reserved|
> >              +-+-+-+-+-+-+-+-+
> > +---
> > +jgs: this should have a registry
> > +---
> >
> > KT> Agree. In hindsight, we could have shared this between ISIS and
> OSPFv3. I missed this as the ISIS spec was working through the reviews. I
> wonder whether it is OK to point to ISIS registry or if we define one for
> OSPFv3.
>
> I think this is a question for the WG; I’m OK with either outcome. (Also
> for the later instance.)
>

KT2> I will wait to hear if anyone from the WG has a preference/suggestion,
if not, I will introduce a new flags registry on the same lines as done by
RF9352 for ISIS but under OSPFv3 parameter. FWIW, we have not defined
registries for such flags previously for RFC8665/6/7 related to SR-MPLS.

Thanks,
Ketan


>
> —John
>
>