Hi Qin,

Thanks for the review comments, and apologies for the delayed reply.

Please see inline ...

> -----Original Message-----
> From: netmod <[email protected]> On Behalf Of Qin Wu
> Sent: 19 August 2019 10:55
> To: Kent Watsen <[email protected]>; [email protected]
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-
> 05
> 
> I know the LC has ended. But I have a few suggestion to draft-ietf-netmod-
> sub-intf-vlan-model-05:
> 1.
> OLD TEXT:
> "
>      import ieee802-dot1q-types {
>       prefix dot1q-type;
>      }
> "
> NEW TEXT:
> "
>      import ieee802-dot1q-types {
>       prefix dot1q-type;
>       reference
>         "IEEE Std 802.1Q-2018: Virtual Bridged Local Area Networks.";
>      }
> "
[RW] 
Yes, I'll fix this.  Although I'll actually use the reference to "IEEE 
802.3.2-2019".

> 2. Suggest to add IEEE Std 802.1Q-2018 to normative reference.
[RW] 
Yes, I'll add this, again to "IEEE 802.3.2-2019".


> 3. As you described in draft-ietf-netmod-sub-intf-vlan-model,
> "
> Sub-interface 'eth1.0' is not currently bound to any service and hence
> traffic classified to that sub-interface is dropped.
> "
> Just want to confirm binding eth1.0 to l2vpn service is realized using ac
> attribute which is leafref to interface in the interface management model.
> But as described in RFC8529, binding service to interface is realized by
> using the following:
> "
>    augment /if:interfaces/if:interface:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>    augment /if:interfaces/if:interface/ip:ipv4:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>    augment /if:interfaces/if:interface/ip:ipv6:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> "
> I am wondering whether this is overdesign in RFC8529.
[RW] 

This is an interesting question.  I don't think that it affects the 
sub-interface model per se, but is a general question about how the NI model 
and L2VPN models are expected to work together.

Currently, it looks like the interface binding need to be separately defined in 
both places, i.e. once as part of the NI, and again as part of the L2VPN 
instance.  The AC definition in the L2VPN model contains more information, such 
as whether an AC is primary or backup, so I can't really see how that could be 
removed, but I also think that it is right that a NI lists the interfaces that 
comprises of.  So perhaps having these bindings twice is okay?

One related question for the NI model, is whether a binding to a parent 'trunk' 
interface automatically includes any child sub-interfaces in the NI.  I presume 
not, but there is perhaps a question as to whether this needs to be clarified 
(in draft-ietf-netmod-intf-ext-yang).

Thanks,
Rob


> 
> -Qin
> -----邮件原件-----
> 发件人: netmod [mailto:[email protected]] 代表 Kent Watsen
> 发送时间: 2019年7月10日 8:15
> 收件人: [email protected]
> 主题: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05
> 
> All,
> 
> This starts a twelve-day working group last call for draft-ietf-netmod-
> sub-intf-vlan-model-05.
> 
> The working group last call ends on July 21 (the day before the NETMOD 105
> sessions).  Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.
> 
> Thank you,
> NETMOD Chairs
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to