Subject: Re: [Last-Call] Last Call: <draft-ietf-opsawg-vpn-common-09.txt> (A Layer 2/3 VPN Common YANG Model) to Proposed Standard

From: tom petch <[email-masked]>
Date: Mon, 2 Aug 2021 17:09:22 +0100

On 16/07/2021 17:06, The IESG wrote:
>
> The IESG has received a request from the Operations and Management Area
> Working Group WG (opsawg) to consider the following document: - 'A Layer 2/3
> VPN Common YANG Model'
>    <draft-ietf-opsawg-vpn-common-09.txt> as Proposed Standard

This I-D creates an additional set of YANG identity for address-family 
with semantics I have not seen before and which seem inappropriate for 
routing protocols.

'address family' has long been a concept in BGP and there is an 
IANA-maintained registry most of which is unlikely to be seen in 
practice (e.g. Decnet IV, Banyan Vines) and so does not provide a good 
basis for YANG modules.

RFC8349 (routing) defines a separate set of identity more suitable for 
current protocols, of IPv4 unicast, IPv6 unicast, with the expectation 
that others would be added, such as mpls, which indeed has happened 
(RFC8960).

This I-D goes in a different direction, defining ipv4, ipv6 and dual 
stack.  This last is a term that seems alien to routing, rather 
something for host implementations concerned with migrating from ipv4 to 
ipv6.  Further, the way the identity is used, as in 
draft-ietf-opsawg-l3sm-l3nm, is that ipv4 means ipv4 and not ipv6, and 
vice versa, so that YANG tests that are simple in other modules e.g. for 
ipv4 alone or in combination with others become complex having to test 
for 'dual stack but not ipv6' or dual stack as well as ipv4.

But it is when dual stack is applied to OSPF that I lose the plot.  OSPF 
has v2 and v3 and that is how every other YANG module models it AFAIK, 
base identity ospf with derivations of ospfv2 and ospfv3, allowing 
simple tests for one or other or both, depending on what function is 
being tested for.  As used in draft-ietf-opsawg-l3sm-l3nm, I see ospf 
and ipv4, ospf and ipv6, ospf and dual stack; this last makes no sense 
to me.  ospfv3 is happy to convey ipv4 and ipv6 information so what is 
it then, what if it only conveys ipv4?

dual stack as a concept should be limited to applications, not routing. 
  It may make sense for the applications, the services that a vpn 
supports, as modelled in draft-ietf-opsawg-lsm-lnm, but I can make no 
sense of its application to protocols such as OSPF and BGP (or any other 
routing protocol).

Tom Petch

>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-08-06. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document defines a common YANG module that is meant to be reused
>     by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN
>     network models.
>
> Editorial Note (To be removed by RFC Editor)
>
>     Please update these statements within the document with the RFC
>     number to be assigned to this document:
>
>     o  "This version of this YANG module is part of RFC XXXX;"
>
>     o  "RFC XXXX: A Layer 2/3 VPN Common YANG Model";
>
>     o  reference: RFC XXXX
>
>     Also, please update the "revision" date of the YANG module.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>