Skip to main content

A YANG Network Data Model for Layer 3 VPNs
RFC 9182

Note: This ballot was opened for revision 11 and is now closed.

Robert Wilton
Erik Kline
(was Discuss) No Objection
Francesca Palombini
(was Discuss) No Objection
Comment (2021-10-04 for -17) Sent for earlier
Thank you for the work on this document, and for addressing my review comments.

Lars Eggert
No Objection
Comment (2021-09-20 for -11) Sent
It would be useful to summarize this document's relationship to RFC8299 in the abstract.

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 7.6.3. , paragraph 43, nit:
> icates which BFD flavor is used to setup the session (e.g., classic BFD [RFC
>                                    ^^^^^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 7.7. , paragraph 1, nit:
> y applicable if both RP redundancy and and delivery through optimal path are
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 8. , paragraph 8, nit:
>  VPLS and, VXLAN. Other values may defined, if needed."; leaf type { type ide
>                                    ^^^^^^^
The modal verb "may" requires the verb's base form.

Section 8. , paragraph 32, nit:
> cription "Reference to the TCP-AO key chain."; reference "RFC 8177: YANG Key
>                                   ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> description "Reference to the MD5 key chain."; reference "RFC 8177: YANG Key
>                                   ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> f; description "Customer-supplied key chain."; } } } } } container service {
>                                   ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> cast static source/group associated to to IGMP session"; leaf group-addr { ty
>                                     ^^^^^
Possible typo: you repeated a word.

Document references draft-ietf-opsawg-vpn-common-09, but -10 is the latest
available revision.

Obsolete reference to RFC4447, obsoleted by RFC8077 (this may be on purpose).

These URLs point to, which is being deprecated:
Martin Duke
(was Discuss) No Objection
Comment (2021-09-27 for -13) Sent
Thanks for addressing my DISCUSS
Murray Kucherawy
No Objection
Roman Danyliw
(was Discuss) No Objection
Comment (2021-09-30 for -16) Sent for earlier
Thank you to Rifaat Shekh-Yusef for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT feedback.
Warren Kumari
(was Abstain) No Objection
Comment (2021-09-23 for -11) Not sent
I originally balloted Abstain, but after discussions and explanations from Rob I'm moving to No Objection.

I agree with Alvaro that there are inconsistencies that make deriving the mapping between the model and implementations tricky. However, I don't really think that that is the "fault" of this document, but rather is an artifact of the fact that there are so many different "types" of VPNs, and every standard/implementation/vendor has their own special knobs and features. This makes creating a generic model largely impossible - it either needs to be so restrictive that it is basically pointless, or so comprehensive that it is unwieldily.
I think that this document did a good job of trying to thread this needle (and I thank/congratulate the authors), but I still think that it is not really usable. 
I also support Erik's discuss on Sec 7.6.2 -- this is also (I think) an artifact of trying to cover both too much and too little.
Zaheduzzaman Sarker
(was Discuss) No Objection
Comment (2021-09-27 for -12) Sent for earlier
The -11 version addresses my discuss point. Thanks for addressing it.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2021-09-28 for -14) Sent
Thanks for the many updates in the -12 through -14.
Just one final comment on the new changes:

Section 7.6.3

   The L3NM supports the configuration of one or more IPv4/IPv6 static
   routes.  Since the same structure is used for both IPv4 and IPv6, it
   was considered to have one single container to group both static
   entries independently of their address family, but that design was
   abandoned to ease the mapping with the structure in [RFC8299].

This paragraph appears both at the end of 7.6.3 and at the start of; presumably only the latter is needed.
Martin Vigoureux Former IESG member
No Objection
No Objection (2021-10-05 for -17) Not sent
I finally found the time to go through that document and have no objection with it going forward.
Alvaro Retana Former IESG member
Abstain (2021-09-22 for -11) Sent
I understand that L3NM is not a device model and that, as such, it is not intended to include every possible parameter.  

However, not leveraging existing work has resulted in inconsistencies: from using different names to changing implementation expectations.  I believe that this result impacts the implementation-specific work needed to derive device-specific actions (using existing models) and potentially reduces the value of using this network model.

Many WGs in the routing area work on related technology, including bess, idr, lsr, pim, bfd, rtgwg, and teas. However, I found no evidence in the archives that any of these WGs were consulted or asked to review this work.

Both points (lack of reuse and lack of review) have been mentioned in the mailing list, so I assume they have been considered.  This fact and the existence of multiple implementations lead me to ABSTAIN.