Hi Yingzhen,
> On Aug 12, 2025, at 4:52 PM, Yingzhen Qu <[email protected]> wrote:
>
> I don't see any functional capability bits defined yet. Am I missing
> something?
This would be the first in the OSPFv2 Router Information (RI) Opaque LSA and
the OSPFv3 RI LSA. We have the uint32 list of functional-capabilities but not
any identity references like the informational-capabilities. We probably should
have named the former functional-capabilities-flags for consistency. Anyway, we
can discuss offline.
grouping router-capabilities-tlv {
description
"Grouping for OSPF router capabilities TLV types.";
reference
"RFC 7770: Extensions to OSPF for Advertising Optional
Router Capabilities";
container router-informational-capabilities {
leaf-list informational-capabilities {
type identityref {
base informational-capability;
}
description
"List of informational capabilities. This list will
contain the identities for the informational
capabilities supported by the router.";
}
description
"OSPF Router Informational Flag definitions.";
}
list informational-capabilities-flags {
leaf informational-flag {
type uint32;
description
"Individual informational capability flag.";
}
description
"List of informational capability flags. This will
return all the 32-bit informational flags, irrespective
of whether or not they are known to the device.";
}
list functional-capabilities {
leaf functional-flag {
type uint32;
description
"Individual functional capability flag.";
}
description
"List of functional capability flags. This will
return all the 32-bit functional flags, irrespective
of whether or not they are known to the device.";
}
}
Thanks,
Acee
>
> Thanks,
> Yingzhen
>
> On Mon, Aug 11, 2025 at 4:50 PM Acee Lindem <[email protected]> wrote:
> 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]
