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. > 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]
