re: AlcaLu's Alwan: PBT Will Lose Its ShineHi Mark, The original comment was that MPLS label semantics vary, which is true if you exclude any context.
(By the way - this isn't my subject wording - I actually do think MPLS is bloated - but at the Control Plane when it comes to using it as a Transport technology)
For example, let's say you are operating a converged MPLS backbone in which there are both Layer 2 and Layer 3 MPLS VPNs.
If you go to one of the core LSRs and pluck an individual frame from the wire, then you cannot tell from looking at the label what that frame is supposed to be. You don't have any context in which to make that decision.
In the context of an LSR the meaning of the outermost label tells the LSR where to forward the frame, and (if configured) what priority or queuing behaviour to apply. But within that context the meaning of the MPLS label does not vary.
In the context of an Egress LSR (or Label Edge Router) the label has much more meaning - allowing the Egress LSR to figure out VPN membership, label stripping etc. Within that context the meaning of the label does not vary either - but it is locally administered. In other words the "owner" of those LERs decides the VPN label allocation, and if any mapping of those labels takes place.
I don't think I said that IP addresses or Ethernet MAC addresses are context-dependent did I? If I did I goofed :-)
Of course there's the option of using locally administered Ethernet MAC addresses - which has been in IEEE defined 48 bit addressing forever. I'm not sure that's relevant in this discussion though is it?
What I did mean is that MPLS VLAN IDs are locally administered, in the same way that LERs can do with MPLS VPN IDs. "Local" means that a carrier can create multiple VPN layers if they want (this has an obvious application in "carriers' carrier" environments). So the same VLAN ID could potentially be re-used in the context of the MPLS core LSRs (because it would be hidden from them by another layer of labels).
This might sound complex - and I can imagine some folks thinking "phew - that's why I want to go with PBT and keep it simple". But the point is that any specific network administrator in this architecture only sees the amount of complexity that they need to. The carriers' carrier only sees the outmost MPLS labels they need to keep customer traffic separated. Their customers only see the inner label structure they need to perform the application (eg. L2 VPN, L3 VPN) that they are offering.
In fact there's no difference in the basic idea of an MPLS core that hides an MPLS application label structure, and an MPLS core that hides a PBT label structure.
But by retaining MPLS label formats throughout it's more consistent, and I think MPLS label stacking is more flexible.
re: AlcaLu's Alwan: PBT Will Lose Its ShineGeoff, et al
There are some very good points brought out in this thread. The real question is can a packet/application approach (MPLS) to solving what is a flow/transport problem be effective over a long life cycle without major restructuring. Is it better to start with a baseline that came from the problem statement vs. pounding the square peg into a round hole.
As usual almost any technology can be force fit into a new solution. I just believe that MPLSs early focus and heritage will make it difficult to manage dydnamic flows across what will hopefully be in the future very flexible optical pipes at a sub-wavelegth level of granularity. Managing connection oriented flows across optical paths for unpredictable service traffic patterns will be very difficult and I believe will require a new control plane paradigm which can cover layer 0 to layer 2 as a single entity. I just do not see MPLS providing that baseline.
>> If you go to one of the core LSRs and pluck an individual frame from the wire, then you cannot tell from looking at the label what that frame is supposed to be. You don't have any context in which to make that decision. <<
Exactly, and yet this is the proxy information for a DA (a PT2MP network), or a SA/DA combo (a PT2PT circuit), or whatever it is being used for. With an Ethernet address you *don't* have to know any context, it always is an Ethernet address. This the difference the previous poster was trying to draw attention to when speaking of one approach being variable (I personally prefer "semantically overloaded" - but that is just a personal preference) and another not being so. BTW, both approaches have some semantics which are not overloaded (normally) - so the issue is some semantics, not all semantics. The compelling comparison point is the difference between a DA/SA pair and a label. This is where the compelling discussion about the differences in approaches is occurring (at a protocol design level anyway as opposed to discussions about overall architecture etc, business benefits, etc...)
This is in my opinion a positive statement (a statement of what is) that stands on its own regardless of whether people want to make normative statements (a statement of what should be) about it.
So if you want to assert all kinds of goodness about MPLS with respect to this issue, stacking, or whatever...have at it. But that is my positive 2 cents on the issue of "variable" semantics - which was one of the rationales for the adoption of MPLS and one of the assertions for why it was different than other approaches (an assertion of difference which I believe is objectively true).
re: AlcaLu's Alwan: PBT Will Lose Its ShineHi delphi,
I had to smile at your analogy, "Is it better to start with a baseline that came from the problem statement vs. pounding the square peg into a round hole."
I wouldn't personally describe adapting MPLS to become a transport technology in that way. More like MPLS as a piece of clay. You pull off a lump, mould it one way and it becomes an "IP helper". you pull off another lump and it becomes a "Layer 2 helper".
The Layer 2 lump should be smaller, cheaper and easier to mould than the Layer 3 lump.
re: AlcaLu's Alwan: PBT Will Lose Its ShineHi Mark, I see what you're saying about the "Ethernet address is always an Ethernet address", but I'm trying to imagine a situation where it would be advantageous.
Since Ethernet addresses have no structure (beyond the OUI) surely they're as abstract as a label?
In fact they're not even guaranteed to be unique because they could be locally administered, just like a label.
They could also be deliberately duplicated if there was a reason to do that. Most like a DoS situation I suspect.
re: AlcaLu's Alwan: PBT Will Lose Its ShineGeoff: (By the way - this isn't my subject wording - I actually do think MPLS is bloated - but at the Control Plane when it comes to using it as a Transport technology)
How do you measure the bloatedness of a protocol? Is it because it has too many features? Knobs? Applications? Would you provide examples of other protocols you think are bloated: BGP, OSPF, ISIS, PIM, SNA, ATM, etc. so I can get a baseline of your measure?
And finally, one man's bloat is another man's feature. What part of MPLS do you think is extravagance?
-desi
PS. I think bloat is when a protocol can do all these fancy things and you don't need them. It isn't simply that the protocol can do all these fancy features because you may want/need them.
re: AlcaLu's Alwan: PBT Will Lose Its ShineHi desiEngineer, Excellent point!
I'll try and give you a working definition or two, and remind you that all of this is just my humble opinion - make of it what you will.
A protocol, or set of protocols that make up...well what ever the collective noun for protocols is...becomes too bloated when the people who have to administer the system find that as the number of users on that system increases, the time required to administer the system increase at more than a linear rate.
To paraphrase WC Fields: "Twice as many users, 1.5 times the OpEx - result happiness. Twice as many users, 2.5 times the OpEx - result misery."
Can I provide examples of bloated protocols?
OSPF has certainly grown a few "love handles", but I think it's still pretty lean for the functionality it brings. PNNI was a heck of a lot better, but only because of the flexibility of the ATM Private Address structure. It's funny because people used to look at 20-byte ATM addresses in horror! Wouldn't they be wonderful in today's Internet?
Let's see. BGP is, without doubt, bloated. Not so much the original protocol, but the reams of hacks that have been bolted on to allow IPv4 to be managed at a carrier scale. Don't get me wrong - I think BGP is actually a testament to human ingenuity and dogged perseverance. It's a miracle it works, but somehow it does. I am in awe of people who have to manage BGP networks on a daily basis. (By the way there are no smileys at the end of that sentence. I am genuinely not being sarcastic).
ATM LAN Emulation was a porker too. To emulate something as beautifully simple as Ethernet, ATM had to go through astonishing contortions. I remember giving presentations about how LANE worked and secretly being amazed that it was as reliable as it was. But of course it had to be that bloated to work at all. So does it really count? Not sure.
It's not for me to say what should be trimmed or even removed from MPLS to make it become a cost-effective transport technology. Frankly I think it works as one today. Maybe it's just the profit margins of the manufacturers that need to go on a diet.
"So in that respect both MPLS and PBT have context-dependent label semantics"
In what context is an Ethernet or IP address not an Ethernet or IP address?
The original comment was that MPLS label semantics vary, which is true if you exclude any context.
(By the way - this isn't my subject wording - I actually do think MPLS is bloated - but at the Control Plane when it comes to using it as a Transport technology)
For example, let's say you are operating a converged MPLS backbone in which there are both Layer 2 and Layer 3 MPLS VPNs.
If you go to one of the core LSRs and pluck an individual frame from the wire, then you cannot tell from looking at the label what that frame is supposed to be. You don't have any context in which to make that decision.
In the context of an LSR the meaning of the outermost label tells the LSR where to forward the frame, and (if configured) what priority or queuing behaviour to apply. But within that context the meaning of the MPLS label does not vary.
In the context of an Egress LSR (or Label Edge Router) the label has much more meaning - allowing the Egress LSR to figure out VPN membership, label stripping etc. Within that context the meaning of the label does not vary either - but it is locally administered. In other words the "owner" of those LERs decides the VPN label allocation, and if any mapping of those labels takes place.
I don't think I said that IP addresses or Ethernet MAC addresses are context-dependent did I? If I did I goofed :-)
Of course there's the option of using locally administered Ethernet MAC addresses - which has been in IEEE defined 48 bit addressing forever. I'm not sure that's relevant in this discussion though is it?
What I did mean is that MPLS VLAN IDs are locally administered, in the same way that LERs can do with MPLS VPN IDs. "Local" means that a carrier can create multiple VPN layers if they want (this has an obvious application in "carriers' carrier" environments). So the same VLAN ID could potentially be re-used in the context of the MPLS core LSRs (because it would be hidden from them by another layer of labels).
This might sound complex - and I can imagine some folks thinking "phew - that's why I want to go with PBT and keep it simple". But the point is that any specific network administrator in this architecture only sees the amount of complexity that they need to. The carriers' carrier only sees the outmost MPLS labels they need to keep customer traffic separated. Their customers only see the inner label structure they need to perform the application (eg. L2 VPN, L3 VPN) that they are offering.
In fact there's no difference in the basic idea of an MPLS core that hides an MPLS application label structure, and an MPLS core that hides a PBT label structure.
But by retaining MPLS label formats throughout it's more consistent, and I think MPLS label stacking is more flexible.
Again, just my 2 cents.
Cheers,
Geoff
There are some very good points brought out in this thread. The real question is can a packet/application approach (MPLS) to solving what is a flow/transport problem be effective over a long life cycle without major restructuring. Is it better to start with a baseline that came from the problem statement vs. pounding the square peg into a round hole.
As usual almost any technology can be force fit into a new solution. I just believe that MPLSs early focus and heritage will make it difficult to manage dydnamic flows across what will hopefully be in the future very flexible optical pipes at a sub-wavelegth level of granularity. Managing connection oriented flows across optical paths for unpredictable service traffic patterns will be very difficult and I believe will require a new control plane paradigm which can cover layer 0 to layer 2 as a single entity. I just do not see MPLS providing that baseline.
should have been MP2PT network.
>> If you go to one of the core LSRs and pluck an individual frame from the wire, then you cannot tell from looking at the label what that frame is supposed to be. You don't have any context in which to make that decision. <<
Exactly, and yet this is the proxy information for a DA (a PT2MP network), or a SA/DA combo (a PT2PT circuit), or whatever it is being used for. With an Ethernet address you *don't* have to know any context, it always is an Ethernet address. This the difference the previous poster was trying to draw attention to when speaking of one approach being variable (I personally prefer "semantically overloaded" - but that is just a personal preference) and another not being so. BTW, both approaches have some semantics which are not overloaded (normally) - so the issue is some semantics, not all semantics. The compelling comparison point is the difference between a DA/SA pair and a label. This is where the compelling discussion about the differences in approaches is occurring (at a protocol design level anyway as opposed to discussions about overall architecture etc, business benefits, etc...)
This is in my opinion a positive statement (a statement of what is) that stands on its own regardless of whether people want to make normative statements (a statement of what should be) about it.
So if you want to assert all kinds of goodness about MPLS with respect to this issue, stacking, or whatever...have at it. But that is my positive 2 cents on the issue of "variable" semantics - which was one of the rationales for the adoption of MPLS and one of the assertions for why it was different than other approaches (an assertion of difference which I believe is objectively true).
I had to smile at your analogy, "Is it better to start with a baseline that came from the problem statement vs. pounding the square peg into a round hole."
I wouldn't personally describe adapting MPLS to become a transport technology in that way. More like MPLS as a piece of clay. You pull off a lump, mould it one way and it becomes an "IP helper". you pull off another lump and it becomes a "Layer 2 helper".
The Layer 2 lump should be smaller, cheaper and easier to mould than the Layer 3 lump.
Cheers,
Geoff
I see what you're saying about the "Ethernet address is always an Ethernet address", but I'm trying to imagine a situation where it would be advantageous.
Since Ethernet addresses have no structure (beyond the OUI) surely they're as abstract as a label?
In fact they're not even guaranteed to be unique because they could be locally administered, just like a label.
They could also be deliberately duplicated if there was a reason to do that. Most like a DoS situation I suspect.
Cheers,
Geoff
How do you measure the bloatedness of a protocol? Is it because it has too many features? Knobs? Applications? Would you provide examples of other protocols you think are bloated: BGP, OSPF, ISIS, PIM, SNA, ATM, etc. so I can get a baseline of your measure?
And finally, one man's bloat is another man's feature. What part of MPLS do you think is extravagance?
-desi
PS. I think bloat is when a protocol can do all these fancy things and you don't need them. It isn't simply that the protocol can do all these fancy features because you may want/need them.
Excellent point!
I'll try and give you a working definition or two, and remind you that all of this is just my humble opinion - make of it what you will.
A protocol, or set of protocols that make up...well what ever the collective noun for protocols is...becomes too bloated when the people who have to administer the system find that as the number of users on that system increases, the time required to administer the system increase at more than a linear rate.
To paraphrase WC Fields: "Twice as many users, 1.5 times the OpEx - result happiness. Twice as many users, 2.5 times the OpEx - result misery."
Can I provide examples of bloated protocols?
OSPF has certainly grown a few "love handles", but I think it's still pretty lean for the functionality it brings. PNNI was a heck of a lot better, but only because of the flexibility of the ATM Private Address structure. It's funny because people used to look at 20-byte ATM addresses in horror! Wouldn't they be wonderful in today's Internet?
Let's see. BGP is, without doubt, bloated. Not so much the original protocol, but the reams of hacks that have been bolted on to allow IPv4 to be managed at a carrier scale. Don't get me wrong - I think BGP is actually a testament to human ingenuity and dogged perseverance. It's a miracle it works, but somehow it does. I am in awe of people who have to manage BGP networks on a daily basis. (By the way there are no smileys at the end of that sentence. I am genuinely not being sarcastic).
ATM LAN Emulation was a porker too. To emulate something as beautifully simple as Ethernet, ATM had to go through astonishing contortions. I remember giving presentations about how LANE worked and secretly being amazed that it was as reliable as it was. But of course it had to be that bloated to work at all. So does it really count? Not sure.
It's not for me to say what should be trimmed or even removed from MPLS to make it become a cost-effective transport technology. Frankly I think it works as one today. Maybe it's just the profit margins of the manufacturers that need to go on a diet.
Cheers,
Geoff