From: Acee Lindem <[email protected]>
Sent: 01 January 2024 13:14
> On Dec 30, 2023, at 06:56, tom petch <[email protected]> wrote:
>
> Going through ospf-sr-yang-25 (and no, I do not want a new version for
> Christmas!) it seems to me that RFC8666 updates, RFC8665 even if the metadata
> does not mention it.
>
> RFC8665 says
> " AF: Address family for the prefix. Currently, the only supported
> value is 0 for IPv4 unicast. The inclusion of address family
> in this TLV allows for future extension.
> "
>
> while RFC8666 says
> " AF: Address family for the prefix.
> AF: 0 - IPv4 unicast
> AF: 1 - IPv6 unicast
> "
> Since 8665 says 'only supported value' then this is no longer valid and has
> a knock-on efffect when it comes to ospf-sr-yang.
OSPFv2 only supports IPv4.
<tp>
Not something you would know from reading ospf-sr-yang:-(
There are plenty of objects with ospfv2 in the identifier which then allow IPv6
values e.g
grouping ospfv2-prefix-sid-sub-tlvs {
with mt-id
or
grouping ospfv2-extended-prefix-range-tlvs {
with type inet:ip-prefix;
You could restrict OSPFv2 to IPv4 but you do not.
Tom Petch
If OSPFv2
OSPFv3 supports both IPv4 and IPv6.
Thanks,
Acee
>
> If 8665 set up a registry (which I appreciate that the LSR WG has been
> resistant to doing in other cases) then adding a value to the registry would
> not be an update as per previous AD decisions but the phrase 'the only
> supported value is 0' can mislead until the reader understands 8666 (and may
> still do so).
>
> Note that ospf-sr-yang has both RFC8665 and RFC8666 as Normative References
> so it is the implementor of the yang module that is at risk of
> misunderstanding.
>
> I have a number of comments on ospf-sr-yang relating to this which I will
> post separately.
>
> Tom Petch
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
