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

From: <[email-masked]>
Date: Wed, 10 Jul 2019 11:00:14 +0800 (CST)

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

[email-masked] 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/