Susan, In chapter 2 Definitions there is a copy/paste error I presume
PWE3: Pseudo Wire Emulation Edge-to-Edge EPC: Pseudo Wire Emulation Edge-to-Edge Presume that EPC = Evolved Packet Core Have several comments for the rest of the draft, as it is somewhat not clearly written. I can't figure out what is the plan for the access and what for the aggregation networks in mobile backhaul. In Application configuration chapter 3.1, the draft talks about protecting legacy radio networks, but it doesn't discuss that todays MBH are designs, access (hub and spoke) and aggregation networks (rings with IP/MPLS and IGP, mostly OSPF, overlay). In same chapter, The radio architecture evolution will bring out new radio interfaces, such as the X2 interface in LTE which will not work in hub-spoke communication mode and needs much more shorter latency. Introduction of X2 shortens the latency for control and data traffic, as now eNodeBs can communicate directly, not as before via RNC. With X2 interfaces, can create mesh topology in MBH access part, which allows multi path to EPC from each eNodeB. With introduction of 5G networks, as spectrum allocation will be dynamic, the bandwidth requirements will fluctuate from different areas, depending on the allocated spectrum to the eNodeBs. 2. various radio applications next gen networks (actually this was definition and requirement for 4G) are IP networks, so real-time applications like voice and video should be IP applications, not really radio applications. The classifications for traffic should be real-time, near-realtime non-real time user traffic and control traffic. As radio should carry only data and signaling, there should be no other differentiation. 3. various network architectures: The mobile backhaul network maybe consist of hundreds of nodes in a small county or thousands of nodes in a populous region. It will be an integration of different ASNs rather than a single AS, when EPC is deployed in the Core network with LTE. The network devices on different points of the network (e.g. access\aggregation\core) have different routing and protocol processing capabilities, resulting in an integration of different IGP routing areas rather than a single large IGP routing area. Within various network architectures, different service modes should be provided, such as SS- PW or MS-PW, E2E L3VPN or HVPN, Seamless MPLS, and the integration of them. Can you please clarify this chapter? MBH topologies today are very much geographically created and connected to the core, so for example network operator in Boston will have access and aggregation network connected to the core in Boston and this will be within single AS. The edge device between aggregation and core is connected to multiple ASNs, but not devices with access and aggregation networks? Do you expect to see devices in access networks to be connected to different ASNs? In 3.2 are you looking to use BGP as IGP and EGP protocol? Why not run IGP in access networks, as those are mesh topologies with X2 interfaces, especially as X2 has same S1 characteristics for E-UTRAN service continuation. Also eNodeBs will be often connected via wireless connections (microwave), so using an IGP in access part of the mobile backhaul should be considered and how to manipulate certain metrics based on the wireless backhaul portion performance. Do you presume running pseudo wires all the way through the access portion of MBH or just to the pre-aggregation site? If you could clarify the network topology in mind, that would be helpful. I believe there are different requirements for access and aggregation part of the mobile backhaul for i2rs and that your draft is more applicable to the aggregation part of mobile backhaul. Regards, Dean On Mar 6, 2014, at 5:01 AM, Susan Hares <[email protected]<mailto:[email protected]>> wrote: During the last two weeks, people have indicated interested in mobile backhaul cases. We would appreciate input on the following draft: https://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/ If you are interested in chatting about this draft would you please contact me ([email protected]<mailto:[email protected]>). For those who are at the IETF and would like to talk about MBB over beer, join us at the IETF registration desk at 7:30pm (Thursday 3/6/14). Sue Hares <Untitled attachment 00301.txt>_______________________________________________ i2rs mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
