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]
