[bess] Review of draft-ietf-bess-l2vpn-yang-10

<wang.yubao2@zte.com.cn> Wed, 10 July 2019 03:00 UTC

Return-Path: <wang.yubao2@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92608120141 for <bess@ietfa.amsl.com>; Tue, 9 Jul 2019 20:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nUmliOZETxND for <bess@ietfa.amsl.com>; Tue, 9 Jul 2019 20:00:51 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 8CAC31200D5 for <bess@ietf.org>; Tue, 9 Jul 2019 20:00:50 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 6905F4F7B433AA728363; Wed, 10 Jul 2019 11:00:48 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id x6A30Jnw062021; Wed, 10 Jul 2019 11:00:19 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Wed, 10 Jul 2019 11:00:14 +0800 (CST)
Date: Wed, 10 Jul 2019 11:00:14 +0800 (CST)
X-Zmail-TransId: 2afa5d2554be1d568f6e
X-Mailer: Zmail v1.0
Message-ID: <201907101100141999170@zte.com.cn>
Mime-Version: 1.0
From: <wang.yubao2@zte.com.cn>
To: <pbrisset@cisco.com>, <hshah@ciena.com>
Cc: <bess@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x6A30Jnw062021
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/nmGK6ma4iK5vxgSZhRu8QQBzrA4>
Subject: [bess] =?utf-8?q?Review_of_draft-ietf-bess-l2vpn-yang-10?=
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 03:00:55 -0000

Hi authors,






I reviewed the draft and I have a question on the endpoint with the choice of "ac" case.





When we configure the "ac" case of the "endpoint" node according to this draft,

is it still necessary or not for us to configure the "bind-network-instance-name" leaf of the "interface" node as per RFC 8529?

It seemed that we technically don't need another yang model to bind a L2VPN AC to it's VPLS/VPWS instance,

because the information here is already technically enough.

Can you clarify this ? Thanks.




<snip>


       +--rw endpoint* [name]


       |  +--rw name                      string


       |  +--rw (ac-or-pw-or-redundancy-grp)?


       |  |  +--:(ac)


       |  |  |  +--rw ac* [name]


       |  |  |     +--rw name     if:interface-ref


       |  |  |     +--ro state?   operational-state-type

</snip>





In RFC8529, It seemed that the "bind-network-instance-name" is assumed to be a VSI in L2VPN use case.




<snip>

[RFC8529] Section 3.2




module: ietf-interfaces

      +--rw interfaces

      |  +--rw interface* [name]

      |     +--rw name                        string

      |     +--rw ip:ipv4!

      |     |  +--rw ip:enabled?                      boolean

      |     |  +--rw ip:forwarding?                   boolean

      |     |  +--rw ip:mtu?                          uint16

      |     |  +--rw ip:address* [ip]

      |     |  |  +--rw ip:ip               inet:ipv4-address-no-zone

      |     |  |  +--rw (ip:subnet)

      |     |  |     +--:(ip:prefix-length)

      |     |  |     |  +--rw ip:prefix-length?   uint8

      |     |  |     +--:(ip:netmask)

      |     |  |        +--rw ip:netmask?         yang:dotted-quad

      |     |  +--rw ip:neighbor* [ip]

      |     |  |  +--rw ip:ip                  inet:ipv4-address-no-zone

      |     |  |  +--rw ip:link-layer-address yang:phys-address

      |     |  +--rw ni:bind-network-instance-name?   string

      |     +--rw ni:bind-network-instance-name?   string




   The "ietf-interfaces" module [RFC8343] is structured to include all

   interfaces in a flat list, without regard to virtual instances (e.g.,

   VRFs) supported on the device.  The bind-network-instance-name leaf

   provides the association between an interface and its associated NI

   (e.g., VRF or VSI).  Note that as currently defined, to assign an

   interface to both an LNE and an NI, the interface would first be

   assigned to the LNE using the mechanisms defined in [RFC8530] and

   then, within that LNE's interface module, the LNE's representation of

   that interface would be assigned to an NI.




</snip>










Best Regards


Bob





On Tue, 02 Jul 2019 15:22:38 -0700

internet-drafts@ietf.org wrote:




> 

> A New Internet-Draft is available from the on-line Internet-Drafts directories.

> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

> 

>         Title           : YANG Data Model for MPLS-based L2VPN

>         Authors         : Himanshu Shah

>                           Patrice Brissette

>                           Ing-When Chen

>                           Iftekar Hussain

>                           Bin Wen

>                           Kishore Tiruveedhula

> 	Filename        : draft-ietf-bess-l2vpn-yang-10.txt

> 	Pages           : 49

> 	Date            : 2019-07-02

> 

> Abstract:

>    This document describes a YANG data model for Layer 2 VPN (L2VPN)

>    services over MPLS networks.  These services include point-to-point

>    Virtual Private Wire Service (VPWS) and multipoint Virtual Private

>    LAN service (VPLS) that uses LDP and BGP signaled Pseudowires.  It is

>    expected that this model will be used by the management tools run by

>    the network operators in order to manage and monitor the network

>    resources that they use to deliver L2VPN services.

> 

>    This document also describes the YANG data model for the Pseudowires.

>    The independent definition of the Pseudowires facilitates its use in

>    Ethernet Segment and EVPN data models defined in separate document.

> 

> 

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-bess-l2vpn-yang/

> 

> There are also htmlized versions available at:

> https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-10

> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2vpn-yang-10

> 

> A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2vpn-yang-10

> 

> 

> 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/

> 

> 

>