Hi Tom, Sorry, but I don't understand your question. RFC8665 is for OSPFv2, and RFC8666 is for OSPFv3. While in both cases, the TLV name is "Extended Prefix Range TLV", one is for OSPFv2 extended prefix LSA, the other may be advertised in: E-Intra-Area-Prefix-LSA E-Inter-Area-Prefix-LSA E-AS-External-LSA E-Type-7-LSA
I'm not sure whether this answers your question. More comments are welcome. Thanks, Yingzhen On Sat, Dec 30, 2023 at 3:56 AM 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. > > 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
