Hi Victor, Traveling back from München I found some time to write feedback on the stitching framework. I tried to be complete, listing both comments made by others and myself during the gphn session. Please keep GHPN <ghpn-wg@ogf.org> in the loop for replies (I'm not sure if you are subscribed; if not: http://www.ogf.org/mailman/listinfo/ghpn-wg) Regards, Freek 1. Deployment If this framework is deployment, must all domains along a path participate? What happens if one domain has decided not to deploy it? Would it still be usable for the other domains? 2. Transparency Must a domain tell its direct neighbours all details, also if those details are only relevant for domains further along the path? 3. Layer Dependencies In the current proposal, each domain announces the different Types it wants to negotiate, e.g. "IP", "Ethernet", "Physical", "UserSLS", and "energy". Some of these types represent a certain technology (IP, SDH, Ethernet, Physical), but _there is no order between these types_. This is fine in the following scenario (as you had on your slides): Type Domain 1 Domain 2 Domain 3 IP * * Ethernet * * * * Physical * * * * (a star means the domain announces/supports that specific type.) This leads to the following negotiation between the domains: Type Domain 1 Domain 2 Domain 3 IP * <---------------> * Ethernet * <---> * * <---> * Physical * <---> * * <---> * Which is great. However, what if domain 2 decides no longer to negotiate the Physical type (perhaps because it thinks it is nonsense because it is static anyway): Type Domain 1 Domain 2 Domain 3 IP * * Ethernet * * * * Physical * * In that case, the stitching framework still sees no problem, and will initiate the following parameter negotiations: Type Domain 1 Domain 2 Domain 3 IP * <---------------> * Ethernet * <---> * * <---> * Physical * <---------------> * I think this is wrong, should be detected as an erroneous negotiation. I believe this problem can easily be solved by introducing an "(layer) depency" that is _optionally_ announced by every domain. In this case, domain 3 would announce a dependency from Ethernet on Physical, meaning that the Peering domain of the Physical type must either be the same as the Peering domain of the Ethernet type, or closer in the path. For a dependency from IP on Ethernet, this is true (the Ethernet peering domain is closer in the path than the IP peering domain), but for a dependency from . Because the dependency is announced by the domains, instead of an inherent property of the type, this allows flexibility and easy introduction of new types later. 4. Optional Types Is it possible to announce an "optional" type? For example, a domain may announce that it is willing to negotiate about "Energy" type or the "userSLS" type, but it fine to forfeit the parameter negotiation of this particular type if the Peer Domain is not willing or capable to perform the negotiations? (I have the impression that you already gave this some though, so there might be another way how this is already solved in the current proposal. However, I don't see it yet.) 5. Adaptation The current example describe types as different technologies, contacts or link weight parameters. It does not describe the relationship between technologies. This might -falsely- be interpreted that the framework also does not support negotiation of different adaptation parameters (which tie technologies together on the data plane). I think it does, but it might be helpful to include this as a particular example. Let's say you have 10 gigabit/s Ethernet, and want to negotiate a possible PMD (adaptation to the physical layer), and you can choose between these 8 (of the 12 that 802.3 defines): 10GBASE-KR, 10GBASE-LRM, 10GBASE-SR, 10GBASE-LR, 10GBASE-ER, 10GBASE-SW, 10GBASE-LW, or 10GBASE-EW. 6. Tunnels One of the strengths of the stitching framework is that it does not enforce a certain ordering of the layer, so it supports a tunnel with Ethernet over IP. However, what if I have a tunnel with IP over Ethernet over IP over Ethernet over Physical, and I like to negotiate parameters for all of them. In that case, there are two sets of parameters for the types "IP" and "Ethernet". Is the stitching framework capable of making sure that the one set of parameters is properly negotiated with the correct other set, or is it random which set is chosen? 7. Physical The physical type is IMHO an ill-defined type. The parameter negotiation differ wildly depending if the physical layer is electrical or optical. I recommend to change this to change the example to an Electrical and Optical type. 8. WS-Agreement It seems that this framework could very well make use of WS-Agreement, which apparently provides a exchange mechanism to negotiate on certain parameters. 9. Who? Who has the time and willingness to pull the effort of making the ideas into a protocol? Feedback Stitching Framework 1. Deployment If this framework is deployment, must all domains along a path participate? What happens if one domain has decided not to deploy it? Would it still be usable for the other domains? 2. Transparency Must a domain tell its direct neighbours all details, also if those details are only relevant for domains further along the path? 3. Layer Dependencies In the current proposal, each domain announces the different Types it wants to negotiate, e.g. "IP", "Ethernet", "Physical", "UserSLS", and "energy". Some of these types represent a certain technology (IP, SDH, Ethernet, Physical), but _there is no order between these types_. This is fine in the following scenario (as you had on your slides): Type Domain 1 Domain 2 Domain 3 IP * * Ethernet * * * * Physical * * * * (a star means the domain announces/supports that specific type.) This leads to the following negotiation between the domains: Type Domain 1 Domain 2 Domain 3 IP * <---------------> * Ethernet * <---> * * <---> * Physical * <---> * * <---> * Which is great. However, what if domain 2 decides no longer to negotiate the Physical type (perhaps because it thinks it is nonsense because it is static anyway): Type Domain 1 Domain 2 Domain 3 IP * * Ethernet * * * * Physical * * In that case, the stitching framework still sees no problem, and will initiate the following parameter negotiations: Type Domain 1 Domain 2 Domain 3 IP * <---------------> * Ethernet * <---> * * <---> * Physical * <---------------> * I think this is wrong, should be detected as an erroneous negotiation. I believe this problem can easily be solved by introducing an "(layer) depency" that is _optionally_ announced by every domain. In this case, domain 3 would announce a dependency from Ethernet on Physical, meaning that the Peering domain of the Physical type must either be the same as the Peering domain of the Ethernet type, or closer in the path. For a dependency from IP on Ethernet, this is true (the Ethernet peering domain is closer in the path than the IP peering domain), but for a dependency from . Because the dependency is announced by the domains, instead of an inherent property of the type, this allows flexibility and easy introduction of new types later. 4. Optional Types Is it possible to announce an "optional" type? For example, a domain may announce that it is willing to negotiate about "Energy" type or the "userSLS" type, but it fine to forfeit the parameter negotiation of this particular type if the Peer Domain is not willing or capable to perform the negotiations? (I have the impression that you already gave this some though, so there might be another way how this is already solved in the current proposal. However, I don't see it yet.) 5. Adaptation The current example describe types as different technologies, contacts or link weight parameters. It does not describe the relationship between technologies. This might -falsely- be interpreted that the framework also does not support negotiation of different adaptation parameters (which tie technologies together on the data plane). I think it does, but it might be helpful to include this as a particular example. Let's say you have 10 gigabit/s Ethernet, and want to negotiate a possible PMD (adaptation to the physical layer), and you can choose between these 8 (of the 12 that 802.3 defines): 10GBASE-KR, 10GBASE-LRM, 10GBASE-SR, 10GBASE-LR, 10GBASE-ER, 10GBASE-SW, 10GBASE-LW, or 10GBASE-EW. 6. Tunnels One of the strengths of the stitching framework is that it does not enforce a certain ordering of the layer, so it supports a tunnel with Ethernet over IP. However, what if I have a tunnel with IP over Ethernet over IP over Ethernet over Physical, and I like to negotiate parameters for all of them. In that case, there are two sets of parameters for the types "IP" and "Ethernet". Is the stitching framework capable of making sure that the one set of parameters is properly negotiated with the correct other set, or is it random which set is chosen? 7. Physical The physical type is IMHO an ill-defined type. The parameter negotiation differ wildly depending if the physical layer is electrical or optical. I recommend to change this to change the example to an Electrical and Optical type. 8. WS-Agreement It seems that this framework could very well make use of WS-Agreement, which apparently provides a exchange mechanism to negotiate on certain parameters. 9. Who? Who has the time and willingness to pull the effort of making the ideas into a protocol?