Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-l3sm-l3nm-08.txt

From: [email-masked]
Date: Thu, 22 Apr 2021 04:07:21 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : A Layer 3 VPN Network YANG Model
        Authors         : Samier Barguil
                          Oscar Gonzalez de Dios
                          Mohamed Boucadair
                          Luis Angel Munoz
                          Alejandro Aguado
	Filename        : draft-ietf-opsawg-l3sm-l3nm-08.txt
	Pages           : 137
	Date            : 2021-04-22

Abstract:
   This document defines an L3VPN Network YANG Model (L3NM) that can be
   used for the provisioning of Layer 3 Virtual Private Network (VPN)
   services within a service provider network.  The model provides a
   network-centric view of L3VPN services.

   L3NM is meant to be used by a network controller to derive the
   configuration information that will be sent to relevant network
   devices.  The model can also facilitate the communication between a
   service orchestrator and a network controller/orchestrator.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-08
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l3sm-l3nm-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Thu, 22 Apr 2021 11:25:23 +0000

Hi all, 

This version takes into account the comments raised in the WGLC. The changes are further detailed below: 

* Address Adrian's comment as per the reply sent to the list [1]. Also, a new text was added to clarify the SLAAC case.
* s/4/4.c in the IETF Trust Copyright as suggested in the yangdoctors review (Radek).
* Integrate almost all Dhruv's comments [2].
* Address the comments from Roque: 
 (1) Adding leaf for vlan virtual interface id: this is covered by the l3-termination-point (see below). 
 (2) Missing BGP update source for BGP clients (see below). 
 (3) BGP client, redistribute connected ipv4/ipv6 addresses (see below). 
 (4) Multi-hop clients, enabling/disabling mpls label re-write: No change was made as this is implementation-specific.    
* Extend the scope of profile-ie as announced in [3]. This was a major change that impacted many other data nodes and text (e.g., multicast description). New text was added to explain vpn-instance-profile.
* Replicate some of the changes that were made in the common model + add the companion explanation text. This is mainly about RD assignment.
* Add a clarification that other values can be defined in the future for 'vpn-type' in addition to the current "l3vpn". this is to address one of the comments from Dhruv.
* Route targets can be defined per address family.
* Better structure the 'connection' container by reorganizing existing data nodes under encapsulation and l2-tunnel-service. The following changes were also made in this container:
 (1) Add a reference to the companion L2VPN service for IRB interfaces.
 (2) Add a local-bridge-reference to accommodate implementations that may require internal bridging.      
* Update the text to indicate that 'ip-connection' is scoped to include L3 connectivity information in general, not only IP addressing. A new leaf called 'l3-termination-point' is added to that container to address cases where distinct l2/l3 sub-interfaces are used (a new l2-termination-point is added under "connection). This change was also made to address Roque's comment #1. 
* Update the BGP container to control:
  (1) the address/interface used to establish the TCP session (Roque's comment #2)
  (2) whether a local ASN is allowed or not in AS_PATHs received from a peer. 
  (3) whether the ASN at the VPN level can be prepended or not in cases where distinct ASNs are used at the VPN node and network access level.
  (4) whether the PE/CE link is redistributed (Roque's comment #3)  
* Fix area-address for IS-IS. Thanks Dhruv for catching this.
* Update the RIP container to include more parameters that are used in some of deployments. 
* Add NTP service to address a specific requirement for management VPNs.
* Add a note about transport protocols similar to what we did in the common module.
* Add more references to the module as suggested in Dhruv's review. 
* Update the examples to align with the new module structure. 
* Added Paul as a contributor as announced in [3]
* Many other edits and fixes

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/opsawg/TRKiy9Nn9PVTMNjq2Ko62ySi5VU/  
[2] https://mailarchive.ietf.org/arch/msg/opsawg/lAHxjvbkzZQ5jpKR5lshUrp6l_U/   
[3] https://mailarchive.ietf.org/arch/msg/opsawg/vNVN7el7V9WWmzSecE_nWYzSaFc/

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]] De la part
> de [email-masked]
> Envoyé : jeudi 22 avril 2021 13:07
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-opsawg-l3sm-l3nm-08.txt
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.