[i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

Don Fedyk <dfedyk@labn.net> Wed, 05 August 2020 17:38 UTC

Return-Path: <dfedyk@labn.net>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 845AB3A0E19 for <i2rs@ietfa.amsl.com>; Wed, 5 Aug 2020 10:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zK9mOwzbvsO2 for <i2rs@ietfa.amsl.com>; Wed, 5 Aug 2020 10:38:32 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D7F3A0E8D for <i2rs@ietf.org>; Wed, 5 Aug 2020 10:38:31 -0700 (PDT)
Received: from cmgw10.unifiedlayer.com (unknown []) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id B3FA4175D82 for <i2rs@ietf.org>; Wed, 5 Aug 2020 11:38:30 -0600 (MDT)
Received: from box313.bluehost.com ([]) by cmsmtp with ESMTP id 3NN0koJHoDlyd3NN0kzsg8; Wed, 05 Aug 2020 11:38:30 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=QtBwI26d c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=kj9zAlcOel0A:10:nop_charset_1 a=y4yBn9ojGxQA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=HLvPDLHGFjgA:10:nop_election2020_name_subject a=KwIv_cxWQxYHak7Tpn4A:9 a=WiJ_-Dz12mbO2Msl:21 a=hBgeOQhVO5bpUg1-:21 a=0zN2VfR8ED-94fFr:21 a=CjuIK1q_8ugA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=jd6J4Gguk5HxikPWLKER:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Og5ou9V3w0G0QYKBVJn2AGXXsL9dkBYi7S2ViiAHyIs=; b=DNNUESX/vSiOBxLU8qINDSwn2z kUWxGsDH3dxj2qfrp5WYOL2ZZcJHuqkKDvxGF7sxsBbcQBZ7GpSXn8Kw3Oi68CrWmKYQy17jqWufK UEn56C8JpjgG3M7vUooKzZmYa;
Received: from pool-173-48-105-206.bstnma.fios.verizon.net ([]:58273 helo=FedykLabn) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <dfedyk@labn.net>) id 1k3NN0-003fVl-98; Wed, 05 Aug 2020 11:38:30 -0600
From: Don Fedyk <dfedyk@labn.net>
To: i2rs@ietf.org
Cc: shares@ndzh.com, 'Scott Mansfield' <scott.mansfield@ericsson.com>, 'Glenn Parsons' <glenn.parsons@ericsson.com>
Date: Wed, 05 Aug 2020 13:38:29 -0400
Message-ID: <01a001d66b4f$3c133b10$b439b130$@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdZrTk/1Fc4GePNcT+iHzdNCMEXHrA==
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1k3NN0-003fVl-98
X-Source-Sender: pool-173-48-105-206.bstnma.fios.verizon.net (FedykLabn) []:58273
X-Source-Auth: dfedyk@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/NtnhmhouhLbSv6nU2xX_wFw0to8>
Subject: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 17:38:35 -0000

IEEE 802.1 were asked to give feedback on the L2 topology model. 
We thank the I2RS WG for the opportunity.  

Executive Summary:
An alternative structure to the l2 topology information is suggested.  The
rational is based on how bridges are described in IEEE 802.1Q-2018 and the
structure used models the structure from analogous models.


As a reference we compared the L3 in topology in RFC8346 with L2 in

   module: ietf-l3-unicast-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw l3-unicast-topology!
     augment /nw:networks/nw:network:
       +--rw l3-topology-attributes
          +--rw name?   string
          +--rw flag*   l3-flag-type
     augment /nw:networks/nw:network/nw:node:
       +--rw l3-node-attributes
          +--rw name?        inet:domain-name
          +--rw flag*        node-flag-type
          +--rw router-id*   rt-types:router-id
          +--rw prefix* [prefix]
             +--rw prefix    inet:ip-prefix
             +--rw metric?   uint32
             +--rw flag*     prefix-flag-type
     augment /nw:networks/nw:network/nt:link:
       +--rw l3-link-attributes
          +--rw name?      string
          +--rw flag*      link-flag-type
          +--rw metric1?   uint64
          +--rw metric2?   uint64
     augment /nw:networks/nw:network/nw:node/nt:termination-point:
       +--rw l3-termination-point-attributes
          +--rw (termination-point-type)?
             |  +--rw ip-address*       inet:ip-address
             |  +--rw unnumbered-id?    uint32
                +--rw interface-name?   string

This model augments a larger topology model as we understand it.  There are
nodes and links and then termination points that represent the link
to the nodes and ultimately a topology.   

Comment on draft-ietf-i2rs-yang-l2-network-topology-15.txt.

module: ietf-l2-topology
  augment /nw:networks/nw:network/nw:network-types:
    +--rw l2-network!
  augment /nw:networks/nw:network:
    +--rw l2-topology-attributes
       +--rw name?    string
       +--rw flags*   l2-flag-type
  augment /nw:networks/nw:network/nw:node:
    +--rw l2-node-attributes
       +--rw name?                 string
       +--rw description?          string
       +--rw management-address*   inet:ip-address
       +--rw sys-mac-address?      yang:mac-address
       +--rw management-vlan-id?   dot1q-types:vlanid {VLAN}?
       +--rw flags*                node-flag-type

Management address addresses the node but tells nothing of the L2 topology.
It is an informational attribute.  Management VLAN ID is only in context
a management interface.  Sys-MAC-address is not an IEEE 802.1 term.
unique bridge address is the MAC address that is the base of Bridge
and SystemID (the generic form of Bridge identifier) IEEE 802.1 Management
addresses are specified for some devices in 802.1Q primarily for Two port
relay which by definition has a limited number of ports and is men to be
managed in-band. The address may part of a VLAN and reachable over a
VLAN-ID. (that VLAN ID could be different depending on the interface used.)
Management address are common on actual equipment. 

  augment /nw:networks/nw:network/nt:link:
    +--rw l2-link-attributes
       +--rw name?    string
       +--rw flags*   link-flag-type
       +--rw rate?    uint64
       +--rw delay?   uint32

IEEE 802.1 Links have portIds or unnumbered identifiers (Shortest Path
Bridging).  Delay is OK if it is a propagation delay between neighboring

  augment /nw:networks/nw:network/nw:node/nt:termination-point:
    +--rw l2-termination-point-attributes
       +--rw description?                   string
       +--rw maximum-frame-size?            uint32
       +--rw (l2-termination-point-type)?
       |  +--:(ethernet)
       |  |  +--rw mac-address?             yang:mac-address
       |  |  +--rw eth-encapsulation?       identityref
       |  |  +--rw lag?                     boolean
       |  |  +--rw member-link-tp*          -> /nw:networks/network
       |  |  +--rw auto-negotiation?        boolean
       |  |  +--rw duplex?                  duplex-mode
       |  |  +--rw default-untagged-vlan?   dot1q-types:vlanid {VLAN}?
       |  |  +--rw vlans* [vlan-id] {VLAN}?
       |  |  |  +--rw vlan-id    dot1q-types:vlanid
       |  |  |  +--rw name?      string
       |  |  +--rw qinq* [svlan-id cvlan-id] {QinQ}?
       |  |  |  +--rw svlan-id    dot1q-types:vlanid
       |  |  |  +--rw cvlan-id    dot1q-types:vlanid
       |  |  +--rw vxlan {VXLAN}?
       |  |     +--rw vni-id?   vni
       |  +--:(legacy)
       |     +--rw layer-2-address?         yang:phys-address
       |     +--rw encapsulation?           identityref
       +--ro tp-state?                      Identityref

This part has a lot of detail.  It sees a termination point is a handoff of
particular packet or frame to an interface that specifies it layer and
encapsulation.  But we are not sure.  A link mac-address may be present on a
device, but we think it is irrelevant to the model. 
The encapsulation type is OK as specifying an instance of encapsulation. 
Lag at this level is a bit confusing. While one could view a LAG as either
being a single large link it is useful to have LAG members identified
for keeping traffic streams on a specific member link.  

Member-link tp -  Is this being used to capture LAG members? 

We think Auto negation and duplex should be with the link properties. 
The encapsulation is either no tag, priority tag, one tag C-VID or S-VID or
two tags inner C-VID inner S-VID although other combinations are possible.
VLAN tags have type priority and VLAN ID.   Normally there is the addition
removal of only one tag. (VLAN tag) The VID can be specified here if it
to the VLAN that support these links. 
Note in a bridge interface map to a Bridge component that supports a VLAN.
There is no mapping of VIDs to bridge components. Instead there is a filter
forward property for each VID on a VLAN.  There are also VID translation
properties that are not captured by this model.  
It might be worth stating what the termination point model is expected here.
If an Interface and the supported VLANs is desired it would be a list of
identified by names).  Then each VLAN would have the supported VLAN-IDs.
(Note that is per interface).
If just the superset of all expected VLAN-ID received on an interface is
portrayed, then that would say nothing about the connectivity to bridge
components or the VLANs themselves. 

The other types of VXLAN and VPLS - We have not covered. 

An L2 Model analogous to the L3 model:

It might help if we show how we think the L2 model could be analogous to the
L3 model.  Compared to the L3 Model L2 networks have a physical topology of
nodes and links and build VLAN tree using spanning tree, RSTP, MSTP or SPB.
If IEEE were to build a model analogous to the L3 model but using L2
components it might look something like this: 
Note: This is a rough L2 physical model that follows the L3 paradigm.

module: ietf-l2-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw l2-topology!
     augment /nw:networks/nw:network:
       +--rw l2-topology-attributes
          +--rw name?   string
          +--rw flag*   l2-flag-type
     augment /nw:networks/nw:network/nw:node:
       +--rw l2-node-attributes
          +--rw name         inet:domain-name
          +--rw description? string
          +--rw bridge-id          uint64
          +--rw vlan-name      string
          +--rw management-address*   inet:ip-address
          +--rw management-mac
          +--rw management-vlan   string
      augment /nw:networks/nw:network/nt:link-group
        +--rw l2-lag
             +--rw member[name]
             +--rw name-ref         -> /nw:networks/network/link
     augment /nw:networks/nw:network/nt:link:
       +--rw l2-link-attributes
          +--rw name?      string
          +--rw description?  String
          +--rw type       ianaift: interface-type
          +--rw flag*      link-flag-type
          +--rw rate       uint64
          +--rw delay      uint32
          +--rw auto-negotiation?        boolean
          +--rw duplex?                  duplex-mode         

     augment /nw:networks/nw:network/nw:node/nt:termination-point:
       +--rw l3-termination-point-attributes
          +--rw (termination-point-type)?
             |  +--rw port-number?      uint32
             |  +--rw unnumbered-id?    inet:ip-address
                +--rw interface-name?   string
             +--rw outer-tag?      dot1q-types:vid-range-type
             +--rw outer-tpid?    vid-type
             +--rw inner-tag?     dot1q-types:vid-range-type
             +--rw inner-tpid?     vid-type

Explanation of the terms and assumptions:
bridge-id*   uint64 - This is the 64-bit bridge identifier.  It has 4 bits
priority 12 bits of MSTI-ID and the base bridge identifier. There may be
multiple one for each spanning tree instance.  Note this is the closest
analogy to router-id. It is unique per VLAN topology. 

vlan-name - This is the name of the VLAN. Each VLAN can have any number of
VLAN-ID (1-4094).  The actual VLAN -ID are not enumerated. Each VLAN
has a bridge-id. 

management-mac - this is a MAC address used the bridge management. I can be
the Bridge Base VID or other.  
management-vlan - this is a VLAN that supports the Management address. The
actual VLAN ID type and value would be a member of this VLAN. 

l2-lag - This is a Link aggregation group.  The attributes of the members
be the same and any encapsulation is inherited from the actual members. 

member[name] This is the list of links that belong to the group. 

Name This is the name of a link in the group as index and reference to a ll2

l2-link-attributes This is the L2 link attributes 
name - This is a string name
type - this is an iana type 
description?  String
flag*      link-flag-type  We keep the flags - not sure what the flags are
rate       uint64  this is the link speed 
delay     unint32 this is link propagation delay (which is a function of
distance to the remote link endpoint.)  
auto-negotiation?    Boolean This should belong with the l2 link
duplex?              This should belong with the l2 links. 

Termination point. 
We took a stab at the termination point
Note the IEEE bridges support VID translation - we have not capture this it
assumed that all VLAN -id received are accepted as on the wire.  The
maps to the bridge component and the component filters or forwards the
traffic.  Bridge Components also add and remove tags on the "leg" of the
bridge based on the type of component.
We have suggested vlan tagging based on terminology similar to
Typically only one tag is applied at a timebut we have allow for 2. 
The type value a TPID allows the tags to be set appropriately (one tag or

Physical topology versus VLAN topology information. 
Note: We don't believe the L2 document is trying to capture the VLAN

The physical topology of Ethernet switches consists of nodes and links.
these switches support routing as well as well as bridging. 
VLAN topology is different. VLAN had their origins with LANs and maintain a
forwarding style that has served well for 40+ years.  VLANS are maintained
switched media today but maintain broadcast, multicast forwarding that
MAC learning for unicast. 

Logically a L2 VLAN topology utilizes a forwarding tree and forwards or
filters traffic over that tree based on traffic type, VLAN -ID and rules for
that traffic type.

A VLAN topology is based on a forwarding tree (spanning trees or shortest
trees) that resides on an active topology for that VLAN.  The active
for a given VLAN is part or all of a physical bridged network and may be
static or control plan driven.  

The traffic in a VLAN has a l2 header with a VLAN tag that contains a type,
VLAN ID, priority code points and discard eligible indication.  The types
support Customer (C-VLAN) and Service provider (S-VLAN) or Backbone Service
provider (B-VLAN) topologies.  The VLAN-ID is a reusable 12 bit identifier
that associates traffic to a VLAN at a point in the topology. The Value of
ID may change over the path of the frame as one way to avoid VLAN-ID
contention.  Within a VLAN type it filters or forwards VLAN-ID tagged
based on static or dynamic (control plane) configuration.  MAC learning,
broadcast and multicast occurs within this constrained VLAN tree.  These
operations may be across all MACs within a VLAN (shared learning) or MAC-DA
and VLAN ID (individual learning).

(Note: Shortest path trees have a slightly different behavior based on the
type. To keep this explanation simple we will use spanning tree here, but
shortest path bridging is compatible with the spanning tree concepts.) It is
possible to have a single spanning tree that supports all VLANs ID
the whole tree.  Simultaneously there could be another spanning tree that is
disjoint (no shared interfaces) that also uses the same range and type of
VLAN-ID.   If at any point int eh network two VLANs share an interface the
VLAN IDs must be coordinated on that interface - the VLANs may use the same
VLAN-IDs in different parts of the network where there is no conflict.
(usually the interface is of a single VLAN type). 

Best regards