dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
17473
share rss forum feed

resa1983
Premium
join:2008-03-10
North York, ON
kudos:10
reply to jfmezei

Re: CNOC's Part 1 Filing on the 703/704 tariffs

said by jfmezei:

The incumbent replies from yesterday were about tariffs on service charges (5 different processes)

Today is the deadline for the CNOC Part 1 final replies. Tey should be pouring in later today.

Anything interesting in the replies? Nothing's up on the CRTC site.

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

I'll try to post the replies. I really have not had the time to read any of them. and today I have to do the replit to Shaw's R&V. There are deadlines every day for some time now, with some days having multiple deadlines.


jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

Click for full size
downloadCable Carrie···tion.pdf 110,814 bytes
Cable Carriers Reply
Click for full size
download120328-The C··· ABR.pdf 318,330 bytes
Bell Canada
Here are the march 28 final replies on the CNOC Part 1

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

Click for full size
downloadCNOC Reply 2···inal.pdf 94,915 bytes
CNOC Comments
Click for full size
downloadprimus.pdf 31,939 bytes
Primus' submission
Click for full size
downloadMTS Allstream.pdf 671,896 bytes
Primus' submission
Click for full size
downloadCRTC-CNOC-Pa···tion.pdf 374,473 bytes
vaxination Informatique's submission
More submissions


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to jfmezei

Ugh, so many filings... Anybody have a summary about what's all going down?
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

incumbents: system is fine as it is.

good folks: having to purchase separate amounts of disctnct capacity for each AHSSPI link is nuts, it prevents one from using a link's capacity on other lnks when the later fails.


InvalidError

join:2008-02-03
kudos:5

said by jfmezei:

good folks: having to purchase separate amounts of disctnct capacity for each AHSSPI link is nuts, it prevents one from using a link's capacity on other lnks when the later fails.

Rogers: load-balancing, fail-over, etc. sold separately.


Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

said by InvalidError:

Rogers: load-balancing, fail-over, etc. sold separately.

 
aka 'The Batteries NOT Included Equivalency'. [Think 'Big Bang Theory' episode title]

freejazz_RdJ

join:2009-03-10
kudos:1
reply to jfmezei

Top two highlights for me:
-The current model with CBB for residential and flat rate for business has created a quagmire.
-Two parties quoting an exchange between KvF and Mr. Rocca, but extracting different meanings from it.


freejazz_RdJ

join:2009-03-10
kudos:1
reply to jfmezei

The burning question nobody seems to have answered: what kind of redundancy do the IISP's want? Take Bell GAS for example. There is already a failover mechanism in place: if an IISP LAC becomes unavailable for any reason, the session drops and is re-established on another node via round-robin. What more do the the IISP's want? CNOC seems to want something, but no specifics. At one point, they bring up issues with Bell's passport ethernet switches at which point I think they want node diversity. Then the arguments shift and it seems they want link protection. Then it seems they want both of the above, plus the ability to shift capacity from any failed link to any other link.

As for your submission JF, I like that it isn't "legalese". If only someone had actually been able to show that some of the solutions proposed can actually be implemented at a reasonable cost, if at all. I don't think it is possible to have PPPoE session failover between boxes. Nor am I aware of any mechanism whereby a pool of capacity can be dynamically allocated between disparate interfaces on disparate boxes. Please someone come up with a real, working, standards based solution that allows the redundancy desired to be provided. Until that happens, incumbents will say it can't be done and IISP's will say they (incumbents) aren't trying hard enough to come up with a solution.



Ott_Cable

@teksavvy.com

It would seem like the IISP only want to pay for redundancy at the AHSSPI link level. It is not like they can afford or care for extra redundancy for traffic inside incumbents' network cloud or to their DSLAM.

The capacity is/(should be) already a separate item from AHSSPI links. An IISP should able able to pay for X Mbps traffic capacity spread over N+M full speed AHSSPI links for redundancy. Seems to me that the incumbents want to double dip by tying the capacity cost to each of the AHSSPI links.


freejazz_RdJ

join:2009-03-10
kudos:1

said by Ott_Cable :

It would seem like the IISP only want to pay for redundancy at the AHSSPI link level. It is not like they can afford or care for extra redundancy for traffic inside incumbents' network cloud or to their DSLAM.

The capacity is/(should be) already a separate item from AHSSPI links. An IISP should able able to pay for X Mbps traffic capacity spread over N+M full speed AHSSPI links for redundancy. Seems to me that the incumbents want to double dip by tying the capacity cost to each of the AHSSPI links.

That was one of the possible interpretations, probably the most logical. N+1 (or +2, etc.) protection. That is fine, I don't think the IISP is asking for anything for free.

The issue remains that nobody has come up with a proven model by which one can allocate a number of increments of capacity dynamically over a given number of links. The only what in which this could be done to my knowledge requires all links to be fed from a single node, which would undermine the whole purpose of the redundancy in the first place: a single node failure would then drop 100% of links.

The other way of implementing this is to do the switchover to the spare ports manually. But given the MTTR for a core device outage and the time it would take for the IISP and the Incumbent to coordinate the activation, would it make a big difference?

HeadSpinning
MNSi Internet

join:2005-05-29
Windsor, ON
kudos:5
reply to freejazz_RdJ

From my perspective, I would want to have at least enough redundancy that a failure right at the edge of Bell's network, or on the transport facility (if I rent one from Bell) would be protected.

What ISPs used to do was buy more AHSSPI capacity than required, such that a single link failure or a single edge switch/router failure on Bell's network wouldn't bring the ISP down.

With capacity allocated per link, this is no longer possible.
--
MNSi Internet - »www.mnsi.net


InvalidError

join:2008-02-03
kudos:5
reply to freejazz_RdJ

said by freejazz_RdJ:

The issue remains that nobody has come up with a proven model by which one can allocate a number of increments of capacity dynamically over a given number of links.

I already proposed one years ago: LAGs.

It isn't perfect but it is standards-based, provides transparent load-balancing/fail-over and the carriers can set rates on a per-LAG basis rather than per-link basis. The main caveat is that capacity would still need to be ordered on a per-LAG basis and there would need to be as many LAGs as there are different boxes at Bell's end feeding the ISP's AHSSPIs. Not perfect but it would at least bring down the number of capacity orders from 20+ to maybe 3 if Bell was willing to remap AHSSPIs to minimize how much they might be spread around.

HeadSpinning
MNSi Internet

join:2005-05-29
Windsor, ON
kudos:5

said by InvalidError:


I already proposed one years ago: LAGs.

LAGs would be a good step forward.

I'd also like to see 10G AHSSPIs.

Right now, a provider with 20 GigE AHSSPIs ends up having to add capacity in 2000 Mbps chunks (one per AHSSPI spread evenly), and also has stranded capacity they'll never be able to use - just to have enough headroom on each individual.
--
MNSi Internet - »www.mnsi.net


Ott_Cable

@teksavvy.com
reply to freejazz_RdJ

>a single node failure would then drop 100% of links.

Chances of the entire node failing on a piece of supposedly "Carrier Grade" equipment is a lot less than the individual optic modules or at the linecard level. If by luck (or by design) Bell spread the links to an IISP onto multiple linecards, the IISP could still end up with some working link(s).

It is not like IISPs are not in the habit of finger pointing if incumbent equipment failure anyways.


jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

In my first filing, I spent some time proposing LAGs. But nobody picked up on in it their replies except Bell which summarily dismissed them as "impossible".

My guess is that the CRTC will send this to a CISC committee who could recommend a technical solution.


HeadSpinning
MNSi Internet

join:2005-05-29
Windsor, ON
kudos:5
reply to Ott_Cable

said by Ott_Cable :

Chances of the entire node failing on a piece of supposedly "Carrier Grade" equipment is a lot less than the individual optic modules or at the linecard level.

There's a reason they're called Crashport 8600s.
--
MNSi Internet - »www.mnsi.net

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

said by HeadSpinning:

There's a reason they're called Crashport 8600s.

Does this monicker also apply to current software for the renamed Avaya ERS 8600 ?

Does Bell upgrade its Nortel Passports with Ayava's new releases or are those switches frozen in time ?

singerie3

join:2008-10-12
Saint-Constant, QC

said by jfmezei:

said by HeadSpinning:

There's a reason they're called Crashport 8600s.

Does this monicker also apply to current software for the renamed Avaya ERS 8600 ?

Does Bell upgrade its Nortel Passports with Ayava's new releases or are those switches frozen in time ?

unfortunately i don't have access to those box, but from what i see in internal email, they are upgraded with avaya code.

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

Lets say an ISP has 4 1gbps links on EAS which terminate on an 8600.

Does this mean that there would be 4 1gbps wires going from the switch to the AHSSPI router using 4 ports ?

Or would Bell have a 40gbps uplink from the Passport to the AHSSPI router and then use software to separate and rate limit each ISP's 1gps link ?


InvalidError

join:2008-02-03
kudos:5

said by jfmezei:

Or would Bell have a 40gbps uplink from the Passport to the AHSSPI router and then use software to separate and rate limit each ISP's 1gps link ?

Why software? All managed switches and routers have options to limit ingress/egress rates on a per-port or per-LAG basis, the rest is simple IP routing between the BRAS and ISP's LNSes/Junipers/whatever.