Hi,
did we not solve this problem with interface layering (or stacking) in
the MIB world? If so, why would we depart from that model?
/js
On Mon, Jul 13, 2015 at 12:24:28PM +0100, Robert Wilton wrote:
> Hi Michael,
>
> Thank you for your comments and review.
>
> I think that the definition of interface type is a bit vague in that
> there is a long list of interface types that seem to apply at quite a
> few different OSI layers!
>
> But in brief, the way that I perceive interface type is as a static
> property of an interface, fixed when an interface is created, that
> defines the flavour of an interface. Where appropriate I would normally
> relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM,
> etc), but there are other software interfaces where the interface type
> is defining a higher level construct (e.g. a tunnel, or sub-interface,
> or LAG group interface).
>
> My definition of encapsulation is that it provided a generic container
> for holding layer-2 related header information, where that is
> configurable. In the model that I have defined so far I have only
> defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the
> intention is that it would be augmented for cHDLC, PPP, FR and ATM. The
> example is potentially better illustrated for POS interfaces where the
> choice of encapsulation can be configured.
>
> So, if you take a POS interface as an example, then I would expect that
> the ifType would be fixed as ifType:pos, but the encapsulation of that
> interface could be cHDLC, PPP or Frame Relay. The layer 2 encapsulation
> information (such as timers, keepalive settings, crc settings, FR
> circuit ids) would live under the datalink protocol specific
> encapsulation node. The encapsulation node itself can be used to
> determine what layer 2 encapsulation is being used.
>
> Of course you could put ppp/chdlc/fr under separate containers, but it
> makes it slightly harder to ensure that an interface only has a single
> encapsulation configured. Although you could add a must statement to
> restrict the allowed encapsulations to those known today, it doesn't
> extend to other encaps types added in future. Having a choice statement
> effectively enforces the restriction that there can be only one
> encapsulation on an interface for you.
>
> Does that alleviate your concern?
>
> Thanks,
> Rob
>
>
> On 13/07/2015 09:42, wangzitao wrote:
> >Dear Authors,
> >
> >I've read your draft-wilton-netmod-intf-ext-yang-00 and have a question:
> >What is the difference between encaps-type in your yang model and
> >interface types in RFC7224?
> >
> >I also read your draft-wilton-netmod-intf-vlan-yangwhich augment the
> >if-cmn as:
> >
> > augment /if:interfaces/if:interface/if-cmn:encapsulation/
> > if-cmn:encaps-type:
> > +--:(vlan)
> > +--rw vlan
> > +--rw tags
> > ......
> >
> > But the vlan type have already defined in the RFC7224:
> >
> > identity l2vlan {
> > base iana-interface-type;
> > description
> > "Layer 2 Virtual LAN using 802.1Q.";
> > }
> > identity l3ipvlan {
> > base iana-interface-type;
> > description
> > "Layer 3 Virtual LAN using IP.";
> > }
> > identity l3ipxvlan {
> > base iana-interface-type;
> > description
> > "Layer 3 Virtual LAN using IPX.";
> > }
> >
> > Why not reuse the vlan types definding in RFC7224? And it may simplify
> > the augment target path such as:
> >
> > augment /if:interfaces/if:interface:
> > +--rw encaps-type identityref
> > +--rw vlan
> > +--rw tags
> > ......
> >
> >Best Regards!
> >-Michael
> >
> >-----邮件原件-----
> >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Robert Wilton
> >发送时间: 2015年7月9日 0:11
> >收件人: netmod@ietf.org
> >主题: [netmod] Interface Extensions YANG draft
> >
> >Hi,
> >
> >I have submitted a new draft for provides several augmentations to the
> >ietf if:interfaces to define configuration YANG for basic interface
> >parameters that are commonly supported on network devices. E.g. it is
> >includes leaves such as bandwidth, carrier delay, dampening, loopback,
> >mtu, & sub-interface parent ref, and configurable interface MAC addresses.
> >I am hoping that this draft could be adopted and standardized by the
> >netmod WG.
> >
> >https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/
> >
> >Any comments or feedback is appreciated.
> >
> >Potential points of interest/discussion may be:
> > - Is it acceptable to define standard YANG for features that are not
> > backed by any formal standard if they are commonly implemented?
> > - We've tried to restrict the leaves to just the interface types (using
> > when if:type = ...) that the configuration applies to rather than
> > adding them to all interfaces. Feedback would be welcome on whether
> > this approach is a good idea/maintainable.
> > - For MTU, I've defined two different MTU leaves because devices
> > program interface MTU in different ways based on whether the configured
> > MTU value includes the L2 header overhead or not. Is this a reasonable
> > approach?
> >
> >Thanks,
> >Rob
> >
> >_______________________________________________
> >netmod mailing list
> >netmod@ietf.org
> >https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
