Hi Tom, all, The address family is simply referring to the VPN connectivity type, this is not to be mixed with AFIs/SAFIs. For routing data nodes, it indicates whether a given protocol is used to provide connectivity for IPv4, IPv6, or both. The setting of which routing protocol version, whether one single or multiple instances, etc. is deployment-specific. The actual AFIs/SAFIs (e.g., l3vpn-ipv4-unicast (AFI,SAFI = 1,128)) will be derived when translating the network model into device-specific configuration. Cheers, Med > -----Message d'origine----- > De : tom petch [mailto:daedulus@xxxxxxxxxxxxx] > Envoyé : lundi 2 août 2021 18:09 > À : last-call@xxxxxxxx > Cc : draft-ietf-opsawg-vpn-common@xxxxxxxx; adrian@xxxxxxxxxxxx; > opsawg-chairs@xxxxxxxx > Objet : Re: Last Call: <draft-ietf-opsawg-vpn-common-09.txt> (A > Layer 2/3 VPN Common YANG Model) to Proposed Standard > > 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 > > . > > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
