Re: [Lsr] AF: RFC8666 updates RFC8665?
From: Acee Lindem
Sent: 01 January 2024 13:14
> On Dec 30, 2023, at 06:56, tom petch 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.
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AF: RFC8666 updates RFC8665?
> On Dec 30, 2023, at 06:56, tom petch 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. 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AF: RFC8666 updates RFC8665?
From: Yingzhen Qu Sent: 30 December 2023 21:11 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. No! There are those in a world with only OSPFv2 routing domains with no awareness of the existence of OSPFv3; likewise there are those in a world with only OSPFv3 routind domains with no awareness of the existence of OSPFv2. Then there are those who live with both, perhaps with boxes at the border of Enterprise and Operator. And IETF documents exist in this world. ospf-sr-yang models OSPFv2 and OSPFv3, it has RFC8665 and RFC8666 as Normative References and defines a leaf 'af' whose definition in RFC8666 contradicts that in RFC8665 unless and until RFC8666 is seen as updating RFC8665 and which could confuse those who comprehend the Normative References, IMHO., Tom Petch Thanks, Yingzhen On Sat, Dec 30, 2023 at 3:56 AM tom petch mailto:ie...@btconnect.com>> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AF: RFC8666 updates RFC8665?
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 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] AF: RFC8666 updates RFC8665?
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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
