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

From: "Don Fedyk" <[email-masked]>
Date: Fri, 20 Sep 2019 09:23:36 -0400

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