| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Glen, Some feedback on your questions / comments: 1) Some operators explicitly filter any frames in upstream transmitted with multicast address(es). That is done to prevent users from sourcing multicast content from their home and causing overload on the routing plane. To make UMT work across edges of L2 domains, we will need to define specific forwarding rules for broadcast UMT traffic, but I would suggest we avoid multicast addressing. Broadcast we control and know how to handle today (ARPs, DHCP, etc. ) but multicast would require specific new ACL rules on the edge to assure that such frames are not dropped. 2) I am not sure a new Ethertype is required. I would use a subtype (say, 0x00) for control traffic and keep it within the same Ether domain. Let’s not create too many protocols – it would be a hard sale to get two Ethertypes, especially when the volume of control traffic is not that extensive here outside of discovery phrase. 3) As indicated in 1), I believe we will need to flood only ports designated as UMT ports. Otherwise, UMT will leak into whole L2 domains, creating potentially broadcast storms in multiple locations. A really bad thing to have, and we would need to keep running spanning trees to prevent the occurrence of loops. Today, we have redundant links, but they are controlled at IP+MPLS level for traffic engineering, but from L2 perspective they might create loops. It is a complex topic once you leave the access and move into metro and core networks. Slide 2 does not show CNU discovery stage. I assume that UMT discovery is sent by FCU when a new CNU is discovered. Is that a correct assumption? Or rather is the initial 3 message sequence intended to register FCU as an UMT node with the controller and enable for UMT transport for CNUs that are discovered and register later on? Marek From: Glen Kramer [mailto:gkramer@xxxxxxxxxxxx] Dear Colleagues, At the last meeting, we have discussed the initial version of the UMT discovery protocol (v1) and produced an updated version (v2) as a result of this discussion (see http://www.ieee1904.org/2/meeting_archive/2014/12/tf2_1412_kramer_3.pdf ) Attached here is version 3 (which is just a cleaned up version 2) with some additional questions that need to be clarified. Also, at the last meeting, I took an action item to “show a protocol diagram simplified for EPoC”. The simplification would come from the fact that the Client-Side End Point (CSEP) and the management client are part of the same device (CNU or FCU), and the Server-Side End Point (SSEP) and UMT Domain Controller are part of the OLT. The second page of the attached document shows this simplified EPOC use case. Please, review and let us further discuss on the reflector. Glen |