"I support this work and I will provide the time necessary to review the drafts as they progress through the WG"
Regards, Dan > -----Original Message----- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, December 15, 2015 10:22 PM > To: Robert Wilton > Cc: netmod@ietf.org > Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf- > ext-yang as NETMOD WG draft > > On Tue, Dec 15, 2015 at 07:12:07PM +0000, Robert Wilton wrote: > > 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://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_8023YangDesignTeam_EthernetYang&d=BQICAg&c=BFpW > Qw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA > &m=3tQyUrqfsDAP33LXzgkILy2EMU_0VWz161hD3GFUwRI&s=TrgAGrPT06kL > wOQzvXNfrBVOFWyoF77-gC0jg_K8EZI&e= ). > > > > 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. > > Thanks for the background and explanation. > > > >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. > > So what will be realistic milestones? There are many things needed to > configure a complete network using YANG models and we need to make > sure we are able to finish what we start with realistic milestones (and > realistic > really boils down to have a sufficient number of dedicated reviewers lined up > with the necessary cycles available to make the milestones happen). > > It might help the WG chairs to not only see "I support this work" > statements but also explicit "I support this work and I will provide the time > necessary to review the drafts as they progress through the WG" > statements. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- > 2Duniversity.de_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3tQyUrqfsDAP33LXzgkILy2EMU_0 > VWz161hD3GFUwRI&s=C5gBdpByRrOyMbxueDnG006pA9mM- > sXifOLKaOpwlHo&e= > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_netmod&d=BQICAg&c=BFpWQw8bsuK > pl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3tQy > UrqfsDAP33LXzgkILy2EMU_0VWz161hD3GFUwRI&s=NjmMtB78Y0S8wiF9- > qLXz4zRy6TyzebcodZpAcFoLWY&e= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
