Hello Freek, Thanks for making this list of the GHPN group. Really appreciated and I also want to thanks the opportunity to be able to present it. Below is my feedback. Freek Dijkstra wrote:
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?
The SF (Stitching Framework) says that are each others Peering domains need to decide together to take part or not. So they do it in pairs! Physical parameters most of the time end at the next (Neighboring) domain in the path, but higher layer parameters can end up in other domains (multiple hops further away in the path). In the prototype implementation: If one of the peering domains in a pair does not take part, the participating domain will get a warning that no peering domain has been found. As the SF can't find out where the other peering domain is (as a Peering domain can be anywhere in a path), such a warning ends up in a non implementable path. At present SF definition can only work if both parties in a peering relation take part or both don't take part. If if both peering domain (remember Peering domains pair exist at multiple layers)
2. Transparency Must a domain tell its direct neighbours all details, also if those details are only relevant for domains further along the path?
In the present form if the SF, the parameters are not send to the a domain in the path, but are send to a central entity (which can be any where): Stitching Engine: SE. In the document it is proposed that the Home domain (where a user below to) coordinates this SE activity. The Home domain does not have to take part in the realisation of the path of course.
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:
Just a small thing: there is no negotiations between domains. Each domain tells the central entity what its capabilities are and then the central entity choices a working option (if possible). If the full path is a feasible path, then the SE will confirm to each domains what parameter option are to be implemented/reserved.
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 *<---------------> *
Correct. As the SF does not know the meaning of parameter's Data (or the Type), it will end up indeed as you say. It only matches the unique combination Name.Type.
I think this is wrong, should be detected as an erroneous negotiation.
If the SF would indeed know that physical means directly connected and if it assumes it is essential, then indeed it could generate an error message. So like with your first question (Deployment); "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):" can only be done on a mutual/peering basis. So *peering* is essential/holy in SF! That peering is *holy* in SF, assumes that indeed certain domains want to work together. Without that assumption no interworking is possible (in any way or the boots trapping becomes very difficult)). This might be something where the general XML/WS activities become important: How do you find a services and how to you generate complete request?
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.
Remember that dependency of layers is *not* inherent (layers don't exist in SF). In the SF it is tried to minimize dependencies. But your proposal might work for this kind of cases. It would make it more dependanble on more rules (and thus open for change in rules in the future). This would need more study indeed.
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.)
There is an attribute 'Default' that is/was reserved for this. To be honest I have not looked in to this. As the Peering domain is essential in SF and if *both* are found for a parameter, than Default might work. So *both* peering domains have to say they are peering (and in that case Default attribute might be useable).
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.
Value of an attridute can be a list of options, so that allows for havign a chopice (and by the way the more optiosn provided by the domains, the easiest for the SE to come to a feasible path). It is possible to use the 'Dependency' attribute for making dependencies, *But* this will need more study if it works indeed for all circumstance. Again dependencies make it more difficult and perhaps it would remove the advantages.
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?
I think that when using tunneling, there is a differentiation of parameters: say a) certain physical parameters will not tunnel, also b) a tunnel might also introduce new parameters (tunnel related parameters that need to be used to demultiplex at the other peering end). So I don't think that this issues will pop up. More worked out examples would help here, to check indeed if no problems happen with tunnels.
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.
No problem, you can define any string of letters you want;-) It is up to the technology experts to define these strings of letters. <by the way: I can understand your point;-)>
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.
It would be great to get more input on this. I think indeed that the SF does something very basic (as all negotiations work in some in that way: one defines mutually the terminology and then defines rules around them: humans also do this;-).
9. Who? Who has the time and willingness to pull the effort of making the ideas into a protocol?
A good question!!! I think before working on the protocol, we need to make sure that all the point you brought up above are indeed solvable (so we need to tease things out a little more). HEAnet/GN3-JRA2-T2 are willing to work on that, hopefully with some other people. I think also that we need to have a working sample (and not only a Visual BASIC prototype;-). We are working on that with GN3. Making it a standardized protocol (*plus* guidelines, best practices, etc.): is a more difficult question. It at least needs that all the above things are satisfactory do-able. It would be great to have a PhD/student working on this? I think it is a worthwhile ideas certainly if it can help the WS framework. Thanks again for putting down all these points. All the best, Victor -- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/