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

[Don Fedyk <[e-mail]>]

Hi Rob

 

Here is my feedback. -07 draft

 

The one hole I see is that there is no mention of priority mapping.  VLAN
tags have priority. (see additional behavior in the 802.1 model below). 

For Priority: 

One might  assume the traffic is 1:1 mapped for Ethernet  ingress and egress
vlans the PCP & DE being preserved.  But the document should state what
happens.  (L2 case).

1:1 mapping is not usually true for S-VLAN tag being added to C-VLAN tag
case.  Usually a C-VLAN does not access all of the outer tag priorities. 

When you add any VLAN  tag to an untagged frame there would typically be a
mapping from IP DSCP to VLAN PCP & DE. (L3 Case)

For this document you should say priority mapping is not specified or point
to where it is specified.

 

Comments on the IEEE Model:  Note this is based on the Model and how it is
supposed to work I know the industry has a wide range of equipment that can
us a hybrid models that are in between. My comments are about how the IEEE
has structured the YANG model.  


 
<https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-07#append
ix-A.2> A.2.  IEEE 802.1Q Bridge Configuration Model Overview (original
text)

 
   The key features of the IEEE 802.1Q bridge configuration model can be
   summarized as:
 
   o  Each VLAN bridge component has a set of Ethernet interfaces that
      are members of that bridge.  Sub-interfaces are not used, nor
      required in the 802.1Q bridge model.
 
   o  Within a VLAN bridge component, the VLAN tag in the packet is
      used, along with the destination MAC address, to determine how to
      forward the packet.  Other forwarding paradigms are not supported
      by the 802.1Q model.
[Don] Partially true
 
   o  Classification of traffic to a VLAN bridge component is based only
      on the Ethernet interface that it arrived on.
[Don] Classification is not the correct term. Mapping   
 
   o  VLAN Identifiers are scoped to a VLAN bridge component.  Often
      devices only support a single bridge component and hence VLANs are
      scoped globally within the device.
[Don] See comments below. It is not that devices are small why there is
little VLAN Identifier config it is because a large part of VLAN Identifiers
is control plane driven for large devices. 
 
   o  Feature configuration is specified in the context of the bridge,
      or particular VLANs on a bridge.

[Don] Oversimplifies. 

 

Here is my view of how VLANs are configured in 802.1.  Feel free to use any
or all of it.  

The main point is that the 802.1 VLAN model is quite different. 

 


 
<https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-07#append
ix-A.2> A.2.  IEEE 802.1Q Bridge Configuration Model Overview (suggested by
me)

 
Note that Bridges range from very simple devices to carrier class high
performance switches and the concepts of bridging covers a vast range of
devices used for data transport, video, audio and industrial control. VLAN
configuration is hierarchical in nature. Interfaces are mapped to bridge
components that support a VLAN.  VLANs are refined by VLAN tags which
contain type, VLAN identifiers and Priority information.
 
VLAN configuration is intentionally a high level and is often not specified
to each specific VLAN identifier on a bridge, since the control plane allows
VLAN tags to be dynamically configured. Devices also vary in how they are
configured - the following is a description of some key features of the IEEE
802.1Q bridge configuration model:
 
*        IEEE Yang Modeling follows the bridge architecture of IEEE 802.1Q.
Each VLAN bridge has one or more Ethernet interfaces that are mapped to that
component.  Sub-interfaces are not used, nor required in the 802.1Q bridge
model. 
*        802.1 Bridges maintain an active topology for each VLAN and the
VLAN identified traffic follows that topology. A Bridge is composed of
bridge components of different types. 
*        Bridges use forwarding and filtering rules to refine the traffic in
the VLAN. Bridges have properties and features that are configured on a VLAN
basis. Example data functions per component are encryption, priority
mapping, time sensitive forwarding, policing and shaping etc. 
*        Configuration maps interfaces to bridges allowing traffic received
and transmitted to be part of the VLAN. (Interfaces may be single links or
link aggregation groups - multiple links between devices that behave as one
large link.) 
*        The VLAN represents a group of traffic that uses VLAN tags to
further refine the connectivity and behavior within that VLAN. VLAN tags
identify the traffic and are used forward and filter traffic and typical
VLAN identifier configuration on the bridge includes or excludes those VLANs
or more commonly leaves the configuration to be dynamically controlled by
the control plane. 
*        Traffic on the interface may arrive with no VLAN tag or several
VLAN tag types. VLAN tags types determine the inclusion in the VLAN and the
treatment. The typical VLAN types are priority tagged, customer VLAN tagged
or provider/backbone VLAN tagged. If the interface receives a type other
than what it is expecting it will treat the traffic as untagged and flow the
rules for that interface. This is one way that multiple tags can occur on a
frame.
*        Within a VLAN on a learning bridge, MAC addresses are learned,
either shared across the VLAN identifiers or shared amongst one or more sets
of VLAN identifiers (This part is configurable by VLAN identifier/Forwarding
Identifier tables but is usually specified simply as shared learning or
independent learning for the whole VLAN). Unicast addresses are learned by
interface. Multicast addresses follow the active topology in the VLAN but
may be pruned further by other protocols.  
*        Traffic and forwarding rules are bidirectionally congruent such
that if a VLAN tag is added at an interface in the forward direction, it is
removed in the reverse direction. 
*        VLAN tags contain priority information that determines the traffic
treatment as it is forwarded. (Within a VLAN traffic streams may be used to
refine the traffic behavior further if the device supports stream filters.)
*        As a rule, each Bridge component considers only the outer VLAN tag
however Bridge components can be cascaded within Ethernet switches or
between switches to handle multiple VLAN tags such as required by provider
bridging or provider backbone bridging. 
*        Many Ethernet bridge devices support VID translation on interfaces.
This is a capability that is localized to an interface mapping VLAN
identifiers to other VLAN identifiers. This capability is primarily used to
prevent VLAN Identifier number conflicts between networks run by different
administrations.
*        Per interface the VLAN Identifiers are scoped to a VLAN bridge
component, but switches may vary in the numbers bridge components and
interfaces supported. The same VLAN identifiers may be reused in disjoint
VLANs. 
 

 

 

I also found errors in the XML config examples.  I used Yanglint and the
attached xml - the etfSubInterface identity is required to be configured by
the xpath when statement. 

There is also some confusion with  prefixes used. ietf-if-extensions
replaces ietf-interfaces-common ?

Yanglint did not like one of the IPv6 addresses  and I'm pretty sure there
is a typo where the parent interface should be eth1 but yanglint does not
care. 

As far as I can tell the YANG modules are OK but the config examples are
outdated and do not validate. 

 

I'm not sure about the format config statement in the xml - I used the
following yanglint commands to validate the attached config.

> load iana-if-type

> load ieee802-dot1q-types

> load ietf-if-flexible-encapsulation  

> load ietf-if-vlan-encapsulation

> load ietf-network-instance

> load ietf-l2vpn

> feature  ietf-if-flexible-encapsulation --enable *

> feature  ietf-if-extensions --enable *

> data  -t config   -f json ietf-flex-test1.xml

> data  -t config   -f json ietf-flex-test2.xml

 

List of the loaded models:

              i ietf-yang-metadata@2016-08-05

              I yang@2017-02-20

              i ietf-inet-types@2013-07-15

              i ietf-yang-types@2013-07-15

              i ietf-datastores@2018-02-14

              I ietf-yang-library@2019-01-04

              I ietf-interfaces@2018-02-20

              I iana-if-type@2017-01-19

              I ieee802-dot1q-types@2018-03-07

              I ietf-if-extensions@2019-11-04

              I ietf-if-flexible-encapsulation@2020-07-13

              I ietf-if-l3-vlan@2019-11-04

              I ietf-ip@2018-02-22

              i ietf-yang-schema-mount@2019-01-14

              I ietf-network-instance@2019-01-21

              i ietf-routing-types@2017-12-04

              I ietf-pseudowires@2018-10-22

              I ietf-l2vpn@2019-05-28

 

Cheers

Don

 

From: Rob Wilton (rwilton) <[e-mail]> 
Sent: Monday, July 13, 2020 5:54 PM
To: Don Fedyk <[e-mail]>; [e-mail]
Subject: RE: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05

 

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/>
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] <mailto:[e-mail]> > On
Behalf Of Don Fedyk
Sent: 20 September 2019 14:24
To: [e-mail] <mailto:[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