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-dra...@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/
>
>
>_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
