Re: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Don,

Apologies for being so slow to get back to you on these comments.

As you are aware, I have added some examples to the document, and tweaked a little bit of the introduction text to hopefully help make it a bit more clear about how this YANG module is used in conjunction with IP or L2VPN YANG models.

If you have time, please can you take a look at the latest draft version (-07) https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ to see if you think the text is sufficient, or further explanation is required?

Regards,
Rob


From: netmod <[e-mail]> On Behalf Of Don Fedyk
Sent: 20 September 2019 14:24
To: [e-mail]
Subject: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05

Some comments on the draft :

On the content of the draft L3 Section:
Overall the draft assumes quite a bit of knowledge about L3 service configuration.  I don't know where L3 service to interfaces in the IETF models.  I'd guess it is routing to interfaces and IP forwarding based on routing but if it is defined, pointers in the draft would help.  From what I understand this draft allows a L3 service interface to terminate to an Ethernet with any combination of 2 VLAN tags.  The draft does not state it but I assume this encapsulation is symmetric.  (Symmetrical/Asymmetrical is only mentioned for L2).   Note the implied service context (what you get when you strip the tags) allows for symmetric traffic . For  L3 this is typically MPLS or IP 5 tuple etc.

On the layer 2 section:
For the L2VPN case there is already a YANG file that describes the Service VLAN tagging.   I'm trying to figure you what your draft brings to this case.  It seems to me this draft allows (more) flexible tagging for the unqualified/unqualified learning VPNs.  By allowing translation and possibly carrying more tags a single VLAN can carry more diverse traffic.  However there are subtleties in doing VLAN translation.  Without examples of applications I'm left guessing how this is intended to be applied.  Also it is not as easy for me to understand the service context as with L3 above.   How do you identify untagged traffic (or is it a tag swapping model?) In L2 VPNs the classic case of qualified learning (also called independent VLAN learning in IEEE) removes the (one) outer tag and carries the second tag in the MPLS frame.  The MPLS label stack is the context for the service. The second tag is assumed unique in the qualified domain. In Unqualified learning (or shared VLAN learning) removing the one outer tag and means the possibility collisions in the second tag space - no unique context is maintained this is where VLAN translation has typically been used.  In both cases the second tag is not changed.  One application of your draft implies to me that you support he same models but the second tag can be changed. Can you support both unqualified and qualified with the flexible tagging and does it change any of the established capabilities?  Or something else?  It would be really great clarify.   Some text on applicability with concrete L2VPN examples would help and what it offers over the current L2VPN Yang.


Therefore my suggestion is that the draft say something to the effect that:
*             The draft is limited to the a port/service interface/access model
*             The draft is agnostic to the full range of the Ethernet functions that rely on the IEEE 802.1 component model.
*             The draft uses Ethernet compatible Tagging to allow bridging in between endpoints or interworking with bridges in a with a subset functionality.*

*Note the draft is adding some other functionally that is outside/alternative to the IEEE 802.1 functions but it interworks with Ethernet on a subset.
I think you do have to revisit some the language around compatibility with compliant bridges with respect to the above points.


Best regards
Don