re: Resilient Packet Ring TechnologyI guess standardization is nowadays hindering efficient development and premises, somehow, I once thought proprietary was much of "too many for the same" but it is rather offering alternatives which is always welcomed by the many not so powerful but yet productive of good ideas
re: Resilient Packet Ring Technology Cisco has caused extreme harm to the usefulness of this standard, and has subverted the IEEE standardization process. One of the requirements of 802.17 is that it provide for IEEE 802.1D bridging, that is, it needs to be able to act as a switch. The draft standard is at this time flawed because bridging is accomplished by having the frames travel all the way around the ring- no spatial re-use when used as a bridge! Since Spatial Reuse is part of the basic premise behind the standard, I would contend that bridging has not been met. I can't say so, though, since Takefman (Cisco), the chair of the group, has restricted access to the email reflector where all discussions take place. The Cisco/ Nortel/ Luminous camp is only concerened with routing, not switching, so they have pushed for layer-3 capabilities only from the very beginning. So, congratulations, on designing a brand new, big, fat, slow router!
How can all this happen in the IEEE? Well, I guess they lost in trying to fight big corporate influences. All future standards from that group will only benefit the few and the powerful from now on, I guess.
re: Resilient Packet Ring TechnologyAlthough, 802 is generally known as the LAN/MAN/WAN standards it has an over zealous toll booth attendant, supported by a local mafia of Ethernet switch vendors, known as 802.1. It is ridiculous to force all future 802 standard to conform to spanning tree based bridging rules. WAN and MANs are not dimunitive networks like LANs to consider bridging (a.k.a layer 2 routing with a flat address space)as a viable solution.
IEEE 802 needs a wake up call. Perhaps, the 802.17 working group has done it a favor by spending less efforts on a dying protocol like spanning tree algorithm based layer 2 routing - also sold as 802.1D bridging. If the 802.17 ends up spending time on this it would have further exposed how broken and sad this protocol is and how IEEE is very disallusioned IEEE in mandating all furture networks to conform to this. For IEEE the main focus should be to gain a beach head in carrier networks. Since, most carriers consider ITU to be the defacto standard body. IEEE will win the local mafia war and loose the over fight to perpetuate itself as a standards body.
I think your note might confuse readers on what the 802.17 decided to keep and what it decided not to undertake to speed up the availability of the standard. As a working group member, I think it is my duty to clarify.
The working group is always reminded and understands well that conformance (paying dues to the local 802 union) to 802.1 is required. There is a general distaste of bridging to many RPR vendors who have leveraged MPLS and a IP control plane to accomplish this. Never the less, the 802.17 working group bit the bullet and decided to show how the protocol they are designing supports all the flooding rules and learning rules required by 802.1 bridging. However, a few over-zealous and lost-at-sea vendors wanted to further optimize 802.17 to ensure 802.17 would be very optimal for bridged networks. So, a poll was taken of the 5 major system vendors whether this complication in the standard was worth it. Cisco, Nortel, Luminous and Corrigent declared that they never plan to shackle their customers by bridging between RPR rings or between RPR and Ethernet. Lantern was the only one who wanted despite having no such product plans. The reality was that Lantern having been trounced soundly in the RPR standards was attempting to use this as a Trojan horse to get back their ATMish "flowid" field in the header - which was one of the outcome if 802.17 workking group were to optimize RPR for 802.1 bridging. So, with 4 out 5 seeking not to pursue this and having reviewed our orginal project proposal the group deemed that such optimization was a wate of the 802.17 working group's time and they gave full permission for such bridging zealots to go persue such elaborate optimization with the 802.1 bridging working group. After al, it is wiser to keep the monkeys busy at something :)
I think this was fair and keeps with current tide in the industry. Your implication of unfairness sounds like sour grapes to me !
Just so that the readers get a full story... Now, there were others like Cypress and C-Cor who have no skin in this game and who have individuals at these meetings who are mainly there to agrandize themselves. These inidviduals made pursuit of optimizing 802.17 for 802.1 a very challenging research and also fell a prey to ever needy Lantern guys on the sidelines.
Sorry chaps. Bridging had its days. Now, its existence has become a pain in the neck. In fact, to resolve some of the obscene inadequacies of 802.1 bridging VLAN was invented. Now, that has become inadequate and stacked-VLANs are being proposed. And there is more...
IMHO, optimizing for bridging will create more problems.
re: Resilient Packet Ring TechnologyHi Lantern competitor (it's obvious who wrote it, even the person's name is easy to guess):
You should focus your time/energy on business rather than go after your competition this way.
It should not be forgotten that you didn't like anything about Cisco proposal for just about anything until just a few months ago. So what changed? Desperation, maybe? Or is it that suddenly your bridging concepts became ultra-clear when the business became tough? Pretty funny.
It's true IEEE spanning tree is old and hardly worth the compatibility pursuit. But 802.17 isn't doing IEEE any favor either. It's bringing an ancient and old proprietary protocol of one particular company to IEEE for stamping of approval and now the 802.17 folks wonder why not all members just sign on the dotted line. For a lot of people in 802.17, winning people by politics is same as improving the protocol. It's high time the blind followers try to fix stuff rather than rush it to make it a standard.
re: Resilient Packet Ring Technologydata_guy: With all due respect, are you attending these meeting and discussions? I think you are WAY off base. RPR is nearing finality and is rolling along quite well. I've even heard thru some carriers that many of the "Next Gen" SONET guys are looking at implementing RPR as a data plane.
If you want 802.1D bridging, buy an ethernet switch. If you want packet transport, use RPR.
re: Resilient Packet Ring TechnologyApologize for any confusions - my previous message was for fundamental_guy for the message where he criticized Lantern and others about their opinions.
re: Resilient Packet Ring TechnologyRPR Semiconductor Inc, (www.rprsemi.com) is another RPR silicon vendor which is not to be ignored, having a range of silicon solutions for the emerging RPR Technology.
re: Resilient Packet Ring TechnologyWho else makes RPR silicon? Can someone give me a list? I'm trying to see whether there are enough players to make it worthwhile doing a survey.
re: Resilient Packet Ring TechnologySome questions:
1. How big a difference is there between Cisco's proprietary SRP and the upcoming RPR standard?
2. Isn't there a real likelihood that Cisco will continue selling SRP in the same way that it continued selling its proprietary routing protocols - ie "Here you go, Mr. Customer, this box supports SRP and RPR so you can make your own mind up which you want to use. You might like to know, however, that SRP is widely deployed so it's proven technology. We're still ironing some kinks out of our RPR implementation."
re: Resilient Packet Ring TechnologyStatements like: "ItGÇÖs not easy to summarize 802.17 concisely, because in some respects it is like a framework on which vendors will add a wide variety of bits to build more complete metro systems" strike a good deal of fear in me.
Does anyone know to what degree 802.17 compliance will be tested so that we can imagine deploying multi-vendor rings (with full layer 1, 2 and 3 interop) or this is really only a "framework standard" that like vendors sell box and leave the problems to the operators?
Please no PR type answers - I am looking for interop specs and event dates.
Cisco has caused extreme harm to the usefulness of this standard, and has subverted the IEEE standardization process.
One of the requirements of 802.17 is that it provide for IEEE 802.1D bridging, that is, it needs to be able to act as a switch. The draft standard is at this time flawed because bridging is accomplished by having the frames travel all the way around the ring- no spatial re-use when used as a bridge! Since Spatial Reuse is part of the basic premise behind the standard, I would contend that bridging has not been met. I can't say so, though, since Takefman (Cisco), the chair of the group, has restricted access to the email reflector where all discussions take place.
The Cisco/ Nortel/ Luminous camp is only concerened with routing, not switching, so they have pushed for layer-3 capabilities only from the very beginning. So, congratulations, on designing a brand new, big, fat, slow router!
How can all this happen in the IEEE? Well, I guess they lost in trying to fight big corporate influences. All future standards from that group will only benefit the few and the powerful from now on, I guess.
LAN/MAN/WAN standards it has an over zealous toll
booth attendant, supported by a local mafia of
Ethernet switch vendors, known as 802.1. It is
ridiculous to force all future 802 standard
to conform to spanning tree based bridging
rules. WAN and MANs are not dimunitive networks
like LANs to consider bridging (a.k.a layer
2 routing with a flat address space)as a viable
solution.
IEEE 802 needs a wake up call. Perhaps, the 802.17
working group has done it a favor by spending
less efforts on a dying protocol like spanning
tree algorithm based layer 2 routing - also
sold as 802.1D bridging. If the 802.17 ends up
spending time on this it would have further
exposed how broken and sad this protocol is and
how IEEE is very disallusioned IEEE in mandating
all furture networks to conform to this. For IEEE
the main focus should be to gain a
beach head in carrier networks. Since, most
carriers consider ITU to be the defacto standard
body. IEEE will win the local mafia war and
loose the over fight to perpetuate itself
as a standards body.
I think your note might confuse readers on
what the 802.17 decided to keep and what it
decided not to undertake to speed up the
availability of the standard. As a working
group member, I think it is my duty to clarify.
The working group is always reminded and
understands well that conformance (paying dues
to the local 802 union) to 802.1 is required.
There is a general distaste of bridging to many
RPR vendors who have leveraged MPLS and a IP
control plane to accomplish this.
Never the less, the 802.17 working group bit the
bullet and decided to show how the protocol they
are designing supports all the flooding rules
and learning rules required by 802.1 bridging.
However, a few over-zealous and lost-at-sea
vendors wanted to further optimize 802.17 to
ensure 802.17 would be very optimal for
bridged networks.
So, a poll was taken of the 5 major system vendors
whether this complication in the standard was
worth it. Cisco, Nortel, Luminous and Corrigent
declared that they never plan to shackle their
customers by bridging between RPR rings or
between RPR and Ethernet. Lantern was the only
one who wanted despite having no such product
plans. The reality was that Lantern having been
trounced soundly in the RPR standards was
attempting to use this as a Trojan horse to
get back their ATMish "flowid" field in the
header - which was one of the outcome if
802.17 workking group were to optimize RPR for
802.1 bridging. So, with 4 out 5 seeking not
to pursue this and having reviewed our orginal
project proposal the group deemed that such
optimization was a wate of the 802.17 working
group's time and they gave full permission for
such bridging zealots to go persue such
elaborate optimization with the 802.1 bridging
working group. After al, it is wiser to keep
the monkeys busy at something :)
I think this was fair and keeps
with current tide in the industry. Your
implication of unfairness sounds like sour
grapes to me !
Just so that the readers get a full story...
Now, there were others like Cypress and C-Cor
who have no skin in this game and who have
individuals at these meetings who are mainly
there to agrandize themselves. These inidviduals
made pursuit of optimizing 802.17 for 802.1
a very challenging research and also fell a prey
to ever needy Lantern guys on the sidelines.
Sorry chaps. Bridging had its days. Now, its
existence has become a pain in the neck.
In fact, to resolve some of the obscene
inadequacies of 802.1 bridging VLAN was invented.
Now, that has become inadequate and stacked-VLANs
are being proposed. And there is more...
IMHO, optimizing for bridging will create more problems.
You should focus your time/energy on business rather than go after your competition this way.
It should not be forgotten that you didn't like anything about Cisco proposal for just about anything until just a few months ago. So what changed? Desperation, maybe? Or is it that suddenly your bridging concepts became ultra-clear when the business became tough? Pretty funny.
It's true IEEE spanning tree is old and hardly worth the compatibility pursuit. But 802.17 isn't doing IEEE any favor either. It's bringing an ancient and old proprietary protocol of one particular company to IEEE for stamping of approval and now the 802.17 folks wonder why not all members just sign on the dotted line. For a lot of people in 802.17, winning people by politics is same as improving the protocol. It's high time the blind followers try to fix stuff rather than rush it to make it a standard.
With all due respect, are you attending these meeting and discussions? I think you are WAY off base.
RPR is nearing finality and is rolling along quite well. I've even heard thru some carriers that many of the "Next Gen" SONET guys are looking at implementing RPR as a data plane.
If you want 802.1D bridging, buy an ethernet switch. If you want packet transport, use RPR.
Your thoughts?
FiberFan
[email protected]
1. How big a difference is there between Cisco's proprietary SRP and the upcoming RPR standard?
2. Isn't there a real likelihood that Cisco will continue selling SRP in the same way that it continued selling its proprietary routing protocols - ie "Here you go, Mr. Customer, this box supports SRP and RPR so you can make your own mind up which you want to use. You might like to know, however, that SRP is widely deployed so it's proven technology. We're still ironing some kinks out of our RPR implementation."
Does anyone know to what degree 802.17 compliance will be tested so that we can imagine deploying multi-vendor rings (with full layer 1, 2 and 3 interop) or this is really only a "framework standard" that like vendors sell box and leave the problems to the operators?
Please no PR type answers - I am looking for interop specs and event dates.