Subject: Re: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp

From: Henning Rogge <[email-masked]>
Date: Tue, 2 May 2017 08:49:16 +0200

Hi,

yes I think the new changes improve the draft and make it easier to understand.

I wonder if there is a way in YANG to prevent the duplication of all
the fields between "interface" and "interface-state"... putting the
common fields into a section of their own and refer to them twice,
once as "read only" and once "read-writeable".

Henning Rogge

On Fri, Apr 28, 2017 at 10:41 PM, Xufeng Liu <[email-masked]> wrote:
> Hi Henning,
>
> Please review if the attached change proposal is ok.
> Thanks,
> - Xufeng
>
>> -----Original Message-----
>> From: Xufeng Liu
>> Sent: Wednesday, April 26, 2017 9:18 AM
>> To: 'Henning Rogge' <[email-masked]>
>> Cc: Jonathan Hardwick <[email-masked]>; Athanasios
>> Kyparlis <[email-masked]>; [email-masked];
>> [email-masked]; Routing WG <[email-masked]>
>> Subject: RE: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp
>>
>> Hi Henning,
>>
>> Yes. We will add some explanations.
>> Thanks,
>> - Xufeng
>>
>> > -----Original Message-----
>> > From: Henning Rogge [mailto:[email-masked]]
>> > Sent: Tuesday, April 25, 2017 9:50 AM
>> > To: Xufeng Liu <[email-masked]>
>> > Cc: Jonathan Hardwick <[email-masked]>; Athanasios
>> > Kyparlis <[email-masked]>; [email-masked];
>> > [email-masked]; Routing WG <[email-masked]>
>> > Subject: Re: Routing directorate QA review of
>> > draft-ietf-rtgwg-yang-vrrp
>> >
>> > On Tue, Apr 25, 2017 at 3:47 PM, Xufeng Liu <[email-masked]> wrote:
>> > >
>> > > Hi Henning,
>> > >
>> > >
>> > >
>> > > Thank you much for the review.
>> > >
>> > >
>> > >
>> > > You are right about the mapping for "address of the virtual router".
>> > > The
>> > existing YANG data model for configuring and managing IP addresses is
>> > RFC7277, which augments the ietf-interfaces model specified by
>> > RFC7223. This VRRP model follows the same paradigm. Such a structure
>> > is also VRRP protocols are usually implemented.
>> >
>> > Maybe the naming of the variables or the explanation of them could be
>> > improved to explicitly state this.
>> >
>> > Henning
>> >
>> > >
>> > >
>> > >
>> > > We will fix the error in  Appendix A. in the next revision.
>> > >
>> > >
>> > >
>> > > Regards,
>> > >
>> > > - Xufeng
>> > >
>> > >
>> > >
>> > > From: Henning Rogge [mailto:[email-masked]]
>> > > Sent: Monday, April 24, 2017 3:41 AM
>> > > To: Jonathan Hardwick <[email-masked]>; Xufeng Liu
>> > > <[email-masked]>; Athanasios Kyparlis
>> > > <[email-masked]>; [email-masked];
>> > > [email-masked]
>> > > Cc: Routing WG <[email-masked]>
>> > > Subject: Re: Routing directorate QA review of
>> > > draft-ietf-rtgwg-yang-vrrp
>> > >
>> > >
>> > >
>> > > Hi,
>> > >
>> > >
>> > >
>> > > Jonathan Hardwick asked me to do an early review of the
>> > > draft-ietf-rtgwg-
>> > yang-vrrp document (currently revision 02) for the routing directorate.
>> > >
>> > >
>> > >
>> > > The draft itself is pretty straight forward and compact, especially
>> > > when you
>> > consider that a lot of text has to be repeated two or four times
>> > (IPv4/IPv6, config vs. read-only state).
>> > >
>> > >
>> > >
>> > > But I had quite a bit of trouble mapping the phrases from the new
>> > > draft-ietf-
>> > rtgwg-yang-vrrp-02 document to the existing VRRP documents (e.g. RFC5798).
>> > This might come from my unfamilarity with VRRP.
>> > >
>> > >
>> > >
>> > > The draft YANG model allows to read (if:interfaces-state) and
>> > > configure
>> > (if:interfaces) virtual IP addresses, but this does not seem to be a
>> > common phrase from the RFCs. Is it the same as "address of the virtual
>> > router" often mentioned in RFC5798?
>> > >
>> > >
>> > >
>> > > In addition to this, I found (I think) a typo or inconsistency in Appendix A:
>> > >
>> > > the ascii art says "eth0" but tree says "eth1".
>> > >
>> > >
>> > >
>> > > Henning Rogge
>> > >
>> > >
>> > >
>> > > On Mon, Mar 27, 2017 at 5:43 PM, Jonathan Hardwick
>> > <[email-masked]> wrote:
>> > >
>> > > Hi Henning
>> > >
>> > >
>> > >
>> > > Please would you do a routing directorate early review of this
>> > > draft?  Would
>> > you be able to do it in 2 to 3 weeks?
>> > >
>> > >
>> > >
>> > > Many thanks
>> > >
>> > > Jon
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Please would you do a routing directorate QA review of this draft?
>> > >
>> > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/
>> > >
>> > >
>> > >
>> > > The draft is still in the RTGWG and is ready for WG last call.  The
>> > > WG chairs
>> > have asked for a QA review from the directorate.  The following link
>> > provides guidance on QA reviews.
>> > >
>> > > https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >

---

From: t.petch <[email-masked]>
Date: Wed, 3 May 2017 18:30:19 +0100

----- Original Message -----
From: "Henning Rogge" <[email-masked]>
Sent: Tuesday, May 02, 2017 7:49 AM
> once as "read only" and once "read-writeable".

No:-(

This has become a thorny and vexed question with lots of solutions whose
benefits depend on where you are coming from with no consensus among the
interested parties. NETCONF/YANG set out to support configuration which
is defined as something writeable. Read only, well it was not ignored
but it did take a back seat since SNMP was already handling that part of
network management.  A requirement emerged to know what the results were
of a configuration change.  I enable an interface; is it now enabled?  I
set an interface card to auto; what speed is it running at?  Clearly
there are 'twin' objects, sometimes triads or more.  Rather late in the
day it emerged that in YANG read-only objects that are below a
read-write object that has not been written do not exist.  This led to
the twin trees approach that is widely used, one tree for read-only, one
for read-write.

Other dimensions of this problem are the need either for configuration
to come first and a hot-plugged card to pick up the configuration or for
hot-plugging to come first and then the card be configured; and for the
box to provide default values to minimise the configuration needed and
for the NMS to know what the defaults are but not to have to read them
all.

Discussions on this go back to 2008 and continue; meanwhile the number
of YANG modules ever increases making changes ever more expensive.

I like your idea but suspect that it will not gain traction.

Tom Petch

> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 4 May 2017 13:47:36 +0000

The Revised Datastore Draft (https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01) is the latest approach to address this issue. Before the solution is finalized, NETCONF/RESTCONF protocols are updated, and implementations are available, we still have the field duplications meanwhile.

Thanks,
- Xufeng

> From: t.petch [mailto:[email-masked]]
> Sent: Wednesday, May 3, 2017 1:30 PM
> To: Henning Rogge <[email-masked]>; Xufeng Liu <[email-masked]>
> Cc: Athanasios Kyparlis <[email-masked]>;
> [email-masked]; Routing WG <[email-masked]>
> Subject: Re: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp
> 
> interested parties. NETCONF/YANG set out to support configuration which is
> defined as something writeable. Read only, well it was not ignored but it did
> take a back seat since SNMP was already handling that part of network
> management.  A requirement emerged to know what the results were of a
> configuration change.  I enable an interface; is it now enabled?  I set an
> interface card to auto; what speed is it running at?  Clearly there are 'twin'
> objects, sometimes triads or more.  Rather late in the day it emerged that in
> YANG read-only objects that are below a read-write object that has not been
> written do not exist.  This led to the twin trees approach that is widely used, one
> tree for read-only, one for read-write.
> 
> Other dimensions of this problem are the need either for configuration to come
> first and a hot-plugged card to pick up the configuration or for hot-plugging to
> come first and then the card be configured; and for the box to provide default
> values to minimise the configuration needed and for the NMS to know what the
> defaults are but not to have to read them all.
> 
> Discussions on this go back to 2008 and continue; meanwhile the number of
> YANG modules ever increases making changes ever more expensive.
>