Subject: [OPSAWG] ietf-vpn common, L2NM and L3NM calls back again after IETF meeting

From: Oscar González de Dios <[email-masked]>
Date: Wed, 17 Mar 2021 17:39:23 +0000

Dear OPSAWG colleagues,

                Let me remind that, after the IETF week, we retake the regular LxNM calls were we discuss the progress of the VPN network models. In case you don't have the invitation link, the opsawg invitation was sent out to the list, so it should be easy to find (if not , just ask our WG chairs).

                Also, let me remind that there is a single git repository for all the models https://github.com/IETF-OPSAWG-WG/l3nm When adding an issue you can tag it L2NM, L3NM and common.

In the agenda for tomorrow we have:

1)      L3NM

·         Issue #224: Proposal to extend the scope of the profiles. In the IETF published version, the Import/Export profiles are reusable. With the proposed scope, other fields can be reused too. Then, for VPN deployments that have do reuse a lot of fields, it avoids having to repeat many times the options. There is a proposal to cover the issue in https://github.com/IETF-OPSAWG-WG/l3nm/commit/1e711eac8c3ecfd9f9d45caa0e9dad4da8413536 with a vpn-instance-profile.

2)      L2NM:

·         Review Issue #219 L2NM: multihoming: need fields for ESI, LACP System ID and LACP Administrative-key value

·         Review Issue #210  add EVPN variants from RFC 7432 to L2NM L2NM

·         Review Issue #207 Routing Directorate Review (L2NM) L2NM

·         Review Issue #205 EVPN support in L2NM: Diffserv Model type L2NM

·         Review Issue #204 EVPN support in L2NM: EVPN Flavors L2NM

·         Review Issue #203 EVPN Support in L2NM: Bridge Domain ID definition L2NM

·         Review issue #202 EVPN Support in L2NM: Split Horizon L2NM

·         Review issue #201 EVPN Suppport in L2NM: IP FRR L2NM

We would like to invite key authors from draft-www-opsawg-yang-vpn-service-pm to join the calls. The issues with vpn-service-pm could be dealt together.

Please feel free to request more items in the agenda and suggestions to the documents/models.

                Oscar

________________________________

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: Sat, 20 Mar 2021 12:54:59 +0000

Dear OPSAWG colleagues,

Please find the minutes of our last LxNM desing team meeting:

LXNM Desing Team Meeting 28-03:
Agenda

  *   Mohamed Boucadair
  *   Bo Wu
  *   Victor Lopez Alvarez
  *   Oscar Gonzalez de dios
  *   Samier Barrguil

Agenda

  1.  L3NM

  *   Issue #224<https://github.com/IETF-OPSAWG-WG/lxnm/issues/224>: Proposal to extend the scope of the profiles. In the IETF published version, the Import/Export profiles are reusable. With the proposed scope, other fields can be reused too. Then, for VPN deployments that have do reuse a lot of fields, it avoids having to repeat many times the options. There is a proposal to cover the issue in link<https://github.com/IETF-OPSAWG-WG/l3nm/commit/1e711eac8c3ecfd9f9d45caa0e9dad4da8413536%20with%20a%20vpn-instance-profile.>

  1.  L2NM:

  *   Review Issue #219 L2NM: multihoming: need fields for ESI, LACP System ID and LACP Administrative-key value
  *   Review Issue #210 add EVPN variants from RFC 7432 to L2NM L2NM
  *   Review Issue #207 Routing Directorate Review (L2NM) L2NM
  *   Review Issue #205 EVPN support in L2NM: Diffserv Model type L2NM
  *   Review Issue #204 EVPN support in L2NM: EVPN Flavors L2NM
  *   Review Issue #203 EVPN Support in L2NM: Bridge Domain ID definition L2NM
  *   Review issue #202 EVPN Support in L2NM: Split Horizon L2NM
  *   Review issue #201 EVPN Suppport in L2NM: IP FRR L2NM

Discussion

  1.  [L3NM]: Review the Issue 224<https://github.com/IETF-OPSAWG-WG/lxnm/issues/224> and the @Mohamed proposal.
  2.  [L3NM]: Aggree on discard non standard multicast features (Sticky-DR).
  3.  [L3NM]: Update the examples in the draft is a new issue 225<https://github.com/IETF-OPSAWG-WG/lxnm/issues/225>
  4.  [L2NM]: Review of the issue 201<https://github.com/IETF-OPSAWG-WG/lxnm/issues/201>.
     *   The only mention of FRR in https://tools.ietf.org/html/rfc7432 is.
     *   The FRR configuration is related to the MP-BGP sesion of the transport network. It is not necessary to have it at service level. To evaluate if something additional is required at EVPN level.
  5.  [L2NM]: Review of the issue 202<https://github.com/IETF-OPSAWG-WG/lxnm/issues/202>.
     *   Now, it is at vpn network access/connection level in L2NM.
     *   We not need to activate or deactivate.
  6.  [L2NM]: Review of the issue 203<https://github.com/IETF-OPSAWG-WG/lxnm/issues/203>.
     *   Pending for discussion with Qin.
  7.  [L2NM]: Review of the issue 204<https://github.com/IETF-OPSAWG-WG/lxnm/issues/204>.
     *   Issue closed. The VPN flavors already supported by the VPN-Common are the following:

identity service-type {
    description
      "Identity of service type.";
  }

  identity l3vpn {
    base service-type;
    description
      "Identity for L3VPN service.";
    reference
      "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)";
  }

  identity vpls {
    base service-type;
    description
      "Identity for the VPLS service type.";
    reference
      "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for
                 Auto-Discovery and Signaling
       RFC 4762: Virtual Private LAN Service (VPLS) Using Label
                 Distribution Protocol (LDP) Signaling";
  }

  identity vpws-evpn {
    base service-type;
    description
      "Identity for the Point-to-point Virtual Private Wire Service
       (VPWS) service type.";
    reference
      "RFC8214: Virtual Private Wire Service Support in Ethernet VPN";
  }

  identity pbb-evpn {
    base service-type;
    description
      "Identity for Provider Backbone Bridging (PBB) EVPNs.";
    reference
      "RFC 7623: Provider Backbone Bridging Combined with Ethernet VPN
                (PBB-EVPN)";
  }

  identity mpls-evpn {
    base service-type;
    description
      "Identity for MPLS based EVPNs.";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN";
  }

  identity vxlan-evpn {
    base service-type;
    description
      "Identity for VXLAN based EVPNs.";
    reference
      "RFC 8365: A Network Virtualization Overlay Solution Using
                 Ethernet VPN (EVPN)";
  }

  1.  [L2NM]: Review of the issue 205<https://github.com/IETF-OPSAWG-WG/lxnm/issues/205>. Pending for discussion with Qin.

Action Points

  1.  Address Family at VPN-Node-Level @SamierBarguil
  2.  Migrate the Issues from the OPSA L2NM repo to the new LxNM repo @SamierBarguil
  3.  Include the performance monitoring draft and Issues in the LxNM repo. @Bo
  4.  Present the scenario for the FRR implementation at the EVPN,Bridge-Domain ID and diffserv model type. @QinWu
  5.  Open the discussion on the list for the split horizon usage at node level. @Oscar
  6.  To add a clarifying text of the split-horizon usage. @Oscar

Regards

Samier Barguil
Transport & IP Networks | GCTIO - Technology | CIT Centro Integrado de Transporte |

Móvil +57 3017026430

Móvil +34 665416074

E-mail [email-masked]

E-mail [email-masked]

________________________________
De: OPSAWG <[email-masked]> en nombre de Oscar González de Dios <[email-masked]>
Enviado: miércoles, 17 de marzo de 2021 18:39
Para: [email-masked] <[email-masked]>
Asunto: [OPSAWG] ietf-vpn common, L2NM and L3NM calls back again after IETF meeting

AVISO/WARNING: Este mail se ha originado fuera de la organización y no se pudo verificar al remitente / This mail was originated outside the organization and the sender could not be verified

Dear OPSAWG colleagues,

                Let me remind that, after the IETF week, we retake the regular LxNM calls were we discuss the progress of the VPN network models. In case you don’t have the invitation link, the opsawg invitation was sent out to the list, so it should be easy to find (if not , just ask our WG chairs).

1)      L3NM

2)      L2NM:

                Oscar