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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
last-call@xxxxxxxx mailing lists by 2021-08-06. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
.


--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux