Dear Qiao, Thank you very much for the feedback. It was a great exercise to study the ALTO documents and elaborate the answers.
>>It looks to me ALTO potentially provide PolKA needed data, PolKA can consume >>these data and used these data for path selection? In theory, there is no obstacle, and PolKA could consume the data provided by ALTO and use it for path selection. However, we are not yet compliant to the ALTO data models. Thus, we have to work on the integration. We envision PolKA as a complete architecture (very similar to what Segment Routing offers) that involves both management, control and data plane aspects. However, it is not yet as mature as Segment Routing. Our primary focus has been the data plane aspects, and now we are evolving the management and control aspects, including the interface with path-aware applications. At the moment, we use external path selection entities, and for a given path we are able to define at the edges an end-to-end path that will be deployed by the core nodes using our source routing mechanism. As we discuss in the next questions, we believe PolKA changes the way applications can represent source-based paths in the network, and we are starting to explore these ideas. >>1. How source routing design is different from segment routing >>developed by IETF Spring work group? The most traditional way of executing source routing is to represent the path as a list of output ports and the forwarding operation as a pop. Today, the most disseminated source routing protocol is Segment Routing. However, it presents some limitations: - it depends on expensive equipment and proprietary implementations; - its MPLS version still depends on tables in the core nodes; - it depends on variable-length headers, which limits the number of maximum hops implementable in hardware switches; and - there is no direct multicast support (https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKIPM-2249.pdf). On the other hand, PolKA is a novel source routing approach that explores the Residue Number System and Chinese Remainder Theorem by performing the forwarding as an arithmetic operation: the remainder of division. In previous works, we demonstrated that PolKA can be deployed in high-performance P4-enabled programmable switches with the reuse of the CRC hardware, and our performance is equivalent to traditional approaches. Thus, this special path encoding and routing mechanism allows PolKA to offer the following advantages: - it does not keep any table in the core network; - the packet header has fixed length and the route label does not change throughout the path; - it can represent multipaths in the network layer for any topo (M-PolKA extension: https://ieeexplore.ieee.org/document/9738811). To the best of our knowledge, there is no other multipath source routing method in the literature that is topology-agnostic, while not depending on tables in the core network. This is justified by the fact that the encoding of a multipath route label depends on the flattening of a tree, which is a non-linear structure. To tackle this problem, the related works either propose solutions tightly coupled to specific topologies (e.g. a fat-tree), or explore hybrid approaches that combine tables with SR (e.g., BIER: https://datatracker.ietf.org/doc/html/rfc8279). This problem can be solved by the RNS encoding, and our research group has been exploring it to enable a new range of complex network applications (e.g., multipath routing, telemetry, traffic splitting, proof-of-transit, …). From the application's point of view, this can be seen as an unprecedented power to represent source-based multipaths in the network. In addition, we offer an open source implementation that can interoperate with standard protocols via the RARE/freeRtr project (http://docs.freertr.org/). For instance, we get available topology information from link-state routing protocols when calculating routeIDs, and create a static table mapping Segment Routing indexes to nodeID polynomials. It is important to note that the RNS encoding is transparent to the application, which only needs to define a path as a list of addresses, which is encoded by the control plane as routeID. An introductory presentation can be found here (demonstration from 31:33): https://www.youtube.com/watch?v=68vsAWAM8C0 >>2. How ALTO network map, cost map, properties map can be leveraged or >>extended to provide needed data such as nodeID, portID, etc The ALTO network map, cost map, properties can be used by the PolKA’s Controller as input for the path selection task. Currently, once the paths are selected, the Controller maps these decisions to route labels (routeID) that are installed at the edges. In the core network, the nodes are very simple and execute the forwarding with a simple mod operation of the route label in the packet by its own nodeID, which gives the output port (portID) in each node. The nodeIDs can be seen as static node configuration, and the routeIDs are calculated using the Chinese Remainder Theorem to encode a path, which is a set of nodeIDs and their output ports for that path. Also, we envision the applications themselves could interact with the Controller and receive the appropriate route labels, acting as sources. Although we are currently evolving the management and control plane aspects of our architecture, the special properties of our data plane offers unique features that can be further explored by path-aware applications, as proposed by ALTO. >>3. Is the mechanism defined in PolKA used for overlay network or >>underlay network? Ideally, PolKA was initially proposed for programmable networks, where all the core nodes can “speak” our protocol. To enable the deployment in legacy networks, we can have some PolKA-enabled nodes in the overlay, which are connected by the underlay network. We enabled this by creating PolKA tunnels over diverse encapsulations and policy-based routing to select between these tunnels in the overlay. In fact, we are currently working in a demonstration: We create an overlay network with PolKA tunnels using virtual circuits. Then, flows can be classified, balanced and steered using Policy-based routing. We can create a number of virtual circuits by dividing the capacity of the physical links and use them to serve the flows. Underlay congestion can be detected by tunnel monitoring and signalized to the overlay, and overlay routing can steer traffic from congested tunnels to other paths. >>4. How PolkA mechanism is different from path vector solution developed >>by IETF? We don’t know the path vector solution in details, but it seems that it is related to the path selection optimization. Thus, PolKA Controller could use this to serve as the path selection mechanism, and later deploy the selected paths in the data plane. Also, it is important to note that PolKA encodes the path in a routeID using the Residue Number System in contrast to the conventional list-based representation, which transports the path information “in clear” inside the packet header. Then, PolKA core nodes use this encoded route label to discover the output ports. Please feel free to contact us if you have any doubts and we are available to schedule a call if you find interesting. Best regards, Cristina ________________________________ De: Qin Wu <[email protected]> Enviado: quarta-feira, 18 de maio de 2022 01:54 Para: Qiao Xiang; IETF ALTO Cc: Cristina Klippel Dominicini; Jordi Ros Giralt; [email protected] Assunto: RE: [alto] Schedule Cristina@IFES to talk about PolKA, a path-aware routing framework, at ALTO weekly meeting? Thanks Qiao for recommending this topic to ALTO weekly meeting and introducing Cristina to ALTO list. Generally it seem a good idea to document the design of PolKA in the IETF draft, but we need to explain how this work is related to ALTO, Segment routing, PANRG, It looks to me ALTO potentially provide PolKA needed data, PolKA can consume these data and used these data for path selection? I have a few further questions and suggestions: 1. How source routing design is different from segment routing developed by IETF Spring work group? 2. How ALTO network map, cost map, properties map can be leveraged or extended to provide needed data such as nodeID, portID, etc 3. Is the mechanism defined in PolKA used for overlay network or underlay network? 4. How PolkA mechanism is different from path vector solution developed by IETF? -Qin ???: alto [mailto:[email protected]] ?? Qiao Xiang ????: 2022?5?16? 21:00 ???: IETF ALTO <[email protected]> ??: Cristina Klippel Dominicini <[email protected]> ??: [alto] Schedule Cristina@IFES to talk about PolKA, a path-aware routing framework, at ALTO weekly meeting? Hi Qin and all, I am writing to introduce you about Cristina Klippel Dominicini, a researcher from IFES, Brazil, and her work on path-aware routing. Last week I had a wonderful online meeting with Cristina and her team. They are working on PolKA, a path-aware programmable source routing framework (https://events.geant.org/event/748/contributions/575/attachments/476/647/PolKA_-_TNC_-_final.pdf). They are collaborating with the SENSE project and the GEANT team to demonstrate and deploy PolKA. They also made presentations at previous PANRG meetings, and are considering writing an IETF draft documenting the design of PolKA. Other than the original purpose of this meeting, which was to discuss potential synergies between PolKA and network verification, I also introduced Cristina about the ALTO WG, and encouraged her to consider submitting a paper to the coming NAI workshop. Given the close tie between path-aware networking and ALTO, we think there could be synergies and potential collaborations between the PolKA team and ALTO WG. As such, I am wondering, can we schedule a time slot for Cristina to present the PolKA framework at our weekly ALTO meeting? Thanks! Best Qiao -- Qiao Xiang Professor, Xiamen University ________________________________ Esta mensagem (incluindo anexos) contém informação confidencial destinada a um usuário específico e seu conteúdo é protegido por lei. Se você não é o destinatário correto deve apagar esta mensagem. O emitente desta mensagem é responsável por seu conteúdo e endereçamento. Cabe ao destinatário cuidar quanto ao tratamento adequado. A divulgação, reprodução e/ou distribuição sem a devida autorização ou qualquer outra ação sem conformidade com as normas internas do Ifes são proibidas e passíveis de sanção disciplinar, cível e criminal.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
