Hi Charlie, We did the order ourselves but a sensible provisioning team at each CP would be able to co-ordinate, your point around the particular CP is valid, some just wouldn’t be able to comprehend the task I'm sure. The other issue you may come up against is that the larger CP's may not have built this in to their API's (if it's even available on the API, that I wouldn’t know.).
I've just Checked eCO and right at the bottom of the order questions there is a field "Separate From Circuit No", as far as I know as long as an ONEA for the opposing circuit goes in that box regardless of CP then the circuit is provided and diversity is maintained. You are then as a CP ordering a circuit that is contractually separate from circuit ONEAxxxxxx regardless of the provider. This caters for the eventuality (that RO2 doesn’t) that customer decides they want one line and later say 6 - 12 months that they need diversity and in this use case for separate CPs. RO2's won't always form become drivers of one another, especially if you opt for the different a-end and b-end options as there are no related drivers in that configuration. That only occurs with a common B-END. Admittedly that’s quite rare but a possibility. The issue I had with the RO options was actually with an RO1 circuit, the fibre team had no idea what an RO1 circuit was, nor that they were supposed to be installing 2 paths to the POP via different MMR's. Thanks, Graham On 03/05/2018, 10:31, "Charlie Boisseau" <[email protected]> wrote: Graeme Which other CP did you coordinate with out of interest? I think ‘asking’ for them to route something diversely to an existing ONEA is not RO2. It’s my understanding that for the diversity to be guaranteed for the life of the service (there could be maintenance or diversions done in-life that change the routing), both circuits must be in the system as RO2, and specified as being diverse of one another. I think where it may have been possible in the past, it’s no longer allowed to have one RO2 circuit and the other not. We’ve certainly not run into the issue where surveyors/planners don’t know what it is, or where the jobs are allocated to different people. If you’ve specified RO2 correctly, one order becomes the driver order for the other and they get planned together. C > On 3 May 2018, at 10:07, Graham L. Stewart <[email protected]> wrote: > > We haven't moved over to EMP yet and are able to do this just fine on eCO. > > Our experience is that the engineers coming to install often have no idea what an RO1 / RO2 order is and often turn up in droves to do the different paths. We had 4 in two days at one point completely unaware of the other path. One didn’t even understand the concept of RO1/2 or its existence of a product. > > I'm sure on eCO you can request that the circuit is a different path to an existing ONEA number for diversity either via amend or from memory there is a box on the eCO platform for this in the order questions. You have to get the planners talking or request on the second order that the planner allocated is the same as the first. Difficult I must admit but not impossible. I find my experience with open reach you just have to be persistent and use and abuse your account manager as they seem to be able to tie it all up their end! > > I'd be happy to help out if I can. > > Thanks, > > > > Graham > > -----Original Message----- > From: uknof [mailto:[email protected]] On Behalf Of Charlie Boisseau > Sent: 03 May 2018 09:38 > To: Dan Kitchen <[email protected]> > Cc: [email protected] > Subject: Re: [uknof] Openreach RO2 > > Dan, > > We’ve tried this before, having being told it’s theoretically possible but without any luck so far. I believe the issue is that in the old days where everyone was using eCo to place orders it might have been possible, but now that we and many other CPs are using EMP, the system won’t allow it. RO2 orders are difficult to get successfully placed in EMP in any case, because you have to place the orders as non-RO2, then place AMEND orders to change them to RO2. Any discrepancies between the two orders will automatically reject - and there doesn’t seem to be any pattern to what will break it and what works. If your adding a second circuit to be diverse of something that already exists, you have to place an AMEND on the new order only after the MODIFY on the existing circuit. As you can imagine, trying to persuade another CP to do this song and dance alongside you might be difficult. If they’re not on EMP yet, you’ve got almost no chance. If you’re both still on eCo, you might be able to - but it’s still not straightforward. > > In my experience, you’re better asking a single provider to place both orders for you. While this sounds counterintuitive, at least you/they have full visibility end-to-end and can demonstrate the resiliency/diversity available. TalkTalk are particularly helpful in my experience at doing this. Depending on where you’re trying to serve, they will be able to offer different levels of diversity including tail only, exchange level, collector node (PE), core (P) and NNI. > > Hope that helps. > > C > > Charlie Boisseau > CTO, Commsworld Ltd > > T: +44 (0) 131 290 2090 > Twitter: @charlieboisseau > www.commsworld.com > [email protected] > > >> On 2 May 2018, at 21:01, Dan Kitchen <[email protected]> wrote: >> >> Does anyone have any experience of this in practice when using two different wholesale ethernet carriers? >> >> We are trying to deliver a resilient path circuit to a client, but at the same time using a different layer 2 ethernet carrier to avoid any single point of failure in their network in addition. >> >> We are being told that because these circuits are effectively with different Openreach customers RO2 just can’t be done – which I can’t believe is correct? >> >> Kind Regards, >> >> Dan >> >> >> >> >> >> Dan Kitchen >> Managing Director >> razorblue | IT Solutions for Business >> >> ddi:0330 122 7143 | t: 0333 344 6 344 | e: [email protected] | >> w: razorblue.com >> >> >> <118050221015503281.png> >> Legal and address information for all Razorblue Group companies can be >> found at www.razorblue.com/contact. >> <118050221015501681.png> >> >
