I hope I've improved the Abstract in -14 with a concise summary of the link metric backward compatibility. I moved the more detailed discussion to the Introduction.
Thanks, Acee > On Dec 10, 2025, at 2:48 PM, Yingzhen Qu <[email protected]> wrote: > > Hi authors, > > If approved, the document will update RFC 5443, RFC 6987 and RFC 8770. The > update needs to be discussed in the introduction. My suggestion is to make > the abstract simpler and move some of the text to the introduction section. > > Thanks, > Yingzhen > > On Wed, Dec 3, 2025 at 3:08 PM Acee Lindem <[email protected]> wrote: > Ok - so the functional capabilities TLV was missing from the LSA capability > encodings. Right? > > > On Dec 3, 2025, at 6:02 PM, Yingzhen Qu <[email protected]> wrote: > > > > Hi, > > > > Considering we now have ietf-ospf-functional-capability as a separate > > general purpose module, I'm thinking we should also add the functional > > capabilities TLV in link scope RI LSAs. Note that there is > > "functional-flag" as uint32 defined RI LSAs in RFC9129, which can return > > raw data. Now we have both uint32 and identities, which is fine. Thoughts? > > > > I attached the updated module with augmentation to link scope RI LSAs for > > your reference. > > > > Thanks, > > Yingzhen > > > > > > > > On Wed, Dec 3, 2025 at 9:17 AM Acee Lindem <[email protected]> wrote: > > Hi Yingzhen, > > > > Thanks for the detailed review. I have incorporated all your comments in > > -12. > > > > > On Dec 2, 2025, at 7:40 PM, Yingzhen Qu <[email protected]> wrote: > > > > > > Hi authors, > > > > > > Thanks for working on this document. I have some comments for you to > > > consider. > > > > > > 1) > > > Section 2.2, the description and the topology of Figure 2 don't seem to > > > match. It seems there are two links between node A and B, A and C, C and > > > D, and B and D according to figure 3 and 4. Can you please confirm? > > > > > > Yes, the base topology is wrong as the links from A to B and C to D are to > > be used exclusively for flex algo. > > > > > > > > > > 2) > > > " > > > 3. LSLinkInfinity-Based Solution > > > " > > > Maybe change this to "LSLinkInfinity Based Solution"? > > > > I don't much care. It is a compound adjective modifying "solution" similar > > to "YANG-based" modifying > > "management-protocosl" in the YANG security template. However, the title > > reads well without the > > hyphenation and I changed it. > > > > > > > > 3) > > > In Section 3.1, "IGP metric" is used instead of "OSPF metric". > > > > There are multiples of these - I fixed them all. > > > > > > > > > > > 4) > > > " > > > Prior to this specification, OSPF treated links advertised as > > > LSLinkInfinity as reachable [RFC2328]. > > > " > > > Maybe "Prior to this specification, OSPF treated links with an advertised > > > metric of LSLinkInifinity as reachable." > > > > > > Sure. > > > > > > > > > > > 5) > > > Section 3.3 > > > RFC6987 applies to both OSPFv2 and OSPFv3, why is MaxReachableLinkMetric > > > only discussed for OSPFv2? > > > > Right, RFC 6987 allows the use of either MaxLinkMetric or the Router-LSA > > R-bit. I've updated "OSPFv2" to "OSPF". > > > > Recently, I worked on a customer POC involving OSPF and LDP and realized I > > needed to add RFC 5443 as well. > > This is included in section 3.4. > > > > Thanks, > > Acee > > > > > > > > > > Thanks, > > > Yingzhen > > > > > > > <ietf-ospf-functional-capability.yang> > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
