Hi Tom. > On Jan 16, 2024, at 10:26 AM, Acee Lindem <[email protected]> wrote: > > Hi Tom, > >> On Jan 16, 2024, at 06:50, tom petch <[email protected]> wrote: >> >> From: Acee Lindem <[email protected]> >> Sent: 15 January 2024 20:30 >> >> Hi Tom, >> >> Since this YANG model describes the RFC 8362 encodings, those encodings >> should be the primary reference all the leaves and identifies. >> >> <tp> >> >> Acee >> >> I think that you are wrong. The historian in me knows that given a choice >> or primary or secondary sources, the secondary can only get it wrong; you >> always go back to the primary (unless or until the primary is replaced which >> is not the case for most of the definitions here). > > We can disagree then - I have included both references. Note that in any > case, someone really want to dig into the contents of an OSPFv3 LSDB would > need to reference both RFCs if they were not very familiar with OSPFv3 and > the extended encodings. > > > >> >>> On Jan 13, 2024, at 07:42, tom petch <[email protected]> wrote: >>> >>> From: Lsr <[email protected]> on behalf of The IESG >>> <[email protected]> >>> Sent: 11 January 2024 14:35 >>> >> <snip> >> >>> <tp> >>> Most of my comments on this I-D from August are addressed but I still have >>> some doubts. >>> >>> p.11 identity nu-bit >>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a >>> better reference >> >> Agreed. However, I think including both references would be good since RFC >> 8362 includes the >> flags in TLVs >> >>> >>> identity la-bit >>> here RFC8362 changes the meaning so I think the reference to RFC8362 is ok >> >> Actually, for the LA-bit, both references would be good. >> >>> p.11 identity p-bit >>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a >>> better reference >> >> Same as nu-bit. >> >>> p.12 identity dn-bit >>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a >>> better reference >> >> Same as nu-bit. >> >>> p.12 identity e-bit >>> this is not esplained in the referenced RFC8362; in fact, this one defeats >>> me. It is present in a diagram, s.3.6, but with no explanation. Reading >>> RFC5340 it could be A.4.3 but I am not sure >> >> If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, >> there are type 1 and type 2 metrics. Type 1 are simply added to intra-area >> metric to the originator. Type 2 metrics are considered greater than type 1 >> metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 >> extended-LSA encodings. Since the description is brief, I’ll include it in >> its entirety. >> >> <tp> >> Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but >> in the modern context of SR, IPv6, OSPFv3, extended LSA etc I did not >> recognise the terse allusion. > > Yes - since it was not that verbose. I included the complete description in > the description. > > >> >> And why do you not include the AC bit defined in RFC9513? > > We have a separate model for these OSPFv3 segment routing extensions. > However, since the AC-bit is not unique to segment routing, I could just as > well include it here. We’ll see if I get any more IETF Last Call comments.
Actually, the ac-bit is already included in this model - https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-srv6-yang/ Thanks, Acee > > Thanks, > Acee > > >> >> Tom Petch >> >> Thanks, >> Acee >> >> >> >> >>> >>> Tom Petch >>> >>> >>> >>> Abstract >>> >>> >>> This document defines a YANG data model augmenting the IETF OSPF YANG >>> model to provide support for OSPFv3 Link State Advertisement (LSA) >>> Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide >>> extensible TLV-based LSAs for the base LSA types defined in RFC 5340. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ >>> >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
