Rob,
What makes me confuse before is that why not directly use the encapsulation
type in iana-if-type? The iana-if-type also provide a lot of encapsulation type
such as PPP, Frame Relay, etc.
Now I understood a bit. You want to provide an explicit encapsulation
information. For example, for pos interface, you may define the yang model as:
augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
"if-cmn:encaps-type" {
when "../../if:type = 'ianaift:pos'" {
case PPP{
foo;}
.....
Which indicate this is a pos interface and it encapsulation is PPP...
Is my understood right?
Best Regards!
-Michael
-----邮件原件-----
发件人: Robert Wilton [mailto:[email protected]]
发送时间: 2015年7月13日 19:24
收件人: wangzitao; [email protected]
主题: Re: [netmod] Interface Extensions YANG draft
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:[email protected]] 代表 Robert Wilton
> 发送时间: 2015年7月9日 0:11
> 收件人: [email protected]
> 主题: [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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
