[OPSAWG] Summary of closed issues of L3NM in github https://github.com/IETF-OPSAWG-WG/l3nm

[Oscar González de Dios <[e-mail]>]

Dear Opsawg colleagues,



                During the last months and with the help of our regular LxNM calls we have been working in solving the open issues in github. Let me remind that the complete list of issues is available at https://github.com/IETF-OPSAWG-WG/l3nm/issues .



                The issues that have been closed since the last meeting can be found with the query https://github.com/IETF-OPSAWG-WG/l3nm/issues?q=is%3Aissue+closed%3A%3E2020-03-01+



                Let me comment briefly what was discussed to close the issue (more details in the link). If anyone has a concern, the issue can be revisited. Please feel free to ask more details about any of them.



-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/10 Nits in text and reference to BESS-L3VPN. The draft text has been fully reviewed and is ready for submission. The reference to bess https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/ was removed since it is no longer an active document. (can change if the document is back to life).

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/18 Review VPN profiles. The profiles were reviewed and maintained. Note that as per issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/113 explained later a new forwarding profile was added. All the profiles are added to the common module.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/20 We need to indicate whether the RT and RDs are provided by the Network Operator / service orchestrator or they are automatically assigned by the controller which has the l3nm module. After a first proposal, the solution was not 100% OK for the implementors. The issue was also raised by Roque in  https://github.com/IETF-OPSAWG-WG/l3nm/issues/114 Please check that issue for the latest proposal (it is still open).

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/25 Delete extranet VPNs container.  The extranet VPNS information coming from L3SM is needed to be analyzed by the Network operator/service orchestrator and create the necessary import/export policies that will apply in L3SM. The container has been removed from the yang model (it is present in L3SM).

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/32 Review Yang for containers that can directly imported from L3SM. This is solved with the new vpn common module, so avoiding directly importing containers from L3SM.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/36: BGP Session under vpn_node (erez proposal) or under vpn_network_access After several discussions it was agreed to keep it under vpn-network-access. In the implementation level there the fulfillment entity need to go down to the device and set the BGP per VRF on the device level. each BGP over vpn-network-access reflected as a neighbor configuration on the BGP instance on the VRF. Dual homing is done from different PEs - metric is treated in the customer side.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/39 Add Local-AS under the BGP session. The request is to Include the Local-AS as an option to announce a different AS to the CE. Fixed in https://github.com/IETF-OPSAWG-WG/l3nm/commit/f987d5b4b7fcbebf10b59f114fa316a54ba877cd

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/41 In vpn_target, make route_target a list of route_targets (meaning an and operation between all route_targets) AND OR operations have been added https://github.com/IETF-OPSAWG-WG/l3nm/commit/003fcabcd15429c097f7b66f2fb4eb342231c27c

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/45 Add RP PIM Anycast under multicast configuration. Solved in https://github.com/IETF-OPSAWG-WG/l3nm/pull/54 and  https://github.com/IETF-OPSAWG-WG/l3nm/pull/75 It is required to add the following information to detail the Multicast service: Provider Tunnel: RSVP-TE, mLDP, PMSI-Type: iPMSI sPMSI Threshold rt.  Solved together with issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/47

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/53 Custom QoS. We agreed on leaving just standard QoS profile and removing custom QoS. https://github.com/IETF-OPSAWG-WG/l3nm/commit/3b74db5a029d44e1c51a87c61c9e7a67696fc392 Hence, the definition of the QoS is done outside the model.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/73 This was just the text for the I-D.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/111 Fix issues from Yang doctor review. All issues are dealt. 1) The module seems NMDA compliant, so it should be mentioned in Introduction (or some other) section. NMDA compliance text added to the draft text (the draft-04 is to be published after solving the common module discussion). 2) the filename's revision part does not match the latest revision date (2020-04-03) of the module. Fixed in new version (to be published). 3) All the imported modules must have their document (RFC) in the normative references section. The references have been added  (done together with the new vpn common module). 4) Since RFC 8277 is referenced in the module, it should appear in the normative references section. On this one, we don't think we need to cite it as normative as RFC8407 says the following: If the reference statement identifies an informative reference that identifies a separate document, a corresponding informative reference to that document MAY appear in the Informative References section. 5) Additional indentation (3 spaces on each line except the first one) in the module's contact statement seems weird and unnecessary/unintentional (fixed). 6) The whole groupings part need a cleanup and maybe some structural changes: A new vpn common module has been proposed with the reusable groupings. Unnecessary groupings not reused are removed. https://github.com/IETF-OPSAWG-WG/l3nm/pull/122 ) 7) description of the service-status grouping seems to be invalid. Description of the service-status is updated (see issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/62 ).  8) typedef protocol-type: Are you really sure that the list of the underlying protocols is fixed forever in all its instances? Having it in the form of identity would allow later augmenting of the list of possible values. Protocol types changed to identity refs as per yang doctor suggestion (see common module). 9) I'm afraid about the usability of appendix A. The status of the implementations will tent to change quite intensively and having such information in RFC does not make much sense to me: Regarding the usability of appendix A,  The status of the implementations, this is to be removed once the document is RFC. With this all issues are closed. Note that as soon as the vpn common discussion is closed, we will properly reply to yang doctor's review with the previous comments

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/112 Fix issues from Tom Petch review in Opsawg mailing list. All points were solved and the references updated in issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/115

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/113 Routing policy vs forwarding policy difference. On the global routing profiles, it should be a difference between routing and forwarding policies. A forwarding profile (which refers to the treatment of the packets received by the VPN at the interface of the vpn-network-access) is added in   https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/115 Add reference and descriptions to identityrefs for protocol-type. They are added in https://github.com/IETF-OPSAWG-WG/l3nm/pull/164

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/117 Routing policy: just a name or a reference to leaf in a routing policy yang? The model does not force any particular policy model to be implemented. Also, maintaining leafrefs adds complexity to implementations. It was agreed to keep just a hook.





Before the last IETF we closed a bunch of issues summarized below:



-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/59 This issue is about how to model the filtering happening at vpn-network-access level, as part of the qos profile. The way the match (of L3 and L4 packets) is changed from the L3SM style to the more recent and generic RFC 8519: YANG Data Model for Network Access Control Lists (ACLs). Hence, the model imports from RFC 8519. Solved in pull https://github.com/IETF-OPSAWG-WG/l3nm/pull/88

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/61 A pointer to L3SM service id is added, so the relation between a service created in the service orchestrator with L3SM and in the network controller instantiated with L3NM is maintained. The pointer is OPTIONAL. Solved with https://github.com/IETF-OPSAWG-WG/l3nm/pull/60 (yang change) and explanation in text in https://github.com/IETF-OPSAWG-WG/l3nm/pull/72

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/62 Overal service status. A container with the service status was added See https://github.com/IETF-OPSAWG-WG/l3nm/pull/58  . Note that the status related groupings and types are now being revisited to  be part of the common module.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/70 control which notifications should be supported for the service. This important issue will be managed in a separate document. See https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-00.html

-           Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/71 Consider exposing a set of VPN-related network capabilities. These capabilities may be used by the service layer as input to service order handling (or service activation). Examples can be:Limit on max routes per customer: supported/not, FIB/RIB limits, Max supported VRF instances, link capacity. Max BGP sessions, Encryption capabilities. It is an important line of work, but for the moment we keep it out of the draft and we plan to initiate a new line of work related to exposing the capabilities.

-          Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/76 The model does not support the creation of vrf-import & export profiles. Solved with https://github.com/IETF-OPSAWG-WG/l3nm/commit/16fa91d76f9ecccbb16aca7052783c2266574ebb by adding vrf import and export policies within vpn-targets container to expand routing profiles functionality. Note that we are just pointing to a policy. The information inside the policy is out of scope of the model. This can be done, for example, with the routing-policy yang models defined in IETF (https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-15).



        Best Regards,



                               Oscar on behalf of L3NM authors and contributors


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição