Hi Janos,
The concept defined in this draft goes outside the scope of 802.1Q.
Taking a subset of the OpenFlow 1.0 spec and defining corresponding
node-side YANG model with transactional flow table (/flows) and
optional support for controller introducing single RPC (transmit-packet)
and notification (packet-received) corresponding to OFPT_PACKET_OUT and
OFPT_PACKET_IN messages seemed like a natural evolution of the SDN
concept for the specification of alternative to OpenFlow southbound
protocol (e.g. over NETCONF). With OpenFlow-derived flow model
addressing 1. forwarding (switching) and adding a 2. flexible scheduler
model referencing the flows a complete bridge model is presented. It can
be implemented seamlessly on all OpenFlow 1.0 and above supporting
hardware and more importantly extensions (to flow forwarding or
scheduling) to the OpenFlow spec can be specified in YANG.
A device implementing this model can implement the 802.1Q family of
models with proper controller software (STP, LLDP etc. which is readily
available) but it is not limited to that.
We have been following closely the models developed by the IEEE TSN and
we have both reused terminology and ensured all of those standard
solutions can be represented with the generic scheduler model part of
this draft. The IEEE YANG model is great reference but is not suitable
for all applications especially when more flexibility is required and
being able to augment a module to document our vendor specific
extensions. The 802.1Q are limited in certain ways to 802.1Q (for
example fixed to 8 traffic classes either priority or time slots).
Attempts to make 802.1Q configuration more generic and a subset to a
more generic forwarding configuration mechanism are not unprecedented
(see
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/
). Here virtual interfaces instead of flows are introduced.
IMO a standard flows model is needed starting from something with
running software and trying to find consensus. I see this goal is
already part of the detnet focus
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model and
https://datatracker.ietf.org/doc/draft-geng-detnet-conf-yang
Requesting comments on the ietf netmod list seemed like a good place to
start to allow for open discussion and if we manage to identify anything
that falls into the scope of IEEE 802.1Q except the name "bridge" I
would be glad to contribute there. Same goes for the detnet WG.
Vladimir
On 08/03/2018 05:59 PM, János Farkas wrote:
Hi Vladimir,
Bridging including bridge management belong to IEEE 802.1:
https://1.ieee802.org/. You may consider contributing to IEEE 802.1.
The next Interim is hosed by your company in Oslo:
https://1.ieee802.org/meetings.
IEEE 802.1Qcp is the basic bridge management specification, which is
an approved draft standard to be published soon:
http://standards.ieee.org/findstds/standard/802.1Qcp-2018.html. (The
archived web page of the finished project:
https://1.ieee802.org/tsn/802-1qcp.)
The pages of the ongoing projects are available via the TSN page:
https://1.ieee802.org/tsn/#Ongoing_TSN_Projects, including P802.1Qcw
(https://1.ieee802.org/tsn/802-1qcw/), which specifies YANG for
various bridge scheduling mechanisms.
Best regards,
Janos
On 7/17/2018 4:26 PM, Vladimir Vassilev wrote:
Hi,
I have submitted a draft
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/
that proposes a model for network bridge management based on the
concept of flows. The model has 2 components 1. Forwarding based on
flows. 2. Scheduling/QoS based on gate controller topologies that
provide a new and very generic way of modeling and managing the
actual scheduler design and map the flows to scheduler topology inputs.
There is similar work on the flow based forwarding in detnet however
I am not sure detnet is the right workgroup to be defining the flow
model. I think the flow concept is important and general. It is as
significant as the concept of interfaces and is not only relevant to
detnet. Let me know what is your opinion of the draft and the
proposed network bridge concept.
Vladimir
-------- Forwarded Message --------
Subject: New Version Notification for
draft-vassilev-netmod-network-bridge-00.txt
Date: Sat, 14 Jul 2018 22:04:06 -0700
From: [email protected]
To: Vladimir Vassilev <[email protected]>
A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt
has been successfully submitted by Vladimir Vassilev and posted to the
IETF repository.
Name: draft-vassilev-netmod-network-bridge
Revision: 00
Title: A YANG Data Model for Network Bridge Management
Document date: 2018-07-14
Group: Individual Submission
Pages: 44
URL:
https://www.ietf.org/internet-drafts/draft-vassilev-netmod-network-bridge-00.txt
Status:
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/
Htmlized:
https://tools.ietf.org/html/draft-vassilev-netmod-network-bridge-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-vassilev-netmod-network-bridge
Abstract:
This document introduces new YANG model of a network bridge.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
detnet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
