Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

Qin Wu <bill.wu@huawei.com> Mon, 01 June 2020 04:15 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F283A0C70 for <opsawg@ietfa.amsl.com>; Sun, 31 May 2020 21:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Jy1wVdjSeU for <opsawg@ietfa.amsl.com>; Sun, 31 May 2020 21:15:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6563A0C6F for <opsawg@ietf.org>; Sun, 31 May 2020 21:15:05 -0700 (PDT)
Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D2C6FCFC6C6A3F8D5C61; Mon, 1 Jun 2020 05:15:03 +0100 (IST)
Received: from lhreml743-chm.china.huawei.com (10.201.108.193) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 1 Jun 2020 05:15:03 +0100
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 1 Jun 2020 05:15:02 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.233]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Mon, 1 Jun 2020 12:14:59 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Roque Gagliano (rogaglia)" <rogaglia=40cisco.com@dmarc.ietf.org>, Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>, opsawg <opsawg@ietf.org>
Thread-Topic: [OPSAWG] Minutes of L3NM/L2NM module discussions
Thread-Index: AdY3yZkuyZKsn8usRKGWE7Ba4o6oLg==
Date: Mon, 01 Jun 2020 04:14:59 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD71DF4C@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.123]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD71DF4Cdggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/NkOtNYYWCf0zCh_-dJQ0VtfjmGI>
Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2020 04:15:09 -0000

Hi, Roque:
Should rd-pool-name be defined in L3SM, how does upper layer OSS the RD pool list and related names?
If rd-pool-name is introduced only for troubleshooting, should a separate NBI interface should be defined to expose RD pool resource to the upper layer OSS and maintain the binding between RD and RD pool?
Please give your troubleshooting usage example to explain how the anomaly in the network change can be located and repaired.
Also in your proposed, I think RD should be defined as rt-types:route-distinguisher instead of empty type.

-Qin
发件人: OPSAWG [mailto:opsawg-bounces@ietf.org] 代表 Roque Gagliano (rogaglia)
发送时间: 2020年5月26日 17:39
收件人: Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>; opsawg <opsawg@ietf.org>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

Hi Oscar,

Thursday was a national holiday and I was not able to participate.

I believe I did say in my previous email that there are not syntax issues with using the union of an empty leaf. I implemented two logics for dynamic rd, one using the current draft construct and one using a different construct with a presence container (to avoid an extra leaf). The reason for a container is that I believe we are also missing to say something about the pool from where the RD should be chosen as there could be more than one pool in a network. So, we will need additional leafs anyhow:

    leaf rd {
      type empty;
    }
    container dynamic-assign-rd {
      presence "Aut-assign-rd";
      when "not(../rd)";
      leaf rd-pool-name {
        type string;
      }
    }

Now, let’s put owerselves on the shoes of a person troubleshooting some provisioning problems of validating a posible network change, Which of these two payloads are clearer to know that a dynamic RD should be used?


1)     Implicit using current draft:



{

  "data": {

    "ietf-l3vpn-ntw:l3vpn-ntw": {

      "vpn-services": {

        "vpn-service": [

          {

            "vpn-id": "650087400",

            "ie-profiles": {

              "ie-profile": [

                {

                  "ie-profile-id": "ie_00”

                }

              ]

            }

          }

        ]

      }

    }

  }

}

2)       Using Explicit mentioned with a presence container and specifying the name of the pool:


{

  "data": {

    "ietf-l3vpn-ntw:l3vpn-ntw": {

      "vpn-services": {

        "vpn-service": [

          {

            "vpn-id": "650087400",

            "ie-profiles": {

              "ie-profile": [

                {

                  "ie-profile-id": "ie_00",

                  "dynamic-assign-rd": {

                    "rd-pool-name": "metro1_rd_pool"

                  }

                }

              ]

            }

          }

        ]

      }

    }

  }

}



Regards,
Roque


From: OPSAWG <opsawg-bounces@ietf.org<mailto:opsawg-bounces@ietf.org>> on behalf of Oscar González de Dios <oscar.gonzalezdedios@telefonica.com<mailto:oscar.gonzalezdedios@telefonica.com>>
Date: Thursday, 21 May 2020 at 16:27
To: opsawg <opsawg@ietf.org<mailto:opsawg@ietf.org>>
Subject: [OPSAWG] Minutes of L3NM/L2NM module discussions

Dear OPSAWG colleagues,

                Thanks for participating in the call today. Please find bellow the minutes:

L3NM and L2NM module discussions
* Date: 21-May-2020

Participants
- Oscar Gonzalez de Dios (Telefonica)
- Samier Barguil (Telefonica)
- Anton Snizar (Sedona)
- Daniel King (Old Dog Consulting)
- Adrian Farrel (Old Dog Consulting)
- Qin Wu (Huawei)
- Sergio Belotti ()
- Sriram Krishnamurthy (Nokia)
- Italo Busi (Huawei)

1. Agenda:
    - Revision of the L3NM Github issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues)

2. L3NM
    Revision of the three main issues:
Implementation Report by Cisco. It has two main issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110)
- Common module to have all the L3NM specific requirements. Type-like module.
[Anton]: It makes implementation simpler. Does not generate unnecessary dependencies
[Adrian]: It depends on if we need module for specific types, to avoid unnecessary imports. Also don't you only need to import types, not the entire module?
[Qin]: With L3SM we did not take an augmentation approach. If there are common types defined in both models, then we may need to find the common components. We should decouple of L3SM.
[Sriram]: Prefer to have a separate type-file for the specific parameters.
[Oscar]: Define a common type-file for the service models.
[Qin]: Is it possible to manage it as an independent draft?

[Oscar in github issues]: After the discussions, it seems reasonable to have a separate Yang module to contain the types. The suggestion is to write the module to cover the four service models (client service models, l3sm, l2sm and Network service models, l2nm, l3nm). It seems reasonable to include this module in l3nm draft instead of creating a new one to avoid dependencies.
Samier, Dan and Anton to collaborate for a first version of the split

- RD Auto-assigment implementation issue (https://github.com/IETF-OPSAWG-WG/l3nm/issues/114)
[Anton]: Do not see an implementation issue. The logic can be used as described in the yang.
[Qin]: Same as Anton. If alternative proposal is used, one additional parameter is needed
[Sriram]: Same as Anton
      [Oscar]: There seems to be a smaller preference for the original aproach. However, in order to be fully sure on the aproach, let's take it to the Yang doctor review.
[Oscar in github issues]: Oscar will sent it to the Yang Doctor Review.

Yang Doctor review Issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/111)
- Oscar will take care of editorial changes in the draft text.
- The review of the groupings will be done in a second round after the split.
- [Oscar in github issues]: Oscar will assign Med Boucadair the references issues.

- Protocol-Type: Better as a Indentity (https://github.com/IETF-OPSAWG-WG/l3nm/issues/115)
- [Samier]: Its better to have as an Idenity and include as part of the type-file.yang
- [Qin]: Idenity is extensible.
[Oscar in github issues]: Assigned to Samier

- Groupings review. It will be done after the review of the Types and modules.

Implementation status: There is text in RFC 7942 that provides guidance on text to include to show that the implementation status is not intended to be included in the final RFC

Tom Petch review Issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/112)
    - Oscar fixes the editorial issue of the IANA section.
- [Oscar in github issues]: Oscar will assign Med Boucadair and Qin the references issues in the Yang file.. The review needs to be done in after the module split to avoid conflicts in the yang. Part of the reference work should have been fixed with the update of references for the Yang doctor's review
- [Daniel King]: Volunteers to look at where is the best place to locate the examples.

Best Regards,

                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