Your blog here is so good made me think a bit so here's more. 1. The True LIEs acronyms are fully intended, it's actually quite deeply rooted in psychology/brain physiology and how people learn that led me to choose acronyms that way ;-) 2. SR & RIFT: yes, SR is a great technology to start in the leaf as overlay as e.g. SRoUDP and terminate on DCI, we see lots of that. RIFT will not preclude SR in the fabric but frankly, I have to see a use case for SR in IP fabric underlay I believe in (footnote: it's overkill for error triangulation e.g.). 3. yes, I paid lots attention to the gripes of people actually cabling fabrics, lots interesting things like "I just want to know WHO as in switch/port is on the other side" led to lots stuff you find in the protocol design. 4. Automation/Intent is _great_ and super valuable when we talk about "service monitoring & provisioning". IGP is just standard pipes, e'one standardizes on laying them same way by now (that's your other argument, we see lots of CLOS now in access/sattelite access/core form factors, you name it". The reason is that CLOS is imply the most effective way to interconnect crossbars, we know that since 50s and the math is very hard to argue with. So, use controller to provision service which is unique to every network (since that's the produce you sell while fabric is just "ram chips") but using controller to provision your IGP while you have no IGP is kind of interesting but really unnecessary exercise AFAIS. 5. RIFT is AFAIS the simplest solution to pull servers into underlay with minimal resource consumption and once you multi-home them L3 all the service migration and other headaches go away. True multi-home L3 is not just "download the default route", it needs proper dealing with failures upstream or "on the other side" as well so simple static 0/0 is good neough if you think "blackholing is ok, we have pagers for that" only. And yes, you can always find a more complex way to solve the same problem ;-) 6. I don't follow your argument really how RIFT design impacts BGP, it's just another way to get your IGP next-hop really but that would be an interesting discussion.
Would be interesting to pull Russ and Jeff into the BGP discussion. The language in the day one book on how modifying BGP for autonomic capabilities feels a little like Russ, and I suspect Jeff endorses. I personally feel there are many good and natural reasons why BGP is used for so many things ( https://internetdynamics.substack.com/p/no-accident-bgp-is-used-for-vpns ), however, I do feel the argument made in the RIFT book about what it would take to completely rip out an IGP, only use BGP, and still have autonomic behavior was interesting.
The discussion around SR, E2E networking, and service chaining is probably more complicated than can really be handled on a blog response, unless someone can cut to the chase and really simplify it.
Consider that many of us have been digested the messaging around SR as a technology to a) reduce the state at the core, and b) provide explicit, traffic engineered routing from A to B. Which of these goals is achieved by using SR over UDP? Many of us inherently think of SR as the next generation underlay technology that replaces IP/MPLS either as SR MPLS or SRv6. Do people put underlay protocols in tunnels to get around sections of the network that do not use those protocols? Sure. But what is the compelling value proposition of SR in networking today, and in the future? I would be interested to hear what Ron’s perspective is.
Then to complicate things a little, there is a growing buzz in the SR world around using SR as a service chaining technology, where segments connect VRFs. In this use case, SR is not a leaf-sourced technology, but a server/vNF sourced/sinked technology. What is going to be the most prominent approach to doing this in the future? I would assume Contrail is not using SR for this purpose today, and again, I am not 100% sure SR is the best or worst way to do this, and am very curious to see how this plays out. You know how we are as an industry. Once you decide something is your favorite hammer, everything looks like a nail. OTOH, I can’t think of any reason why SR is a terrible choice for this use case, it might even be a good choice. Something I would definitely like to see more discussion on outside of SR cohorts.
But the net-net for me is the following: if the value proposition of a technology is source-routed, explicit routing, isn’t that value undermined a little if the underlay is obfuscated from it? Not a black and white question. There are many different “networks” in a network. VoIP has traditionally created its own network of voice nodes overlaid on an IP infrastructure. Does not make it any less of a network. IP itself is an overlay on a physical infrastructure. So, it is really a question of what the right tool for the job is, and why. Should SR go all the way to the server, should it be source/sinked on leaf, should it be a WAN technology only? These are the questions that come to mind. My comment really was does RIFT suggest that we don’t need a source-routed, explicitly routed, technology from server to server. In a fabric with oodles of bandwidth, perhaps not. So it is these fundamental questions of are we dealing with domains that have an abundance of bandwidth and paths and all we need is ECMP? Are we dealing with domains where per-hop-state is not a concern? Etc. Maybe there is some context missing from the RIFT discussion, what are the underlying assumptions?
I’d love to hear Jeff’s view on where Automation/intent adds the most value, the underly or the overlay. If it is true, that what you are implying, is that the underlay should and can be automated by approaches like RIFT, leaving the overlays/service layers to be automated by intent-systems, then just having clarity on that assertion would be a useful industry understanding / principle. While authors argued that RIFT as general applicability, most people today probably see it has having specific applicability, leaving many underlays still needing automation.
As for LIEs, damn LIEs, and valid LIEs, I really hope that technologists do not make decisions based on acronyms, but people can be fairly petty sometimes. I used to work with a marketing guy whose first instinct was always to ponder how a term might be used by competitors to mock us. I really hope this does not happen in the case of LIEs, and I probably should have left it alone, but sometimes I can’t restrain myself from going for the low-hanging humor. Australians, god love us.
Anyway, lot to chew on, and overall, I am very enthusiastic about the RIFT work, wish it well, and will be watching it with interest. The high-order bit for me is that network self-automation is a good thing, and I am curious to see how this evolves.
Your blog here is so good made me think a bit so here's more. 1. The True LIEs acronyms are fully intended, it's actually quite deeply rooted in psychology/brain physiology and how people learn that led me to choose acronyms that way ;-) 2. SR & RIFT: yes, SR is a great technology to start in the leaf as overlay as e.g. SRoUDP and terminate on DCI, we see lots of that. RIFT will not preclude SR in the fabric but frankly, I have to see a use case for SR in IP fabric underlay I believe in (footnote: it's overkill for error triangulation e.g.). 3. yes, I paid lots attention to the gripes of people actually cabling fabrics, lots interesting things like "I just want to know WHO as in switch/port is on the other side" led to lots stuff you find in the protocol design. 4. Automation/Intent is _great_ and super valuable when we talk about "service monitoring & provisioning". IGP is just standard pipes, e'one standardizes on laying them same way by now (that's your other argument, we see lots of CLOS now in access/sattelite access/core form factors, you name it". The reason is that CLOS is imply the most effective way to interconnect crossbars, we know that since 50s and the math is very hard to argue with. So, use controller to provision service which is unique to every network (since that's the produce you sell while fabric is just "ram chips") but using controller to provision your IGP while you have no IGP is kind of interesting but really unnecessary exercise AFAIS. 5. RIFT is AFAIS the simplest solution to pull servers into underlay with minimal resource consumption and once you multi-home them L3 all the service migration and other headaches go away. True multi-home L3 is not just "download the default route", it needs proper dealing with failures upstream or "on the other side" as well so simple static 0/0 is good neough if you think "blackholing is ok, we have pagers for that" only. And yes, you can always find a more complex way to solve the same problem ;-) 6. I don't follow your argument really how RIFT design impacts BGP, it's just another way to get your IGP next-hop really but that would be an interesting discussion.
Thanks for your comments Tony!
Would be interesting to pull Russ and Jeff into the BGP discussion. The language in the day one book on how modifying BGP for autonomic capabilities feels a little like Russ, and I suspect Jeff endorses. I personally feel there are many good and natural reasons why BGP is used for so many things ( https://internetdynamics.substack.com/p/no-accident-bgp-is-used-for-vpns ), however, I do feel the argument made in the RIFT book about what it would take to completely rip out an IGP, only use BGP, and still have autonomic behavior was interesting.
The discussion around SR, E2E networking, and service chaining is probably more complicated than can really be handled on a blog response, unless someone can cut to the chase and really simplify it.
Consider that many of us have been digested the messaging around SR as a technology to a) reduce the state at the core, and b) provide explicit, traffic engineered routing from A to B. Which of these goals is achieved by using SR over UDP? Many of us inherently think of SR as the next generation underlay technology that replaces IP/MPLS either as SR MPLS or SRv6. Do people put underlay protocols in tunnels to get around sections of the network that do not use those protocols? Sure. But what is the compelling value proposition of SR in networking today, and in the future? I would be interested to hear what Ron’s perspective is.
Then to complicate things a little, there is a growing buzz in the SR world around using SR as a service chaining technology, where segments connect VRFs. In this use case, SR is not a leaf-sourced technology, but a server/vNF sourced/sinked technology. What is going to be the most prominent approach to doing this in the future? I would assume Contrail is not using SR for this purpose today, and again, I am not 100% sure SR is the best or worst way to do this, and am very curious to see how this plays out. You know how we are as an industry. Once you decide something is your favorite hammer, everything looks like a nail. OTOH, I can’t think of any reason why SR is a terrible choice for this use case, it might even be a good choice. Something I would definitely like to see more discussion on outside of SR cohorts.
But the net-net for me is the following: if the value proposition of a technology is source-routed, explicit routing, isn’t that value undermined a little if the underlay is obfuscated from it? Not a black and white question. There are many different “networks” in a network. VoIP has traditionally created its own network of voice nodes overlaid on an IP infrastructure. Does not make it any less of a network. IP itself is an overlay on a physical infrastructure. So, it is really a question of what the right tool for the job is, and why. Should SR go all the way to the server, should it be source/sinked on leaf, should it be a WAN technology only? These are the questions that come to mind. My comment really was does RIFT suggest that we don’t need a source-routed, explicitly routed, technology from server to server. In a fabric with oodles of bandwidth, perhaps not. So it is these fundamental questions of are we dealing with domains that have an abundance of bandwidth and paths and all we need is ECMP? Are we dealing with domains where per-hop-state is not a concern? Etc. Maybe there is some context missing from the RIFT discussion, what are the underlying assumptions?
I’d love to hear Jeff’s view on where Automation/intent adds the most value, the underly or the overlay. If it is true, that what you are implying, is that the underlay should and can be automated by approaches like RIFT, leaving the overlays/service layers to be automated by intent-systems, then just having clarity on that assertion would be a useful industry understanding / principle. While authors argued that RIFT as general applicability, most people today probably see it has having specific applicability, leaving many underlays still needing automation.
As for LIEs, damn LIEs, and valid LIEs, I really hope that technologists do not make decisions based on acronyms, but people can be fairly petty sometimes. I used to work with a marketing guy whose first instinct was always to ponder how a term might be used by competitors to mock us. I really hope this does not happen in the case of LIEs, and I probably should have left it alone, but sometimes I can’t restrain myself from going for the low-hanging humor. Australians, god love us.
Anyway, lot to chew on, and overall, I am very enthusiastic about the RIFT work, wish it well, and will be watching it with interest. The high-order bit for me is that network self-automation is a good thing, and I am curious to see how this evolves.