Subject: Re: [OPSAWG] LxNM Design Team -- Minutes

From: SAMIER BARGUIL GIRALDO <[email-masked]>
Date: Fri, 4 Jun 2021 07:39:35 +0000

Dear OPSAWG,

Please find the link of the minutes of the desing team: https://codimd.ietf.org/40Dw-yCkQoONcMsYp8e5XQ?both

The latest sesion minutes:

Date: 3-06-2021
<https://codimd.ietf.org/#Participants0>Participants

     *   Erez Segev
     *   Raul Arco
     *   Luis Muñoz
     *   Mohamed Boucadair
     *   Oscar Gonzalez de dios
     *   Samier Barguil

<https://codimd.ietf.org/#Discussion0>Discussion

     *   Merge the pull request ESI-284<https://github.com/IETF-OPSAWG-WG/lxnm/pull/297> to support:
        *   ESI types
        *   DF election method
        *   ESI as part of the EVPN Service attributes.
     *   Close the issue 239<https://github.com/IETF-OPSAWG-WG/lxnm/issues/239> based on the lastest comments of the group. The limit should be at the Application layer and outside the scope of the model. We close the issue. Roque, if you disagree, please reopen the issue.
     *   Close the isse 237<https://github.com/IETF-OPSAWG-WG/lxnm/issues/237>, This is part of the network creation.
     *   Review the issue 301<https://github.com/IETF-OPSAWG-WG/lxnm/issues/301>.
        *   Erez suggest to simplify the sctructure and remove the Id of the VPN Targets.
        *   Med suggests to keep it as part of the model and its extensibility.
        *   Samier explains the possible usage of VPN targets as boolean operators.
        *   The action point 1 has been cretaed to explain the usage.
     *   Review the issue 299<https://github.com/IETF-OPSAWG-WG/lxnm/issues/299>. We need to think to restructure the connection to be aligned with the one in the L3NM.
        *   The L2NM connection container needs to be restructured. The “physical-interface” container has information about the speed port, etc. The impression is that the configuration of the physical interface impacts different services. Hence, L2NM might not be the best place to manage the phisycal interface. It is included as it was defined in L2SM
        *   L2SM defined:

5.3.2.2.1.  Untagged Interface

   For each untagged interface (untagged-interface), there are basic
   configuration parameters like interface index and speed, interface
   MTU, auto-negotiation and flow-control settings, etc.  In addition,
   and based on mutual agreement, the customer and provider may decide
   to enable advanced features, such as LLDP, IEEE 802.3ah
   [IEEE-802-3ah], or MAC loop detection/prevention at a UNI.  If loop
   avoidance is required, the attribute "uni-loop-prevention" must be
   set to "true".
The advance features shown in L2SM are applicable to both tagged and untagged interfaces, so in L2NM, they can be handled separately.

     *   We believe the configuration of physical parameters belongs to the interface model and its an action to do in the network creation phase.

<https://codimd.ietf.org/#Action-Points>Action Points

     *   @Samier create a text to explain the possible usage of the Id under the VPN Targets.

Samier Barguil

________________________________
De: SAMIER BARGUIL GIRALDO <[email-masked]>
Enviado: viernes, 30 de abril de 2021 11:48
Para: [email-masked] <[email-masked]>
Cc: Oscar González de Dios <[email-masked]>
Asunto: LxNM Design Team -- Minutes

Dear OPSAWG,

The notes of the last design meeting:
Date: 29-04-2021
<https://codimd.ietf.org/#Participants>Participants

     *   Raul Arco
     *   Sergio Belloti
     *   Luis Angel Muñoz
     *   Erez Segev
     *   Mohamed Boucadair
     *   Victor Lopez
     *   Oscar Gonzalez de dios
     *   Samier Barguil

<https://codimd.ietf.org/#Agenda>Agenda

     *   Possible Scenarios for the EVPN and the L2NM.
     *   Review the open pull request on the repo.
     *   @Raul has prepared three possible scenarios.

<https://codimd.ietf.org/#Discussion>Discussion

     *   The draft expires next week. @Med has prepared a new version to submit.

     *   Review the open pull request on the repo.
– #289<https://github.com/IETF-OPSAWG-WG/lxnm/pull/289>: Add VRRP virtual address.
     *   Review the latest open issues in the repo.
        *   – #288<https://github.com/IETF-OPSAWG-WG/lxnm/issues/288>: VPN-ID under EVPN-BGP. It is a leaf reference to the service, and the mapping is 1:1, so we agree to remove it.
        *   – #287<https://github.com/IETF-OPSAWG-WG/lxnm/issues/287>: Extranets VPNs.
        *   – #286<https://github.com/IETF-OPSAWG-WG/lxnm/issues/286>: Redundancy information. Med has grouped all the redundancy related attributes in a shared container.
        *   – #283<https://github.com/IETF-OPSAWG-WG/lxnm/issues/283>: Factorization of data nodes.
     *   Review the possible EVPN implementation scenarios studied by Raul.

<https://codimd.ietf.org/#Action-Points>Action Points

     *   @Med would like the review of #289<https://github.com/IETF-OPSAWG-WG/lxnm/pull/289> and accept the changes.
     *   The work is required to evaluate possible redundancy scenarios #286<https://github.com/IETF-OPSAWG-WG/lxnm/pull/286>.
     *   Update the service-VPN-id by parent-service-id to provide more clarity about its difference with the VPN-id.

Samier Barguil

________________________________

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

---

From: SAMIER BARGUIL GIRALDO <[email-masked]>
Date: Fri, 11 Jun 2021 10:00:44 +0000

Dear OPSAWG,

Date: 10-06-2021

     *   Raul Arco
     *   Mohamed Boucadair
     *   Samier Barguil

     *   Review the issue 299<https://github.com/IETF-OPSAWG-WG/lxnm/issues/299> new proposal:
[Connection container restructure. Similar work as in L3NM]
The proposal includes:
        *   Remove the ‘phy-interface’ parameters.
           *   The oam-802.3ah-link should be part of the model. Put it under the ‘l2-termination-point’.
        *   Add dot1q vlan ‘rewrite’ options.
           *   This seems to be vendor specifc (Cisco). The action is not needed in other vendors (Nokia).
           *   Lets check with Roque (Cisco) and Qin (Huawei) the real necessity of the definition of this parameters in the l2nm model.
        *   Remove ‘cvlan-o-svc-map’ parameters.
        *   Include ‘l2-termination-point’ and ‘local-bridge-reference’.

Samier Barguil

Dear OPSAWG,

     *   Raul Arco
     *   Sergio Belloti
     *   Luis Angel Muñoz
     *   Erez Segev
     *   Mohamed Boucadair
     *   Victor Lopez
     *   Oscar Gonzalez de dios
     *   Samier Barguil

Samier Barguil

---

From: SAMIER BARGUIL GIRALDO <[email-masked]>
Date: Fri, 18 Jun 2021 07:26:19 +0000

Dear OPSAWG,

Date: 17-06-2021

     *   Luis Muñoz
     *   Mohamed Boucadair
     *   Oscar Gonzalez de dios
     *   Samier Barguil

     *   New Issue about PE-PE auto-discovery was opened due to Med suggestion #304<https://github.com/IETF-OPSAWG-WG/lxnm/issues/304>.
     *   Closed issue #293<https://github.com/IETF-OPSAWG-WG/lxnm/issues/293> related to Service Topology and RTs management. The gruop concludes the possible inconsistency (and others) between the topology-type and the RT’s management should be handled by the implementation.
     *   Closed issue #233<https://github.com/IETF-OPSAWG-WG/lxnm/issues/233> related to EVPN Identifier. Some of the items can be moved to the Vpn Network Access level. This is part of the restructure of the signaling options #282<https://github.com/IETF-OPSAWG-WG/lxnm/issues/282>.
     *   Closed issue #301<https://github.com/IETF-OPSAWG-WG/lxnm/issues/301>. The group agree to include in the common module the sentence to explain the RTs usage.

     *   Review the ‘container TO-SIMPLFY-diversity-redundancy-TO-SIMPLFY’ to discuss it on the next meeting. Issue: #286<https://github.com/IETF-OPSAWG-WG/lxnm/issues/286>
     *   Review the possibility to auto-derive RTs for the EVPN support.

Regards,

________________________________
De: SAMIER BARGUIL GIRALDO <[email-masked]>
Enviado: viernes, 11 de junio de 2021 12:00
Para: [email-masked] <[email-masked]>
Cc: Oscar González de Dios <[email-masked]>
Asunto: RE: LxNM Design Team -- Minutes

Dear OPSAWG,

     *   Raul Arco
     *   Mohamed Boucadair
     *   Samier Barguil

Samier Barguil

Dear OPSAWG,

     *   Raul Arco
     *   Sergio Belloti
     *   Luis Angel Muñoz
     *   Erez Segev
     *   Mohamed Boucadair
     *   Victor Lopez
     *   Oscar Gonzalez de dios
     *   Samier Barguil

Samier Barguil

---

From: SAMIER BARGUIL GIRALDO <[email-masked]>
Date: Mon, 28 Jun 2021 09:45:49 +0000

Dear OPSAWG,

Date: 24-06-2021

        *   Luis Muñoz
        *   Mohamed Boucadair
        *   Samier Barguil
        *   Oscar Gonzalez de dios

        *   Work in issue #286<https://github.com/IETF-OPSAWG-WG/lxnm/issues/286>. Redundant fields removed to simplify the container.
           *   Constraints: The constraints definitions does not continue in the Network Model, those are service requests and are part of the L2SM.
           *   Esi-redundancy-mode: Kept as part of the EVPN/ESI definition but removed from the connection.
           *   fate-sharing-group-size and group-color are not part of the latest L2SNM.
        *   Work in issue #304<https://github.com/IETF-OPSAWG-WG/lxnm/issues/304> regarding the autodiscovery. The documentation of the autodiscovery is covered in the draft-rosen<https://datatracker.ietf.org/doc/html/rfc6074#section-3.2.2.1>.
        *   New issue #305<https://github.com/IETF-OPSAWG-WG/lxnm/issues/305> open for the RT autoderivation support for the L2NM.

        *   [@sbarguil] The group-id combined with the precedence serves to model the primary and backup on the same vpn-node. So we agree to improve the description of the Leaf and Identities to reflect the use case usage and make it more clear. The figure for the usage must be inlcuded in the draft.
        *   The deadline of the next draft release is in two weeks. So we need to include the current adavances and changes in the text in the model.

<https://codimd.ietf.org/#LxNM-Design-Team-Meeting>

Samier Barguil

Enviado: viernes, 18 de junio de 2021 9:26

Dear OPSAWG,

Date: 17-06-2021

     *   Luis Muñoz
     *   Mohamed Boucadair
     *   Oscar Gonzalez de dios
     *   Samier Barguil

Regards,

Dear OPSAWG,

     *   Raul Arco
     *   Mohamed Boucadair
     *   Samier Barguil

Samier Barguil

Dear OPSAWG,

     *   Raul Arco
     *   Sergio Belloti
     *   Luis Angel Muñoz
     *   Erez Segev
     *   Mohamed Boucadair
     *   Victor Lopez
     *   Oscar Gonzalez de dios
     *   Samier Barguil

Samier Barguil