Hi John & WG members, I've posted an update to this document: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-11
The following changes are to address the remaining comments on this thread: 1) Incorporate the text suggested by John related to the instantiation of the SRv6 End.X SIDs (to qualify the use of SHOULD). 2) New IANA registry with the initial assignments for the OSPFv3 SRv6 End.X and LAN End.X SID sub-TLV flags. John, I've also taken a relook at your previous comments and made following changes: a) New IANA registry with no initial assignments for the OSPFv3 SRv6 End SID sub-TLV flags. I missed that RFC9352 already did this for ISIS and so makes sense for OSPFv3 to follow the same. b) Added a note each in the new OSPFv3 SRv6 Locator LSA Sub-TLVs and the existing OSPFv3 Extended-LSA Sub-TLVs registries to ensure that there is check to ensure consistency of future allocations in either of them being reflected in the other when applicable. Request to check/review the same and let know if these changes address the concerns you had raised. Thanks, Ketan On Tue, May 2, 2023 at 11:48 PM John Scudder <[email protected]> wrote: > Hi Ketan, > > > On May 2, 2023, at 11:46 AM, Ketan Talaulikar <[email protected]> > wrote: > > [omitting agreed points that don’t need further discussion] > > > > @@ -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. > > That sounds pretty good. One quibble — as you’ve written it, an > imaginative reader could come to the conclusion they SHOULD NOT instantiate > such an End.X SID in the “unless” case, which I think is not the intent. > Perhaps, > > Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one unique > SRv6 End.X SID corresponding to each of its neighbors, although it MAY omit > doing so if features like traffic engineering or Topology-Independent Loop > Free Alternate (TI-LFA) that requires it are not in use. > > (Replaced “unless” with ", although it MAY omit doing so if”) > > > > @@ -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. > > That sounds fine. > > > FWIW, we have not defined registries for such flags previously for > RFC8665/6/7 related to SR-MPLS. > > Your point is that those drafts create flags fields but don’t establish > registries for the unused flags? Sure, and if we didn’t create registries > here it wouldn’t be the end of the world, but I think it’s a good practice > (dare I say, a best practice). > > I encourage you to push a new version with the agreed changes (e.g., the > small update to the SHOULD language quoted above) and then I’ll request > IETF Last Call. I don’t think the registry stuff has to happen before IETF > LC, but if we can take care of it before it goes to the IESG telechat that > would be good. > > Thanks, > > —John > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
