Hi there Here are some initial comments on the ABNO draft, although I have plenty more thinking to do on the topic!
Cheers Jon Cross-Domain Orchestration (section 3.1) Your examples all show a single ABNO controller orchestrating across all domains. I'm not sure if that is baked into the proposed architecture but I don't think you should assume this. Of the options given for programming the data plane, some don't work if the child PCEs have returned a Path-Key. * 3b - doesn't work with Path-Key (& how does it talk to the data plane in a different AS?). * 3c - ditto. The architecture presents a lot of options for how the data plane gets programmed. It's good to have flexibility but it's potentially confusing to have too many tools to do the same job. I'd rather focus on a restricted solution. My picture of how this would work is * Child PCE sets up LSP within its domain (either through LSP initiation via the network layer control plane, or talking direct to the network layer data plane via OpenFlow etc.) * Parent PCE sets up the LSP stitching hops on the inter-domain links (again via network layer control plane or direct to data plane) * ... generalizes to grandparent PCE etc. The difference with your draft is that the parent PCE, not the ABNO controller, takes care of the next layer up. One immediate question this prompts (to me anyway) is whether the LSP created by the parent PCE should be stitched or tunnelled through the LSPs created by the child PCEs. On this subject, there is interest in stateful PCE currently, but nobody has really put forward any ideas on inter-domain (that I know of?). I think the combination of stateful PCE and H-PCE is a powerful one. Multi-Layer Networking (section 3.2) The example shows a single ABNO controller orchestrating across all layers. Again, not sure if that's a general restriction, and I don't think you should assume this. Second paragraph says that optimization should be coordinated between layers rather than each layer being optimized independently. But in step 3, the mechanism does suggest that each layer's path is computed by an entity knowing only the topology of that layer and is hence independent. I realise that you are just repeating stuff from RFC 5623 and so it could be I have misunderstood that RFC and need to read it again, and I suppose therefore I'm really making a comment about RFC 5263. I will note that inter-domain PCE has solved this distributed optimization problem in two ways, BRPC and H-PCE. If we viewed each "layer" as a "domain" for path computation purposes then we can solve cross-layer optimization in the same way, can't we? But that somewhat changes the role of the VNTM, I think. Step 6: what kicks the packet-layer PCE to re-do / complete its computation? GCO (section 3.5) Section 3.5.1 does not finish the job... Once the new set of optimized paths is finally, gloriously computed, someone needs to figure out if and how they can reroute the existing LSPs into the new configuration without disrupting any traffic. This is quite a significant problem to solve in general. Who does it, in this architecture? NMS? Human operator? It turns out that this problem can be viewed as a path computation query on a particularly complicated kind of graph. If each possible "routing" of the N LSPs through the network is regarded as a vertex in an abstract graph, and vertices in this graph are adjacent if and only if one can be changed into another by rerouting a single LSP without disturbing traffic, then you are simply asking for the shortest path between the starting configuration and the globally-optimized configuration. So, this job could be done by a (particularly cunning) PCE. Other use cases Would it be worth having a use case addressing operations in a CDN? Or something involving ALTO like an client connecting to an online gaming server? Both types of application are mentioned in your introduction. Interfaces You've made a good start on this but I think over time a more formal / literal description of the interfaces is needed. E.g. * 2.3.2.7 discusses a class of interface, some members of which are defined in other sections, some are not. * 2.3.2.12 is this one interface or many? * 2.3.2.13 this section discusses two interfaces, OAM:network and OAM:controller. Will you also consider east-west interfaces between different instances of the same functional blocks? OAM Handler (section 2.3.1.6) Reporting of problems. The OAM handler can certainly report when a problem has occurred but it is not clear that it can know that the problem is service-affecting, and which services were affected. The ABNO Controller will orchestrate the remedial action in the event of an alert from OAM Handler, and it presumably is better placed to know which services have been adversely & non-transiently affected. So I think that ABNO controller should report affected services to the "ABNO Users". Misc Comments on Functional Components Figure 1 shows a line from NMS / OSS / Application Service Coordinator to ALTO Server but this interaction is not described anywhere in the text. Nits and Typos What is the significance of the dotted box enclosing most of the components in figure 1? Page 5 2nd to last paragraph "instances of the any" -> "instances of any". Page 9 1st paragraph typo "and of functional <?> and" Page 17 final bullet typo "ABNO components can may" Page 21 3rd para typo "PCE consults is TED" Page 22 1st para line 1 typo "requests is receives" Page 22 1st para line 3 typo "type of networks resources" -> "... network resources" Page 26 2nd para typo "Networks typically comprise of" (delete "of") Page 31 sec 3.5.1 1st para "objective function" -> "objective functions" Page 31 2nd to last para typo "as part of the request response" Page 32 bullet 2a typo "the the" Page 32 bullet 2a I don't understand "with the same request-IDs in the PCEP message" Page 32 bullet 2b I can't parse this
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
