Hi authors, Thanks for addressing all my comments. I have uploaded the shepherd writeup: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/shepherdwriteup/
Please review and let me know if you have any questions. Thanks, Yingzhen On Wed, Dec 10, 2025 at 2:32 PM Acee Lindem <[email protected]> wrote: > 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]
