Hi Yingzhen, > On Aug 11, 2025, at 7:07 PM, Yingzhen Qu <[email protected]> wrote: > > Please see my reply below inline. > > Thanks, > Yingzhen > > On Sun, Aug 10, 2025 at 7:06 PM Acee Lindem <[email protected]> wrote: > Hi Yingzhen, > > > On Aug 9, 2025, at 5:08 PM, Yingzhen Qu <[email protected]> wrote: > > > > Hi Authors, > > > > I reviewed the document and have a couple of questions. > > > > In section 4.1, the description about Figure 5 doesn't seem to be right. > > " > > For example in the network shown > > in Figure 5, link D-F is advertised with > > LSLinkInfinity(65535/0xffff). Router A supports LSLinkInfinity as > > unreachable, but router B does not. Router A considers link D-F as > > reachable, and the shortest path to F is A->B->D->F. Router B > > considers link D-F as unreachable, and the shortest path to F is > > B->A->C->E->F. As a result, A forwards the packets to B, but B > > returns them to A, which results in a routing loop. > > " > > It seems to me that it should be router A which doesn't support > > LSLinkInfinity, while router B does. Please correct me if I'm wrong. > > Good catch. It should read "Router B supports LSLinkInfinity as unreachable > but Router A does not. " > > > > > > In section 4.2; > > " > > When an OSPFv2 router supports [RFC6987] and the Unreachable Link > > support capability defined in this document, it MUST also support > > [RFC8770]. > > " > > Why RFC 8770 MUST be supported? > > Actually, if 0xfffe is used for stub router support, support for RFC 8770 is > not required. > > > > > > Also to my understanding, the enablement of unreachable link is only needed > > in the base OSPF topology, correct? > > Yes - since advertisement of other topologies is optional, it is only > required for the base topology. However, it would make more > sense to have 0xffff to mean unreachable consistently. We will add some text. > > [Yingzhen]: Adding some text will be helpful to ensure that 0xffff is > processed consistently. For a flex-algo, I'd think to not-include a link > would be easier than to set the metric to 0xffff. > > > > > Attached are the YANG module and tree for you to include in the draft. > > Please let me know if you need any other info. > > This looks good but we also need to update the router-capabilities-tlv for > the OSPFv2 opaque LSA and OSPFv3 Router-Information LSA. > > [Yingzhen]: I added an identity for the new capability. Do we need to update > the router-capabilities-tlv? The grouping of "router-capabilities-tlv" > defined in RFC9129 can return all possible flags within 32 bits range.
Yes - but we need a functional capability and a list of identifies for the functional capabilities. The existing ones are informational-capabilities. THanks, Acee > > > > Thanks, > Acee > > > > > > Thanks, > > Yingzhen > > > > <ietf-ospf-link-unreachable.yang><ietf-ospf-link-unreachable.tree> > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
