Hi Juergen,
Hopefully I can answer your questions inline ...
On 15/12/2015 17:08, Juergen Schoenwaelder wrote:
On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
The minutes for IETF 95 show that there was in-room support for adopting
draft-wilton-netmod-intf-ext-yang as a WG draft. The minutes also show that
this decision would be confirmed on the mailing list, which I am doing now.
Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and
correspondingly add this to the WG charter as a milestone? Please comment by
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge
whether or not there is consensus to move forward with the document.
This I-D contains some Ethernet specific definitions. Are we going to
define Ethernet specific things in the IETF or is IEEE ready to take
over data models for 'their' interfaces? In other words, what exactly
is the scope of this work?
There is an informal IEEE 802.3 Ethernet design team (that has the
backing of the 802.3 WG chair, and that I'm part of) that is working on
YANG models for Ethernet interfaces. The intention is that this
informal design team will become a formal IEEE 802.3 WG design team once
it traverses the necessary IEEE 802.3 WG processes (i.e. likely to be
sometime later on next year). The exact scope of this project hasn't
been defined yet, and can't formally be defined until the IEEE 802.3 WG
agrees that we can do it, but my expectation is that the long term goal
will surely be to define YANG models to cover all of the 802.3 work,
although there may be various interim goals along the way.
In the interim, whilst we wait for the formal WG to be started, the
Ethernet design team are working on Ethernet models in Github
(https://github.com/8023YangDesignTeam/EthernetYang).
How does that overlap with draft-wilton-netmod-intf-ext-yang? The basic
answer is that it shouldn't and arguably doesn't. The only thing that
it defines related to Ethernet is three leaves related to MAC address
(configured value, operational value, and burnt-in value) that are
applicable to all interfaces that use Ethernet framing. There are
various types of interface that use Ethernet framing but are not
Ethernet interfaces, nor necessarily defined in IEEE. I.e. I'm thinking
of interfaces where a VPLS instances terminates to a layer 3 forwarding
instances, or where a pseudo-wire is terminated directly to a layer 3
forwarding instance. But at the end of the day, if this part of the
draft needs to be defined as part of the IEEE 802.3 space then I think
that would be fine too - I don't think that it should really be an
issue, and I think that we can involve the necessary folks to ensure
that this bit gets to the right home.
And (likely depending on the answer to the first question), is it
meaningful to produce an interface extension module or is it better to
simply carefully revise the model we already have?
I'm not sure that I know the answer to this one.
Some of the extra configuration that is being defined by this module is
more router specific, whereas I see the base interfaces model as
potentially having a wider applicability across devices.
If we add something to the work of this WG, what will be realistic
milestones and how do we make sure we stay focused? Is there a need
for some prioritization?
I believe that at least some of this configuration is required to
configure networks in a reliable way, so I would have thought that we
need to progress these models at the same time as the routing protocol
models.
On a related note, any VPLS or Pseudowire models defined by IETF are
basically going to be undeployable without
draft-wilton-netmod-intf-vlan-yang-01 (or an equivalent) being defined
because there will be no configuration mechanism to bind the
classification of traffic from a particular VLAN to a VPLS instance.
Note that I don't see that any models coming out of IEEE 802.1Q are
likely to help here. This point was also raised in PALS at IETF 94 by
some of the folks working on, or reviewing, those models.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
