Hi Tom,
See inline <ACEE2> . I've addressed your comments in 05.
On 9/30/20, 6:14 AM, "tom petch" <ie...@btconnect.com> wrote:
From: Acee Lindem (acee) <a...@cisco.com>
Sent: 29 September 2020 22:44
Hi Tom,
We can add the references. See ACEE>.
<tp>
Yes please - it will make it easier for me to review
On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" <lsr-boun...@ietf.org on
behalf of ie...@btconnect.com> wrote:
From: Lsr <lsr-boun...@ietf.org> on behalf of internet-dra...@ietf.org
<internet-dra...@ietf.org>
Sent: 13 August 2020 05:37
I said before that it was tough to review because of a lack of
references in the YANG module and that remains true.
You have two Boolean to enable extended LSA on for ospf, one for area.
Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it
took me some time to find it. RFC8362 defines two parameters
ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the
model; yes you have a Boolean under area but I think its meaning requires a
reading of RFC8362 Appendix B and that is missing and the description is
unclear and the name is wrong. Also the RFC has a SHOULD in it which the model
does not implement. You reference s.6.2 but I think that wrong, that it is
Appendices A and B that describe this.
ACEE> What is the SHOULD that isn't implemented?
<tp>
The very last sentence of RFC8362 about the interaction of
ExtendedLSASupport and AreaExtendedLSASupport; YANG has 'must' not 'should' and
I would be inclined to make this a YANG 'must' but it you think that that is
too much, then a comment in the description is needed IMHO
On type, you say there are three possible values. Precisely. Can you
have the type set to 'ospf' and support ospfv3? If so, your model fails. Or
does ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of
ospf per se?
<ACEE2> Ok - I've changed this quite a bit by removing the default for the area
level and adding the SHOULD as a YANG must.
ACEE>"ospf" is the base identity for "ospfv2" and "ospfv3". So, if a
container is applicable to both, no when constraint is needed. However, if it
is applicable to the one or the other, a "when" constraint. It is common to do
this in YANG. This module is applicable only to OSPFv3.
<tp>
Yes, my question is more about the base ospf model about the valid values
that can appear in rt:type; is ospf per se a valid value of type or must it be
either ospfv2 or ospfv3?
The reference statement after the description could do with a title as
you have for the revision description
My point about link type is that you are augmenting ospf-yang which
uses an enum so in places users will be required to use an enum and in others a
uint8 which could be confusing
ACEE> I don't get this. We don’t augment link-type.
<tp>
Yes, In base ospf.yang link type is YANG type enum but in this it is type
unit8 so modelling the same object with two different data types I think might
be confusing.
<ACEE2>I see now. I've used the type ospf:link-type consistent with
ietf-ospf.yang.
Thanks,
Acee
Tom Petch
Thanks,
Acee
Tom Petch
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
Sharmila Palani
Yingzhen Qu
Filename : draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt
Pages : 27
Date : 2020-08-12
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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
