Re: [ieee-ietf-coord] [Detnet] Fwd: New Version Notification for draft-vassilev-netmod-network-bridge-00.txt

[Vladimir Vassilev <[e-mail]>]

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: [e-mail]
>> To:     Vladimir Vassilev <[e-mail]>
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet
>