Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

From: Lou Berger <[email-masked]>
Date: Mon, 12 Dec 2016 18:31:33 -0500

All,

This is start of a two week* poll on making
draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group
document.

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

* Given the holiday, the poll ends December 28.

Thank you,
NetMod WG Chairs

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Dec 2016 10:50:40 +0100

Support. Lada

> On 13 Dec 2016, at 00:31, Lou Berger <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: wangzitao <[email-masked]>
Date: Tue, 13 Dec 2016 09:57:34 +0000

I have read this document, and I support to adopt it.

Best Regards!
-Michael

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2016年12月13日 7:32
收件人: NetMod WG
抄送: NetMod WG Chairs
主题: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

This is start of a two week* poll on making
draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document.

Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

Thank you,
NetMod WG Chairs

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Dec 2016 12:52:11 +0000

Support. 
Thanks,
Acee

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Dec 2016 08:48:59 -0800

Support.

> On Dec 12, 2016, at 3:31 PM, Lou Berger <[email-masked]> wrote:
> 
> All,
> 

Mahesh Jethanandani
[email-masked]

---

From: Iftekhar Hussain <[email-masked]>
Date: Thu, 15 Dec 2016 18:55:37 +0000

Yes/support.

I have read this draft and believe it would be very useful for enabling many Layer 2 and Layer 3 services.

However, I do have few comments and that I would like the authors to address once the document is a WG document.

a)  Suggest to replace this text:
    "These modules allow IETF forwarding protocols (such as IPv6 and VPLS) ..." 
     with the following text:
    " These modules allow configuration Layer 2 and Layer 3 subinterfaces (e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, EVPN) and L3VPN services". 

b) The document should clearly identify the scope. For example, suggest replace this text:
        "... to interoperate with VLAN tagged traffic orginated from an IEEE 802.1Q compliant bridge". 
       with the following text:
       "... to interoperate with traffic originated from an IEEE 802.1D, 802.1Q, or 802.1AD compliant bridge."

   Note: In the data model, the draft is talking about untagged as well as 802.1AD (see  "tag type (802.1Q or 802.1ad)")
    
 c)  Are there any sub-interface level common statistics counters that the model should address?  Currently, I don't see any.

Thanks,
Iftekhar
-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, December 12, 2016 3:32 PM
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

Thank you,
NetMod WG Chairs

.

---

From: Robert Wilton <[email-masked]>
Date: Fri, 16 Dec 2016 12:13:31 +0000

Hi Iftekhar,

Thanks for the comments and support, please see inline ...

>      " These modules allow configuration Layer 2 and Layer 3 subinterfaces (e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, EVPN) and L3VPN services".
Yes, OK.  I think that this text can be tweaked.

>     Note: In the data model, the draft is talking about untagged as well as 802.1AD (see  "tag type (802.1Q or 802.1ad)")
Yes, it should mention 802.1D.  802.1ad is part of 802.1Q.  The draft 
would be best referring to S-VLANs vs C-VLANs rather than 802.1Q vs 802.1ad.

>   c)  Are there any sub-interface level common statistics counters that the model should address?  Currently, I don't see any.
A sub-interface is still just an interface, so by default it would pick 
up all of RFC7223 interface statistics.  Were you looking for any 
additional specific statistics?

However, it would probably be useful to have a counter on the parent 
trunk to indicate the number of packets that haven't been matched to any 
sub-interface, so I think that I should add that.

Thanks,
Rob

---

From: Iftekhar Hussain <[email-masked]>
Date: Fri, 16 Dec 2016 23:20:23 +0000

Hi Rob,

Regarding ".... Were you looking for any additional specific statistics?". 
As long as RFC7223 interface statistics - relevant to a  given subinterface are picked and are available on per subinterface level  that should be fine.

"However, it would probably be useful to have a counter on the parent trunk to indicate the number of packets that haven't been matched to any sub-interface, so I think that I should add that."

Yes - I think, this would be useful.

Thanks,
Iftekhar

-----Original Message-----
From: Robert Wilton [mailto:[email-masked]] 
Sent: Friday, December 16, 2016 4:14 AM
To: Iftekhar Hussain; Lou Berger; NetMod WG
Cc: NetMod WG Chairs; [email-masked]
Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

Hi Iftekhar,

>     Note: In the data model, the draft is talking about untagged as 
> well as 802.1AD (see  "tag type (802.1Q or 802.1ad)")
Yes, it should mention 802.1D.  802.1ad is part of 802.1Q.  The draft would be best referring to S-VLANs vs C-VLANs rather than 802.1Q vs 802.1ad.

>   c)  Are there any sub-interface level common statistics counters that the model should address?  Currently, I don't see any.
A sub-interface is still just an interface, so by default it would pick up all of RFC7223 interface statistics.  Were you looking for any additional specific statistics?

However, it would probably be useful to have a counter on the parent trunk to indicate the number of packets that haven't been matched to any sub-interface, so I think that I should add that.

Thanks,
Rob

---

From: Giles Heron <[email-masked]>
Date: Mon, 19 Dec 2016 19:37:37 +0000

support

a couple of quick Qs for the authors:

1) is there a reason why you have the “tags” container in the L3 interface but don’t have equivalents in the flexible encapsulation model?  since the “tags” container is the only thing inside the enclosing “vlan” container I’m not sure it’s required.

2) would it be better to rename “push-tags” as “push-tag” to stick with the convention of singular names for YANG lists?

Giles

> On 12 Dec 2016, at 23:31, Lou Berger <[email-masked]> wrote:
> 
> All,
>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Dec 2016 15:44:18 +0000

Hi Giles,

Thanks for the support, and comments.

> 1) is there a reason why you have the “tags” container in the L3 interface but don’t have equivalents in the flexible encapsulation model?  since the “tags” container is the only thing inside the e…
I agree that these should be consistent, although I'm not sure which one 
should be changed.  Perhaps adding the tags container to the flexible 
encapsulation would be more consistent.  I thought that it was always 
good practice to put a list into a container?

> 2) would it be better to rename “push-tags” as “push-tag” to stick with the convention of singular names for YANG lists?
Yes.  I can also fix that.

Thanks,
Rob

---

From: Giles Heron <[email-masked]>
Date: Tue, 20 Dec 2016 18:08:22 +0000

Hi Robert,

> On 20 Dec 2016, at 15:44, Robert Wilton <[email-masked]> wrote:
> 
> Hi Giles,
> 
> I agree that these should be consistent, although I'm not sure which one should be changed.  Perhaps adding the tags container to the flexible encapsulation would be more consistent.  I thought that it was always good practice to put a list into a container?

Yes - in general it’s a good practice to put a list into a container.  But in this case the tag list is the only entity in the enclosing vlan container, so I’m not sure you need another level of container.  I suppose if you think you may add to the vlan container in future then there may be value in the tags container (so you can get all tags in one operation without getting the rest of the vlan container)

> Yes.  I can also fix that.

great.

Giles

---

From: Alex Campbell <[email-masked]>
Date: Wed, 21 Dec 2016 00:08:55 +0000

Yes/support

The main issue I have with this draft, that I would like to be addressed at some point, is the way it uses heavily restricted lists to model sequences of VLAN tags.
It seems to me that something like the following would be much simpler, without losing any expressive power, in most cases:

    container tags {
      leaf s-vlan {
        type dot1q:dot1q-vlan-id;
      }
      leaf c-vlan {
        type dot1q:dot1q-vlan-id;
      }
      must "s-vlan or c-vlan";
    }

where either or both tags can be specified, and only specified tags are matched (so if no c-vlan is specified then c-vlan is irrelevant for matching).

Alternatively, maybe the restrictions relating to tag type and order should be removed, so that if I *want* to have an unusual device configuration (such as pushing 3 consecutive c-vlan tags) then I am able to do so.

Also, ietf-if-l3-vlan contains a feature (l3-vlan-sub-interfaces) that gates everything in the module. This is pointless IMO. If a server doesn't support L3 vlan subinterfaces then it should not implement the module (whose entire purpose is to model L3 vlan subinterfaces).

Alex

________________________________________
From: netmod <[email-masked]> on behalf of Lou Berger <[email-masked]>
Sent: Tuesday, 13 December 2016 12:31 p.m.
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

Thank you,
NetMod WG Chairs

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Dec 2016 14:23:21 +0000

Hi Alex,

Thanks for the support and comments.

Please see inline ...

> where either or both tags can be specified, and only specified tags are matched (so if no c-vlan is specified then c-vlan is irrelevant for matching).
The using a list structure was intended to serve a couple of purposes:
(1) To easily allow the implementations to extend to more than 2 tags if 
required in the future.
(2) Using lists also provides quite a clean way that the model could be 
augmented to classify on the CoS bits or DEI bit.  Specifically it 
logically groups the data together.

> Alternatively, maybe the restrictions relating to tag type and order should be removed, so that if I *want* to have an unusual device configuration (such as pushing 3 consecutive c-vlan tags) then…
The restrictions are in there to ensure good interoperability with IEEE 
802.1Q compliant bridges.  Part of the agreement with the IEEE 802.1Q WG 
to get consent from them to allow this draft to proceed was to ensure 
and emphasize good interoperability with IEEE technologies, particularly 
given that they own the 0x8100 and 0x88a8 Ethertypes.

Of course, there is nothing preventing a vendor deviation to remove some 
of those restrictions.

> Also, ietf-if-l3-vlan contains a feature (l3-vlan-sub-interfaces) that gates everything in the module. This is pointless IMO. If a server doesn't support L3 vlan subinterfaces then it should not im…
Yes, I agree that feature looks like it is redundant in this case and 
should be removed.

Thanks,
Rob