Hi Ketan, Thanks for your careful answers.
> On Apr 27, 2023, at 12:35 PM, Ketan Talaulikar <[email protected]> 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? > +--- > +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 > 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? > @@ -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. > @@ -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.) —John _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
