Re: [netmod] Interface Extensions YANG draft

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: Robert Wilton [mailto:[e-mail]] 
发送时间: 2015年7月15日 17:40
收件人: Qin Wu; wangzitao; [e-mail]
主题: Re: [netmod] Interface Extensions YANG draft

Hi Qin,

On 15/07/2015 02:57, Qin Wu wrote:
>>> More naturally it feels that the interface layering is more useful 
>>> to represent LAG interfaces or VLAN sub-interfaces, which can be 
>>> done,
> [Qin]: Is your proposal about interface extension for L2 sub-interface?
Not just L2 sub-interfaces.

draft-wilton-netmod-intf-ext-yang-00 covers general interface properties that are common to many interface types on network devices.
I.e. (from the draft) it provides the following augmentations to
if:interfaces:

    o  A bandwidth configuration leaf to specify the bandwidth available
       on an interface to control routing metrics.

    o  A carrier delay feature used to provide control over short lived
       link state flaps.

    o  An interface link state dampening feature that is used to provide
       control over longer lived link state flaps.

    o  An encapsulation container and extensible choice statement for use
       by any interface types that allow for configurable L2
       encapsulations.

    o  A loopback configuration leaf that is primarily aimed at loopback
       at the physical layer.

    o  MTU configuration leaves applicable to all packet/frame based
       interfaces.

    o  A transport layer leaf to indicate whether the interface handles
       traffic at L1, L2 or L3.

    o  A parent interface leaf useable for all types of sub-interface
       that are children of parent interfaces.


The parent interface leaf is just one of the augmentations and is effectively the minimal information that you need to have a logical sub-interface.

[Qin]: I see, sounds like tunnel interface defined in the draft-wwz-netmod-yang-tunnel-cfg-00 also intends to support several similar properties which make me believe you guys has some same goal. Both augment if:interface with interface specific, I am wondering which one draft has better model design, one is to place all common properties in one place while the other is distribute common properties in several places within if:interface.

I have also posted a separate draft
(draft-wilton-netmod-intf-vlan-yang-00) that augments the encapsulation container described above, and uses the parent interface leaf to define how traffic is matched and classified to layer-2 and layer-3 sub-interfaces.

[Qin]: I will take a look at it and thanks for the pointer.

>>> but section 3.3 Interface Layering from YANG Interface Management 
>>> indicates that the layering attributes are read only, so you still 
>>> need separate configuration leaves to set up the parent<->child relationship.
> [Qin]: Based on RFC7223, only state leaves are required to represent 
> interface layering hierarchy, if my understanding is correct.
My interpretation of RFC7223 is a bit different, it states:
"

    There is no generic mechanism for how an interface is configured to
    be layered on top of some other interface.  It is expected that
    interface-type-specific models define their own data nodes for
    interface layering by using "interface-ref" types to reference
    lower layers.
"


I.e. you need a model specific way to specify the relationship between the nodes.

[Qin]: that's my misunderstanding on RFC7223, sorry about that, by reading appendix C of RFC7223,
I believe what RFc7223 propose is to define parent interface or base interface in the interface extension model to specify relationship between interfaces in two different layers.

E.g. parent-interface is a such configuration item.  This leaf is needed/useful for several reasons:
(1) To cleanly specify the relationship between the two interfaces. If you don't have this leaf then you would have no way of specifying the relationship between a child sub-interface and its parent is unless it is possible to infer that from the name of the child sub-interface.  
Whilst this is possible on the sub-interface naming scheme for some network devices, I don't think that this is universally true, and probably shouldn't be relied on.

[Qin]:Yes, parent-interface is needed just like why base interface is needed in the interface extension example described in Appendix C of RFC7223.

(2) If you want to define 'must' statements on the model , e.g. to ensure that a particular VLAN Id is only used on a single child sub-interface of a given parent, then having the parent leaf defined in the config namespace makes this easier.  I don't think that a must statement is allowed to check against operational leaves, so it either needs a node in the config namespace, or again would have to extract it from the sub-interface name (if that is even possible).

>> See Appendix C in RFC 7223 how this was envisioned to be done.
> Yes, I believe that the approach that we have proposed is broadly consistent with that, but defined in a slightly more generic way and without the need for the vlan-tagging leaf on the parent.
>
> However, in the model that we have proposed, it is likely that the "parent-interface" interface-ref that we define on a sub-interface has to be an optional leaf because you are not allowed to augment with a mandatory node.  So, this would come down to implementations being expected to reject sub-interface configurations if the parent-interface hasn't been correctly populated.  In some ways this is not ideal - but I can appreciate why the YANG rules are how they are.
>
> [Qin]: How is "parent-interface" define in the interface extensions different from base-interface defined in the example of Appendix C in RFC7223? It looks you both using "interface-ref" types to reference lower layers.
They are pretty much equivalent.  The main difference is that the Appendix C requires a "vlan-tagging" leaf to be configured on the parent interface, whereas the "parent-interface" leaf that I have defined does not, but has the restriction that it cannot be marked as being mandatory.

[Qin]: I can see this subtle difference between two but can't weigh one is better than the other.

Thanks,
Rob