An attempt to motivate and clarify Software-Defined Networking (SDN)

00:57:25
https://www.youtube.com/watch?v=WVs7Pc99S7w

Summary

TLDRIn his keynote speech, Professor Scott Shenker emphasizes the need for fundamental changes in networking, specifically through the lens of Software Defined Networking (SDN). He identifies the existing challenges in networking architectures, particularly their rigidity and complexity, and argues for better abstractions to enhance flexibility and manageability. Throughout the talk, he uses analogies from areas such as programming and user interface design to highlight the importance of simplicity and effective abstractions. His call to action is for the networking field to move away from complicated distributed protocols and towards clearer, modular solutions that enhance functionality without being encumbered by the underlying complexity. Shenker discusses the relevance of a Network Operating System and modular programming as pivotal elements for the future of networking, while openly acknowledging the difficulties in transitioning existing networks to SDN models.

Takeaways

  • 🔑 Network architectures are overly complex and rigid.
  • 🛠️ SDN emphasizes the need for clear abstractions in networking.
  • 📊 Effective abstractions separate control and forwarding tasks.
  • 🚀 Modular programming facilitates handling complex functionalities.
  • 🌍 Global views enhance network management and efficiency.
  • ⚙️ Moving from distributed protocols to abstractions is essential.
  • 👨‍💻 User interface design principles apply to networking.
  • 🔗 The need for flexibility in interdomain routing is paramount.
  • 🔄 Incremental changes can help integrate SDN in existing networks.
  • 📉 Better abstractions can reduce operational complexity.

Timeline

  • 00:00:00 - 00:05:00

    The keynote speaker, Professor Scott Shanker from UC Berkeley, is introduced. He has collaborated on research activities with Stanford, particularly in the area of networking and cloud computing.

  • 00:05:00 - 00:10:00

    Scott begins his talk by discussing the challenges in teaching networking fundamentals compared to operating systems and databases, emphasizing the complexities and weak foundations in networking as a discipline.

  • 00:10:00 - 00:15:00

    He presents two conundrums about the teaching of networking principles, questioning why networking principles lack robustness compared to other fields, and calls for clarification on the foundations of software-defined networking (SDN).

  • 00:15:00 - 00:20:00

    Scott shares personal anecdotes illustrating the importance of extracting simplicity from complexity, suggesting that mastering complexity does not equate to understanding principles, as evidenced by his experiences with algebra and user interface design.

  • 00:20:00 - 00:25:00

    He emphasizes the notion that programming languages have evolved through abstraction to manage complexity, contrasting this with networking where control-plane abstractions are still lacking, leading to unnecessary complexity in network management.

  • 00:25:00 - 00:30:00

    Abstractions in networks, such as layers, are discussed; however, Scott criticizes existing interfaces for being poor examples of modularity, as they expose too many implementation details, unlike successful programming abstractions.

  • 00:30:00 - 00:35:00

    He identifies a need for better control-plane abstractions in networking, proposing that the focus should shift from treating symptoms of complexity to addressing the foundational issues in networking design.

  • 00:35:00 - 00:40:00

    Scott advocates for defining clear abstractions for networking tasks: flexible forwarding models, distributed state management, and detailed configuration processes to simplify networking control tasks without unnecessary complexity.

  • 00:40:00 - 00:45:00

    He conceptualizes a 'Network Operating System' to provide a global view of the network which simplifies control programming while separating concerns, allowing complex network management tasks to become manageable.

  • 00:45:00 - 00:50:00

    Scott addresses the challenges of convergence in a dynamic network environment, suggesting that updates to the global network view should be approached strategically to avoid knee-jerk responses to state changes, maintaining system stability and performance.

  • 00:50:00 - 00:57:25

    In conclusion, Scott argues that building cleaner abstractions is essential for the evolution of networking, encouraging a focus on defining better abstractions rather than relying solely on distributed protocols or complicated mechanisms.

Show more

Mind Map

Video Q&A

  • What is Software Defined Networking (SDN)?

    SDN is an approach to networking that uses software-based controllers or APIs to communicate with the underlying hardware, allowing for more flexibility and programmability.

  • What are the main challenges in current networking architectures?

    Current architectures are often rigid and complex, making it difficult to adapt to new requirements and technologies.

  • Why are abstractions important in networking?

    Abstractions help simplify the complexity of networking by providing a clear interface between different components, allowing for easier management and development.

  • How does Professor Shenker suggest improving networking?

    He suggests redefining interfaces and introducing better abstractions to separate concerns within networking, improving functionality while reducing complexity.

  • What examples does he use to illustrate his points?

    He uses analogies from programming and user interface design to explain the value of simplicity and effective abstractions.

  • Why is the concept of a 'Network Operating System' mentioned?

    A Network Operating System can provide a global view and help manage states and configurations in a simplified manner.

  • What is the significance of modular programming in networking?

    Modular programming enables the development of complex functionalities without the need to deal with their complexities upfront.

  • How can SDN be applied to existing networks?

    While challenging, integrating SDN into existing networks requires careful planning and potentially incremental changes to gradually adopt the new approach.

  • What does Professor Shenker say about the future of protocols like BGP?

    He acknowledges the ongoing research into protocols like BGP but emphasizes the need for new abstractions to improve interdomain routing.

  • What is the takeaway regarding the evolution of Internet architecture?

    To create a more evolvable Internet architecture, eliminating dependencies on rigid protocols like IP and focusing on clean interfaces is essential.

View more video summaries

Get instant access to free YouTube video summaries powered by AI!
Subtitles
en
Auto Scroll:
  • 00:00:07
    next speaker is our invited keynote
  • 00:00:08
    speaker I want to invite Professor Scott
  • 00:00:10
    Shanker on stage here Scott is professor
  • 00:00:14
    at UC Berkeley at computer science is
  • 00:00:17
    also head of the net well come on
  • 00:00:21
    Scotch uh the networking uh president of
  • 00:00:24
    the international Computer Science
  • 00:00:26
    Institute at Berkeley and uh Scott has
  • 00:00:28
    been close
  • 00:00:30
    Ally and partner in in some of the
  • 00:00:32
    research work we've been doing over the
  • 00:00:34
    last few years it's been um one part of
  • 00:00:37
    the um Clean Slate activities we've done
  • 00:00:40
    together with Stanford so this is
  • 00:00:41
    combined um Stanford and Berkeley
  • 00:00:44
    activity uh Ericson is just now joining
  • 00:00:47
    a Berkeley um
  • 00:00:51
    uh research program called amplitudes no
  • 00:00:54
    sorry algorithms machines and people
  • 00:00:57
    which is called amplab and it's relating
  • 00:01:00
    to cloud computing and crowd sourcing
  • 00:01:02
    and stuff like that and where where
  • 00:01:04
    Scott is one of the uh key leading
  • 00:01:07
    professors so uh we are very honored to
  • 00:01:10
    have you here Scott um your talk
  • 00:01:14
    today I'll have to check your title
  • 00:01:17
    again from protocols to abstractions and
  • 00:01:21
    um well I think I can have a guess what
  • 00:01:24
    you will talk about but I'm excited to
  • 00:01:25
    see so
  • 00:01:28
    um very good
  • 00:01:33
    and you
  • 00:01:35
    quick very well welcome Scotland thank
  • 00:01:39
    you so whoops I need to um so I wanted
  • 00:01:42
    to apologize to ton for two reasons one
  • 00:01:45
    is uh I didn't introduce myself when I
  • 00:01:48
    came in so when the previous speaker
  • 00:01:50
    stopped I saw him Panic run out the room
  • 00:01:52
    to try and find where his keynote
  • 00:01:54
    speaker was uh and uh I I was already
  • 00:01:58
    lurking back here so let him suffer in
  • 00:02:00
    silence the other one is that uh he had
  • 00:02:03
    no idea what I was going to talk about
  • 00:02:05
    when he invited me and so uh I I think
  • 00:02:07
    once he sees this talk he'll uh think
  • 00:02:10
    twice so let me start off so I want to
  • 00:02:13
    talk about the future of
  • 00:02:15
    networking and the past to protocols
  • 00:02:17
    this is Joint work with Martin cassado
  • 00:02:19
    Tam konin Nick mun and and many others
  • 00:02:22
    these people are familiar to many of you
  • 00:02:25
    and what it really is is an attempt to
  • 00:02:28
    motivate and clarify what I call
  • 00:02:29
    software defined networking I think it's
  • 00:02:32
    the same you refer to by your split
  • 00:02:33
    architecture I'm not sure what the
  • 00:02:35
    terminology is but uh we refer to it as
  • 00:02:39
    sdn and my talk is going to start with
  • 00:02:43
    sort of a Noah's Arc you know it's two
  • 00:02:45
    of everything I'm going to start with
  • 00:02:46
    two conundrums and then two questions
  • 00:02:47
    and then two stories and then two quotes
  • 00:02:50
    and then hopefully you'll have had too
  • 00:02:51
    much by that
  • 00:02:54
    time um so let's start with an academic
  • 00:02:58
    Paradox or conundrum so so I teach at UC
  • 00:03:01
    Berkeley um and my colleagues when they
  • 00:03:04
    teach operating systems or databases
  • 00:03:07
    they teach fundamental principles they
  • 00:03:08
    have things like synchronization and
  • 00:03:10
    mutual exclusion and then I get up and I
  • 00:03:12
    teach introductory networking what do I
  • 00:03:14
    teach I teach a bag of
  • 00:03:16
    protocols okay I have no principles you
  • 00:03:20
    know the end to end principle is just a
  • 00:03:22
    vague design guideline but we have
  • 00:03:26
    nothing then on the Practical end of
  • 00:03:28
    things you know comp a and storage have
  • 00:03:30
    been virtualized they're now very
  • 00:03:32
    flexible easy to
  • 00:03:34
    manage not so much with networks now I
  • 00:03:37
    understand that a fair amount of your
  • 00:03:38
    profits come from the fact that these
  • 00:03:40
    are still complex but but that doesn't
  • 00:03:42
    mean we should stop there and and
  • 00:03:44
    rejoice in that uh so this talk is going
  • 00:03:48
    to really address two
  • 00:03:50
    questions one is why are the foundations
  • 00:03:53
    and networking so weak I mean is it just
  • 00:03:55
    that we're idiots and that you know the
  • 00:03:56
    people who do databases and operating
  • 00:03:58
    systems are smarter than we are that's
  • 00:03:59
    what my colleagues that's their
  • 00:04:02
    explanation um and then how can we make
  • 00:04:04
    them
  • 00:04:06
    stronger so those are the two things and
  • 00:04:08
    the answers to both of these questions
  • 00:04:11
    really lie in the tension between
  • 00:04:13
    complexity and
  • 00:04:15
    simplicity so we all know that networks
  • 00:04:17
    are becoming increasingly complex you
  • 00:04:20
    know when they were first designed they
  • 00:04:22
    were actually quite simple I mean know
  • 00:04:23
    ethernet is an incredibly simple
  • 00:04:25
    networking design there's nothing
  • 00:04:27
    complex about it and the same thing with
  • 00:04:29
    IP it's core it's very complex I mean
  • 00:04:31
    very simple we have all these new
  • 00:04:33
    control requirements that have led to
  • 00:04:35
    the complexity we have akles and vlans
  • 00:04:37
    and traffic engineering and middle boxes
  • 00:04:38
    and deep packet inspection and that's
  • 00:04:41
    made what used to be this sort of very
  • 00:04:42
    elegant design very
  • 00:04:45
    complex now the infrastructure still
  • 00:04:48
    works and that's because people like you
  • 00:04:50
    are great at mastering the
  • 00:04:54
    complexity now this ability to master
  • 00:04:58
    complexity it's both a blessing and a
  • 00:05:02
    curse because often when you get a
  • 00:05:04
    system that is extremely complex what
  • 00:05:07
    that's telling you is it's built on weak
  • 00:05:10
    foundations now the complexity is a
  • 00:05:13
    symptom not a cause that is the weak the
  • 00:05:16
    foundations aren't weak because it's
  • 00:05:17
    complex it's complex because the
  • 00:05:19
    foundations are weak but the problem is
  • 00:05:21
    we've gotten great at treating the
  • 00:05:24
    symptoms and we sometimes neglect the
  • 00:05:27
    cause so I I want to
  • 00:05:30
    sort of talk about two stories one is so
  • 00:05:34
    when I was growing up I had a lot of
  • 00:05:35
    trouble learning algebra and my father
  • 00:05:38
    you know I mean I was like most of you
  • 00:05:40
    reasonably right nothing special but my
  • 00:05:42
    father was really perplexed by why was I
  • 00:05:44
    having so much trouble learning algebra
  • 00:05:46
    and so he worked with me for a couple of
  • 00:05:48
    weeks and he finally turns to me says
  • 00:05:49
    Scott your problem isn't that you can't
  • 00:05:51
    learn algebra it's that you're so good
  • 00:05:52
    at arithmetic you don't need it that
  • 00:05:55
    when they would give me an algebra
  • 00:05:56
    problem I would sort of go and plug in a
  • 00:05:58
    couple of numbers and figure out what
  • 00:05:59
    the answer was and then come out and
  • 00:06:01
    solve it by guessing so I was I used my
  • 00:06:04
    skill at mastering the complexity of
  • 00:06:06
    arithmetic to avoid learning algebra and
  • 00:06:10
    once he pointed that out to me you know
  • 00:06:12
    I was able to learn it and then let me
  • 00:06:14
    tell another story I spent the first 15
  • 00:06:17
    years of my research life at Xerox Park
  • 00:06:20
    and at the time I joined which was the
  • 00:06:22
    early to mid 80s it was the mecca for
  • 00:06:24
    user interface design I mean it was a
  • 00:06:26
    decade ahead of everybody else in the
  • 00:06:28
    world and Norman who was one of the user
  • 00:06:31
    interface designers that you know became
  • 00:06:33
    famous at Apple came to to give a
  • 00:06:36
    colloquium and so he walks in and and
  • 00:06:38
    you know the the the auditorium was
  • 00:06:41
    packed and and at that point Zero's Park
  • 00:06:42
    was heavily mailed so it's packed with
  • 00:06:44
    all these
  • 00:06:45
    males and so don Norman sort of ambles
  • 00:06:48
    up to the stage and you know takes his
  • 00:06:50
    time and then looks out at the audience
  • 00:06:51
    and he says how many of you drive a
  • 00:06:54
    stick shift so we all look at each other
  • 00:06:57
    and then you know then most of I didn't
  • 00:06:59
    raise my hand I don't drive a stick
  • 00:07:00
    shift but you know almost everybody else
  • 00:07:02
    did and they were very proud you it was
  • 00:07:03
    like I drive a stick shift I'm a man and
  • 00:07:06
    and he said looks at us he just calmly
  • 00:07:07
    scans the audience he says none of you
  • 00:07:10
    should ever design a user
  • 00:07:15
    interface and so there are two morals to
  • 00:07:17
    this story one is that the ability to
  • 00:07:21
    master complexity the ability to drive a
  • 00:07:23
    stick shift is very different than the
  • 00:07:25
    ability to extract
  • 00:07:27
    Simplicity and that if if you like
  • 00:07:30
    driving a stick shift then you're drawn
  • 00:07:32
    to mastering complexity but designing
  • 00:07:35
    user interface is all about extracting
  • 00:07:37
    Simplicity and the two very different
  • 00:07:39
    tasks and the other point that he made
  • 00:07:41
    is we should put a lot more effort into
  • 00:07:44
    this than into mastering complexity when
  • 00:07:46
    you master complexity you have to do it
  • 00:07:47
    for every single problem when you
  • 00:07:49
    extract Simplicity that's much longer
  • 00:07:54
    lasting so where is Simplicity triumphed
  • 00:07:57
    you know where it's an example where
  • 00:07:59
    we've
  • 00:08:00
    successfully extracted Simplicity out of
  • 00:08:02
    a place where things used to be very
  • 00:08:04
    complex so most people would say
  • 00:08:06
    programming is is one of our best
  • 00:08:08
    examples in computer science so how did
  • 00:08:10
    programming become simple so we started
  • 00:08:13
    with machine languages had no
  • 00:08:15
    abstractions you had to deal with all
  • 00:08:16
    the low-level
  • 00:08:18
    details then you had higher level
  • 00:08:20
    languages and they used a lot of useful
  • 00:08:22
    abstractions file systems virtual memory
  • 00:08:24
    abstract data types and then we have the
  • 00:08:26
    modern languages that have object
  • 00:08:28
    orientation and garbage collection and
  • 00:08:30
    so
  • 00:08:31
    forth and the lesson was that
  • 00:08:34
    abstractions are the way we extracted
  • 00:08:37
    Simplicity in this case that by defining
  • 00:08:39
    these abstractions that we could use
  • 00:08:41
    then our task became simpler and
  • 00:08:45
    simpler so so why are these abstractions
  • 00:08:48
    useful so interfaces are really just
  • 00:08:50
    instantiations of abstractions so why
  • 00:08:52
    are abstractions are interfaces useful
  • 00:08:55
    well it's obvious I mean you all use
  • 00:08:56
    them that they Shield you from low-level
  • 00:08:58
    details right right you allow freedom of
  • 00:09:00
    implementation on both sides if you have
  • 00:09:02
    a clean interface then how you implement
  • 00:09:04
    this module is independent of how you
  • 00:09:06
    implement this one so you can define a
  • 00:09:09
    modular programming structure now how
  • 00:09:12
    many people here have seen Barbara
  • 00:09:13
    loff's talk on the power of abstraction
  • 00:09:15
    she gave a turing award lecture on this
  • 00:09:18
    if not go go watch it you know there 18
  • 00:09:21
    versions on YouTube it's really a very
  • 00:09:23
    deep lecture I mean it's something that
  • 00:09:26
    that really inspired me it stayed with
  • 00:09:28
    me
  • 00:09:30
    um but the key Point she makes is that
  • 00:09:33
    interfaces they don't remove complexity
  • 00:09:35
    they merely hide it that is somebody
  • 00:09:37
    deals with complexity once and then
  • 00:09:40
    everybody else gets to leverage that
  • 00:09:41
    work so it's not like you you know
  • 00:09:43
    somehow you've magically made complexity
  • 00:09:45
    disappear you've just been able to
  • 00:09:47
    encapsulate it and let everybody else
  • 00:09:49
    use that work and so what Barbara lisof
  • 00:09:52
    says in her talk is modularity based on
  • 00:09:54
    abstraction is the way things get
  • 00:09:58
    done you this is why we can have
  • 00:10:00
    programs that have 10,000 10 million
  • 00:10:02
    lines of code so if you talk about the
  • 00:10:05
    right way to overcome complexity you
  • 00:10:06
    thought networks were complex 10 million
  • 00:10:09
    lines of code making that simple that's
  • 00:10:12
    a real success
  • 00:10:14
    story now the other thing she said is
  • 00:10:17
    that abstraction is at the center of
  • 00:10:20
    much work in computer science so this is
  • 00:10:22
    something that most areas in computer
  • 00:10:23
    science focus
  • 00:10:25
    on not so much
  • 00:10:27
    networking so where do we talk about
  • 00:10:29
    abstractions and
  • 00:10:32
    networking so one area where we talk
  • 00:10:34
    about are layers layers are you know one
  • 00:10:37
    place where we talk about abstractions
  • 00:10:40
    so layers provide this very nice data
  • 00:10:43
    plane service abstraction right we have
  • 00:10:45
    you know best effort delivery we then
  • 00:10:47
    have a reliable bite stream these are
  • 00:10:49
    great ways to think about what's go you
  • 00:10:51
    know without worrying about the the
  • 00:10:53
    mechanisms underneath you have this
  • 00:10:55
    abstraction of what the network is doing
  • 00:10:56
    for you these are great these are
  • 00:10:59
    terrific abstractions I'm going to get
  • 00:11:01
    back to it but as an aside as interfaces
  • 00:11:04
    they suck these are awful if my grad
  • 00:11:07
    student designed an interface like this
  • 00:11:09
    I'd flunk them I mean these are they
  • 00:11:11
    violate the basic principle of
  • 00:11:13
    modularity which is you hide the
  • 00:11:15
    implementation details and the fact that
  • 00:11:17
    IP addresses go through the architecture
  • 00:11:20
    duh idiotic right nobody would build a
  • 00:11:24
    system that way now I'm not criticizing
  • 00:11:26
    people who invented this they were just
  • 00:11:27
    making things work but if we were look
  • 00:11:29
    at the interfaces now as system design
  • 00:11:32
    decisions they're terrible they're
  • 00:11:34
    terrible interfaces but that's just an
  • 00:11:36
    aside I'll get back to that later but my
  • 00:11:38
    main point here is while we have good
  • 00:11:40
    data plane abstractions we really don't
  • 00:11:43
    have good control plane
  • 00:11:46
    abstractions there are no sort of
  • 00:11:48
    sophisticated management building blocks
  • 00:11:51
    so every time we have a new control
  • 00:11:53
    requirement we have to add complexity to
  • 00:11:56
    the system because we have to invent
  • 00:11:57
    something new we don't have a build
  • 00:11:59
    building block that we can build
  • 00:12:03
    upon so what we need to do is reverse
  • 00:12:05
    this trend towards complexity in
  • 00:12:07
    networks so we need to simplify
  • 00:12:10
    networking
  • 00:12:11
    control rather than just mastering the
  • 00:12:13
    complexity it's harder to do but it's
  • 00:12:15
    much longer
  • 00:12:16
    lasting and so to break this bad habit
  • 00:12:19
    of continually adding complexity to the
  • 00:12:21
    network we need to
  • 00:12:23
    understand why we're doing it where this
  • 00:12:25
    is coming from so how do we solve
  • 00:12:27
    problems today and what are the require
  • 00:12:29
    IR Ms for those Solutions so the the how
  • 00:12:31
    we solve problems today you know we can
  • 00:12:33
    either Define a new protocol or We Can
  • 00:12:35
    ad hoc mechanism or we can leave it to
  • 00:12:37
    the you know operators doesn't really
  • 00:12:40
    matter which which of these we pick the
  • 00:12:43
    key is What are the requirements for
  • 00:12:44
    those Solutions and there are three
  • 00:12:47
    requirements one is they have to operate
  • 00:12:50
    within the confines of a given data path
  • 00:12:52
    you know your handed IP or MLS or
  • 00:12:54
    whatever your data path is but you're
  • 00:12:56
    given a data path and you've got to live
  • 00:12:58
    with whatever can and cannot do second
  • 00:13:02
    you have to live without communication
  • 00:13:03
    guarantees so you've got a general
  • 00:13:05
    distributed system arbitrary delays
  • 00:13:07
    arbitrary drops that's yours to deal
  • 00:13:10
    with and lastly Your solution has to
  • 00:13:14
    compute the configuration of every
  • 00:13:16
    single physical design device in the
  • 00:13:18
    network whether it's akles or fibs or
  • 00:13:21
    whatever it is that's what you've got to
  • 00:13:23
    end up
  • 00:13:25
    Computing so you've got to operate
  • 00:13:27
    within a con straints of a data path
  • 00:13:31
    you've got to deal without communication
  • 00:13:32
    guarantees and you've got to actually
  • 00:13:35
    provide a detailed configuration for
  • 00:13:37
    every device so I've got a secret for
  • 00:13:39
    you this is insanity this is completely
  • 00:13:43
    crazy so let's say somebody came to you
  • 00:13:46
    and said you've got to program your
  • 00:13:47
    computer and to do so you got to specify
  • 00:13:50
    where every bit is stored you've got to
  • 00:13:52
    deal with all internal communication
  • 00:13:53
    errors meaning if you do a store and it
  • 00:13:55
    fails that's your problem deal with it
  • 00:13:57
    and you've got to do it with a with a
  • 00:13:59
    programming language that doesn't have
  • 00:14:00
    much expressibility what would your
  • 00:14:02
    response be you wouldn't say oh yeah
  • 00:14:04
    sure I'll go do that you would say
  • 00:14:06
    forget it and you would say okay well
  • 00:14:08
    first I'm going to define a higher level
  • 00:14:10
    of abstraction for memory right so I
  • 00:14:12
    don't have to deal with that problem and
  • 00:14:13
    then I'm going to deal divide some
  • 00:14:15
    reliable communication prives so I don't
  • 00:14:17
    have to deal with that problem and then
  • 00:14:18
    I'm going to define a new programming
  • 00:14:20
    language that gives me my expressibility
  • 00:14:23
    so why have we in networking just sort
  • 00:14:26
    of said okay fine we'll go do this
  • 00:14:28
    whereas in every other discipline in
  • 00:14:30
    computer science they said forget it
  • 00:14:31
    we're going to Define some abstractions
  • 00:14:33
    first and get those right and then we'll
  • 00:14:35
    go solve the
  • 00:14:36
    problem so what we do here is we've
  • 00:14:39
    separated the problem into manageable
  • 00:14:41
    pieces we haven't done that in
  • 00:14:42
    networking at least not on the control
  • 00:14:45
    plane so what we need to do is Define
  • 00:14:49
    some abstractions to help us simplify
  • 00:14:51
    how we think about control tasks and so
  • 00:14:54
    the three concerns that I listed are
  • 00:14:55
    this constrained forwarding model
  • 00:14:58
    distributed state and detail
  • 00:15:01
    configuration now the way we Define
  • 00:15:05
    these abstractions the way we separate
  • 00:15:07
    these concerns are going to Define the
  • 00:15:10
    Fundamental abstractions of networking
  • 00:15:12
    okay so these are important decisions to
  • 00:15:14
    make because this is what all networks
  • 00:15:17
    will be built
  • 00:15:19
    around now I just want to point out
  • 00:15:21
    we're not talking about new mechanisms
  • 00:15:23
    we have all the mechanisms we're ever
  • 00:15:25
    going to need okay we just have never
  • 00:15:28
    developed the right obstr
  • 00:15:29
    ractions and the difference between
  • 00:15:31
    mastering complexity and extracting
  • 00:15:34
    Simplicity is whether or not you focus
  • 00:15:37
    on finding the right abstraction versus
  • 00:15:39
    defining a new mechanism and so that's
  • 00:15:42
    the Habit we need to break ourselves of
  • 00:15:43
    is that when you're faced with a new
  • 00:15:45
    design problem you figure out what was
  • 00:15:46
    the right abstraction rather than going
  • 00:15:49
    and proving that you're smart by
  • 00:15:50
    building a protocol that solves your
  • 00:15:53
    problem so we now need abstractions for
  • 00:15:55
    these forwarding distributed State and
  • 00:15:57
    detail configurations so let's go
  • 00:15:58
    through those one by
  • 00:16:00
    one so let's subtract the forwarding
  • 00:16:04
    model so if you're trying to control the
  • 00:16:06
    network you need some kind of flexible
  • 00:16:08
    forwarding model so that the control
  • 00:16:10
    program can specify what happens rather
  • 00:16:12
    than dealing with some limitation of
  • 00:16:13
    what your underlying uh forwarding
  • 00:16:16
    protocol
  • 00:16:17
    does so it Shields the upper layers from
  • 00:16:20
    exactly how you do the forwarding and
  • 00:16:22
    the point is it doesn't really matter
  • 00:16:23
    what you pick you could say the way
  • 00:16:25
    we're going to do forwarding is you hand
  • 00:16:27
    me a general x86 program and I'll run it
  • 00:16:29
    and it'll schedule the packets and we
  • 00:16:31
    use you know the route bricks design
  • 00:16:33
    from Intel that you know it's only about
  • 00:16:35
    a tenth as fast as as forwarding chips
  • 00:16:38
    but completely general or MLS or
  • 00:16:43
    OpenFlow doesn't really matter but let's
  • 00:16:45
    pick one let's pick a clean abstraction
  • 00:16:47
    for How We Do forwarding and then we
  • 00:16:49
    don't have to worry about it
  • 00:16:51
    anymore what about State
  • 00:16:54
    distribution so the control program
  • 00:16:56
    should not have to deal with the
  • 00:16:57
    vagaries of distributed state this is
  • 00:16:59
    really complicated stuff it's the source
  • 00:17:01
    of many errors the number of people who
  • 00:17:03
    know how to build really solid
  • 00:17:05
    distributed systems about 10 you know if
  • 00:17:08
    you look at Google has dozens of
  • 00:17:11
    complicated distributed systems Jeff
  • 00:17:13
    Dean has basically designed all of them
  • 00:17:15
    you know that there are not many people
  • 00:17:17
    who really get this stuff right so it's
  • 00:17:19
    really hard so we should do it once and
  • 00:17:23
    let everybody else leverage it rather
  • 00:17:25
    than having your control program have to
  • 00:17:26
    deal with it so the you know the phrase
  • 00:17:29
    Network operating system that that's
  • 00:17:31
    something that we use is an example of
  • 00:17:33
    this which what it says is we're going
  • 00:17:36
    to provide you with an abstraction which
  • 00:17:38
    is we'll give you a global view of the
  • 00:17:40
    network and that's what you deal with
  • 00:17:43
    you don't have to deal with a the
  • 00:17:45
    physical reality will give you a logical
  • 00:17:46
    view of the
  • 00:17:48
    network and so I'm going to show a
  • 00:17:50
    picture of this in a second but the
  • 00:17:51
    point is the control program will
  • 00:17:53
    operate on this network view which is
  • 00:17:54
    essentially a
  • 00:17:56
    graph and so given the graph is is input
  • 00:17:59
    you then figure out what the
  • 00:18:00
    configuration should be of every
  • 00:18:04
    device so if you take these two
  • 00:18:06
    abstractions you end up with a picture
  • 00:18:08
    like this so the current networks look
  • 00:18:09
    like this you've got protocols in
  • 00:18:10
    between switches you throw them out you
  • 00:18:14
    then Define a network operating system
  • 00:18:15
    that runs on servers in the network you
  • 00:18:18
    control the switches via this forwarding
  • 00:18:20
    interface and this network operating
  • 00:18:22
    system provides This Global Network View
  • 00:18:25
    and then if you're writing a control
  • 00:18:27
    program it's on top of this network view
  • 00:18:29
    you write a control program on top of a
  • 00:18:32
    graph you forget about the fact it's
  • 00:18:34
    distributed that's what the network
  • 00:18:35
    operating system does that it takes
  • 00:18:38
    configuration from here and configures
  • 00:18:41
    the switches and then it takes state
  • 00:18:42
    from the switches and puts it into the
  • 00:18:44
    network view your control program has no
  • 00:18:46
    idea the network is
  • 00:18:48
    distributed so you're running dyra not
  • 00:18:50
    Bellman Ford okay you're just writing a
  • 00:18:53
    program on a
  • 00:18:55
    graph so this is a huge change in the
  • 00:18:57
    paradigm because we're not designing
  • 00:19:00
    control protocols we're designing a
  • 00:19:02
    Control Function what I mean by that
  • 00:19:05
    is the configuration you want is some
  • 00:19:08
    function of the
  • 00:19:11
    view you're not figuring out how to get
  • 00:19:14
    the view you're just saying whatever the
  • 00:19:16
    view is here's what the answer is it's
  • 00:19:19
    just a function so why is this in
  • 00:19:20
    advance it's much easier to write it's
  • 00:19:23
    much easier to check it's much easier to
  • 00:19:24
    reason about because it's just it's just
  • 00:19:27
    like writing a program over a Gra
  • 00:19:29
    graph and the network operating system
  • 00:19:32
    handles all of the state dissemination
  • 00:19:34
    and
  • 00:19:36
    collection so this abstraction bites off
  • 00:19:40
    distribution as a tractable piece and
  • 00:19:42
    solves it and then lets the rest of the
  • 00:19:44
    control problem control program ignore
  • 00:19:48
    it so you might say well what what about
  • 00:19:51
    consistency I mean it really is a
  • 00:19:52
    distributed system you haven't changed
  • 00:19:54
    that but notice you design your network
  • 00:19:57
    operating system
  • 00:19:59
    so that it's eventually consistent that
  • 00:20:01
    is the view will eventually reflect the
  • 00:20:04
    reality of the network that's not hard
  • 00:20:06
    we know how to do that and then notice
  • 00:20:09
    that as long as this is true then you
  • 00:20:11
    will eventually end up with the right
  • 00:20:13
    configuration of your network because
  • 00:20:15
    your view will converge towards reality
  • 00:20:18
    and at every step you're saying my
  • 00:20:20
    configuration is just a function of the
  • 00:20:21
    view when my view gets real my
  • 00:20:23
    configuration is
  • 00:20:26
    correct that's the correctness proof
  • 00:20:28
    that's a lot easier than looking at a
  • 00:20:30
    distributed protocol and trying to
  • 00:20:32
    figure out whether it's actually going
  • 00:20:33
    to converge to the right
  • 00:20:35
    answer so what about transient
  • 00:20:37
    conditions because it it does take you a
  • 00:20:39
    while to converge so it's very hard in a
  • 00:20:41
    distributed protocol to figure out let's
  • 00:20:43
    say are there going to be Loops while
  • 00:20:45
    this is
  • 00:20:46
    converging here it's actually quite easy
  • 00:20:49
    if at every time you have a picture of
  • 00:20:52
    the network and you say that the
  • 00:20:54
    function from The View never creates a
  • 00:20:57
    loop then you will never have Loop
  • 00:21:00
    and
  • 00:21:02
    Dory and you say well hold it you know
  • 00:21:05
    you you've got to distribute the
  • 00:21:06
    controller the controller is not a
  • 00:21:07
    single computer it's actually
  • 00:21:09
    distributed well actually if you sensely
  • 00:21:11
    break up the way the the problem is
  • 00:21:14
    distributed among controllers like every
  • 00:21:16
    controller handles you know an end to
  • 00:21:19
    end path that an end to end path is not
  • 00:21:20
    handled by two separate controllers but
  • 00:21:22
    by a single controller and you split
  • 00:21:24
    those up then you can enforce the no
  • 00:21:26
    Loop condition very easily
  • 00:21:28
    so this is a much easier way to enforce
  • 00:21:31
    correctness conditions on a very
  • 00:21:32
    complicated distributed Problem by
  • 00:21:35
    breaking it
  • 00:21:37
    apart so now why does this scale this is
  • 00:21:39
    a question we always get that you know
  • 00:21:42
    okay you've got this big complicated
  • 00:21:43
    Network and all of a sudden you're
  • 00:21:44
    saying that I'm going to give you a
  • 00:21:45
    central view it can't possibly scale but
  • 00:21:48
    actually consistency is the reason why
  • 00:21:49
    it scales down at the fast time scales
  • 00:21:52
    of per packet you don't need any
  • 00:21:54
    consistency packets go independently at
  • 00:21:57
    the per flow scale again you don't need
  • 00:21:59
    any consistency every flow can be
  • 00:22:01
    handled
  • 00:22:03
    individually Network events meaning
  • 00:22:05
    switches coming and going links coming
  • 00:22:07
    and going here you need eventual
  • 00:22:09
    consistency you don't need transactional
  • 00:22:11
    consistency just eventual consistency
  • 00:22:13
    you can build a scalable system that
  • 00:22:15
    that's eventually consistent as big as
  • 00:22:17
    you want the only place you need strong
  • 00:22:20
    consistency is essentially where you
  • 00:22:22
    implement your control program that is
  • 00:22:24
    everybody needs to agree on what the
  • 00:22:25
    control program
  • 00:22:27
    is that happens on human time scales you
  • 00:22:30
    know maximum 10 per second something
  • 00:22:32
    like that easily can build a
  • 00:22:35
    transactional system that can handle
  • 00:22:36
    that rate of change without breathing
  • 00:22:38
    hard so there's no scaling problem here
  • 00:22:41
    whatsoever so the scaling is
  • 00:22:45
    straightforward so you might say okay
  • 00:22:47
    well what about open Flow isn't that
  • 00:22:49
    what everybody's talking about well the
  • 00:22:52
    network operating system conveys the
  • 00:22:55
    configuration of the global Network view
  • 00:22:57
    remember I took a Global Network View
  • 00:23:00
    and then I my control program decided
  • 00:23:02
    what the configuration I want and the
  • 00:23:04
    network operating system would then take
  • 00:23:05
    it down to the physical
  • 00:23:08
    switches nothing in that statement tells
  • 00:23:10
    me what configuration means it just says
  • 00:23:13
    whatever state you want that switch to
  • 00:23:16
    have your control program decides it and
  • 00:23:18
    then it gets handed down to it open Flow
  • 00:23:21
    is is is one possible solution to that
  • 00:23:25
    it's clearly not the right solution I
  • 00:23:27
    mean it it
  • 00:23:29
    probably a very good solution for now
  • 00:23:32
    but it's not there's nothing that says
  • 00:23:34
    this is fundamentally the right
  • 00:23:36
    answer open think of open Flow as the
  • 00:23:39
    x86 instruction set is the x86
  • 00:23:42
    instruction sets correct is it the right
  • 00:23:44
    answer no it's good enough for what we
  • 00:23:46
    use it so for why bother changing it
  • 00:23:48
    that's what open Flow is it's the
  • 00:23:50
    instruction set that we happen to use
  • 00:23:52
    but we shouldn't get a hung up on it
  • 00:23:54
    being exactly
  • 00:23:57
    right so so let's think about what the
  • 00:23:59
    fundamental principles are of software
  • 00:24:02
    defined networking the core principle is
  • 00:24:05
    that the configuration flows from the
  • 00:24:07
    Glo global view that is you look at the
  • 00:24:08
    global view you figure out what you how
  • 00:24:10
    you want the network configured and then
  • 00:24:12
    you instantiate that
  • 00:24:14
    configuration you have lots of
  • 00:24:16
    performance issues for instance every
  • 00:24:19
    time the network changes you can't wait
  • 00:24:21
    to go for the view to change and then
  • 00:24:23
    the controller to come back and
  • 00:24:24
    instantiate new state to respond to
  • 00:24:27
    it so you need to do things like
  • 00:24:30
    configure backup paths or other local
  • 00:24:33
    you know other sort of local programs
  • 00:24:35
    that would respond to local state and
  • 00:24:37
    change and the only Point here is that
  • 00:24:40
    doesn't violate sdn at all that when you
  • 00:24:42
    hear people talk about sdn often other
  • 00:24:45
    academics at least they say well you
  • 00:24:47
    know sdn doesn't work because what
  • 00:24:48
    happens if I need a backup path that's
  • 00:24:51
    just a different way of configuring it's
  • 00:24:52
    just part of configuration doesn't
  • 00:24:54
    change anything about
  • 00:24:56
    SDM so for in here would be a completely
  • 00:24:59
    consistent sdn
  • 00:25:01
    implementation that you know the
  • 00:25:02
    forwarding model that you have on the
  • 00:25:04
    line cards is you have open Flow plus
  • 00:25:05
    the fully General forwarding model you
  • 00:25:07
    know an x86 or maybe you want to use a
  • 00:25:09
    GPU to be more efficient but you have a
  • 00:25:12
    fully General forwarding model your
  • 00:25:14
    switch how you configure a switch is you
  • 00:25:16
    hand it a Java program an arbitrary Java
  • 00:25:19
    program so if you want to say if this
  • 00:25:20
    link fails do this and if that link
  • 00:25:22
    fails do that fine you just hand off a
  • 00:25:25
    program and then the network operating
  • 00:25:27
    system has this distributed State model
  • 00:25:29
    that's essentially key value store with
  • 00:25:31
    a little bit of constraints on the data
  • 00:25:32
    model to sort of so you can make sure
  • 00:25:34
    that you don't get intrinsic in
  • 00:25:36
    consistencies on how you're expressing
  • 00:25:40
    state I'm not advocating that this is
  • 00:25:42
    something we should move towards now but
  • 00:25:44
    the point is this is a completely
  • 00:25:46
    consistent with everything I've been
  • 00:25:48
    saying about this being a viable way to
  • 00:25:50
    implement software defined
  • 00:25:54
    networking and it has the nice feature
  • 00:25:57
    that you can start off with features in
  • 00:25:59
    software and then migrate them to
  • 00:26:01
    hardware and you know right now the the
  • 00:26:04
    sort of the x86 foring you know an order
  • 00:26:07
    magnitude slower than Hardware so if 10%
  • 00:26:10
    of your traffic are less you're using
  • 00:26:11
    this new feature you're fine so new
  • 00:26:14
    features start in software small
  • 00:26:16
    fraction your traffic is using them and
  • 00:26:18
    then they'll gravitate over to Hardware
  • 00:26:20
    if it proves to be valuable perfectly
  • 00:26:22
    viable
  • 00:26:25
    approach so are we done is is this no I
  • 00:26:29
    mean am I going to leave you know with a
  • 00:26:32
    half hour left of my time I'm an
  • 00:26:34
    academic of course not you know um so
  • 00:26:38
    this
  • 00:26:39
    approach is not done because it requires
  • 00:26:41
    the control program or the operator to
  • 00:26:44
    configure each individual Network
  • 00:26:47
    device and that's way more complicated
  • 00:26:50
    than it should
  • 00:26:52
    be so the network operating system eases
  • 00:26:56
    the implementation of functionality
  • 00:26:59
    by it says okay you tell me how you want
  • 00:27:00
    to configure the network and I'll go do
  • 00:27:02
    it for you but it doesn't ease the
  • 00:27:04
    specification of functionality you still
  • 00:27:06
    need to decide on what the FIB is and
  • 00:27:07
    what the akles are and every single
  • 00:27:09
    switch in the
  • 00:27:10
    network
  • 00:27:12
    okay that's way too
  • 00:27:15
    complicated so how can we provide
  • 00:27:17
    abstractions that are more meaningful to
  • 00:27:19
    operators and to control
  • 00:27:23
    programs well it's by offering an
  • 00:27:25
    abstraction so what you want to do is
  • 00:27:27
    give control program an abstract view of
  • 00:27:29
    the
  • 00:27:30
    network you don't want to show them the
  • 00:27:32
    full Network you want to give them an
  • 00:27:33
    abstract view of the network and then
  • 00:27:36
    the control program takes that abstract
  • 00:27:37
    View and it configures that abstract
  • 00:27:40
    View and you want the model to provide
  • 00:27:43
    just enough details so that I can
  • 00:27:44
    express my goals without providing me
  • 00:27:47
    all the information I would need to
  • 00:27:49
    implement those these goals because I I
  • 00:27:51
    don't want to imple if I'm the operator
  • 00:27:52
    I don't want to implement them I just
  • 00:27:53
    want to specify them so here's an
  • 00:27:55
    example let's say we want to do access
  • 00:27:57
    control and here's the full Network View
  • 00:27:59
    and these blue lines are sort of the
  • 00:28:01
    external access links and then the the
  • 00:28:03
    black lines are internal links so is
  • 00:28:06
    that what I want to show an operator of
  • 00:28:08
    course not what I want to show an
  • 00:28:09
    operator if they're talking about access
  • 00:28:11
    control is this it says you know can
  • 00:28:13
    this guy talk to this guy yes or no
  • 00:28:16
    that's all that ought to be specified
  • 00:28:18
    the internal structure of the network
  • 00:28:20
    the operator doesn't need to see that at
  • 00:28:22
    all this is how you implement the AAL
  • 00:28:25
    but you want to specify it on the
  • 00:28:26
    simplest Network model possible and in
  • 00:28:29
    that case it's just a single crossbar
  • 00:28:31
    that's plenty to implement to to specify
  • 00:28:34
    what kind of access controls you
  • 00:28:37
    want so a more detailed model would be
  • 00:28:40
    to say the service model for the network
  • 00:28:42
    is a series of table lookups that you
  • 00:28:45
    might want to do a look up at layer two
  • 00:28:46
    and then you want to do a look up at
  • 00:28:47
    layer three and then maybe you want to
  • 00:28:49
    apply some akles and maybe look up at
  • 00:28:50
    some other table but it's really a
  • 00:28:53
    series of table
  • 00:28:55
    lookups I mean globally I don't mean
  • 00:28:57
    within a single switch meaning that's
  • 00:28:59
    what you want your network to do is so
  • 00:29:00
    to go look at the packet look it up and
  • 00:29:02
    do a couple of lookups for instance here
  • 00:29:04
    if you were just worried about access
  • 00:29:05
    control you would just do an AO lookup
  • 00:29:07
    which says you're coming in on this
  • 00:29:08
    input Port are you allowed to go out on
  • 00:29:10
    that output port or not yes or
  • 00:29:14
    no so if that's the way you specify what
  • 00:29:17
    you want your network to do what you do
  • 00:29:20
    is you create these table pipelines in
  • 00:29:22
    Virtual
  • 00:29:24
    space on you know this is your abstract
  • 00:29:26
    Network and then you figure out how to
  • 00:29:30
    actually Implement these table lookups
  • 00:29:32
    on the physical Hardware you have so
  • 00:29:34
    this is sort of think of this is one
  • 00:29:36
    logical switch in logical space you
  • 00:29:39
    might have a hundred physical switches
  • 00:29:41
    you just need to make sure you want to
  • 00:29:43
    make sure each one of these lookups
  • 00:29:45
    happens it doesn't have to happen on
  • 00:29:46
    every switch just make sure it happens
  • 00:29:51
    somewhere so who Maps this abstract view
  • 00:29:55
    to the the physical view so we're going
  • 00:29:57
    to I defined something called a network
  • 00:30:00
    hypervisor I have come up with the worst
  • 00:30:02
    piece of terminology in the world a
  • 00:30:03
    hypervisor but when I call it a
  • 00:30:05
    hypervisor everybody gets very confused
  • 00:30:07
    and says isn't that what VMware sells so
  • 00:30:09
    it's a network
  • 00:30:11
    hypervisor and it's a hypervisor because
  • 00:30:14
    it's a layer between this abstract model
  • 00:30:17
    and the network operating system so this
  • 00:30:20
    is the picture I used to show you and
  • 00:30:23
    now what we do is we jack up the control
  • 00:30:25
    program and we stick in this network
  • 00:30:28
    supervisor and what it does is it
  • 00:30:30
    provides this abstract Network View and
  • 00:30:33
    so I write a control program to
  • 00:30:35
    configure let's say this pipeline of of
  • 00:30:37
    table lookups and so I say okay you know
  • 00:30:40
    here here's how you populate those
  • 00:30:41
    abstract
  • 00:30:43
    tables the hypervisor then says okay now
  • 00:30:46
    I know what lookups I have to do I see
  • 00:30:49
    the view of the entire network I will
  • 00:30:51
    figure out where those lookups ought to
  • 00:30:53
    happen and I will instantiate the
  • 00:30:55
    correct state in those physical switches
  • 00:30:57
    to make sure this
  • 00:30:59
    happens and then the network operating
  • 00:31:01
    system goes down and instanes that and
  • 00:31:04
    real
  • 00:31:05
    switches okay that's how it
  • 00:31:09
    works so basically what I'm calling for
  • 00:31:12
    are three basic network interfaces
  • 00:31:15
    there's a forwarding interface that
  • 00:31:17
    provides a flexible abstract forwarding
  • 00:31:20
    model there's a Global Network view it
  • 00:31:22
    Shields the higher layers from State
  • 00:31:24
    dissemination and collection you don't
  • 00:31:26
    have to worry about it I'm just going to
  • 00:31:27
    give you a graph
  • 00:31:28
    and then there's this abstract Network
  • 00:31:30
    view that Shields the control program
  • 00:31:32
    from details of the physical
  • 00:31:34
    Network and so I claim that for control
  • 00:31:37
    programs these are the three
  • 00:31:39
    abstractions not a three abstraction the
  • 00:31:41
    three abstractions we will need end of
  • 00:31:47
    story so that in terms of motivating
  • 00:31:52
    software defined networking or the split
  • 00:31:53
    architecture we've all talked about it
  • 00:31:55
    is a mechanism and isn't it great the
  • 00:31:58
    point is this is how we arrived at it by
  • 00:32:02
    thinking about what abstractions you
  • 00:32:06
    need so let's go from software defin
  • 00:32:08
    networking to sort of Clean Slate
  • 00:32:09
    architectures because this is where I
  • 00:32:11
    spend most of my academic life is
  • 00:32:13
    thinking about if we were to redesign
  • 00:32:14
    the internet how would we design
  • 00:32:17
    it and so you know what I've talked
  • 00:32:19
    about today are the basic abstractions
  • 00:32:21
    that would underly softer Define
  • 00:32:26
    networking then but what are the
  • 00:32:28
    abstractions that might be relevant to
  • 00:32:31
    the overall architecture not just to
  • 00:32:32
    network control what about more General
  • 00:32:35
    architectural questions besides Network
  • 00:32:38
    control so one problem you would like to
  • 00:32:41
    solve what something that everybody says
  • 00:32:42
    is the current Internet architecture is
  • 00:32:44
    very rigid it's very hard to change
  • 00:32:46
    going from IP to IPv6 has been decade
  • 00:32:49
    long struggle and that's a pretty mild
  • 00:32:52
    change that it's very hard to change
  • 00:32:55
    things and so why is that and can we fix
  • 00:32:58
    that
  • 00:32:59
    problem so the question is how can we
  • 00:33:01
    make the architecture evolvable how
  • 00:33:03
    could we design an internet architecture
  • 00:33:04
    that's evolvable and I've heard people
  • 00:33:06
    talking about that for 15 years and I've
  • 00:33:08
    never heard a good solution
  • 00:33:10
    proposed I'm going to propose one in two
  • 00:33:14
    slides so first let's talk about why the
  • 00:33:16
    architecture is
  • 00:33:18
    rigid so IP is a central component of
  • 00:33:21
    the
  • 00:33:21
    architecture IP is embedded in
  • 00:33:23
    interdomain routing interdomain routing
  • 00:33:26
    is hard to change because all the domain
  • 00:33:27
    have had to agree on it IP is embedded
  • 00:33:30
    in applications via the API it's hard to
  • 00:33:32
    change all
  • 00:33:36
    applications so we're stuck it's really
  • 00:33:38
    hard to get rid of Ip so pictorially it
  • 00:33:40
    looks like this I find this diagram
  • 00:33:42
    actually a very useful way to think
  • 00:33:44
    about internet architectures not just by
  • 00:33:46
    drawing a bunch of domains but actually
  • 00:33:49
    looking at this sort of Bird's eyye view
  • 00:33:50
    you start with an application it
  • 00:33:52
    interacts with the network stack which
  • 00:33:54
    interacts with the domain which
  • 00:33:55
    interacts with the rest of the
  • 00:33:56
    networking have you seen those ort of
  • 00:33:58
    the New Yorker covers where they show
  • 00:34:00
    New York City and then you know it sort
  • 00:34:01
    of go to the rest of New York and then
  • 00:34:02
    you know sort of California is that
  • 00:34:04
    little speck off into the distance well
  • 00:34:05
    this is sort of the New Yorker view of
  • 00:34:07
    Internet architecture that starts with
  • 00:34:09
    the application being the center of the
  • 00:34:10
    world and the rest of the internet of
  • 00:34:12
    being sort of like
  • 00:34:14
    California so we have two
  • 00:34:17
    fundamental standards IP and
  • 00:34:21
    bgp IP is embedded in applications it's
  • 00:34:24
    embedded in bgp and we end up with a
  • 00:34:27
    very rigid
  • 00:34:30
    architecture so now as an alternative
  • 00:34:33
    let's insert two architectural
  • 00:34:37
    abstractions one let's put in a clean
  • 00:34:39
    interdomain routing interface okay
  • 00:34:42
    there's no leakage of what happens
  • 00:34:44
    inside a domain the way you define
  • 00:34:46
    interdomain routing you don't refer to
  • 00:34:48
    anything that happens inside a domain
  • 00:34:49
    and particularly don't refer to the
  • 00:34:50
    addressing inside the domain you just
  • 00:34:52
    route on domain
  • 00:34:54
    names and you make sure that it it can
  • 00:34:57
    do flexible route computation it's not
  • 00:34:58
    like bgp that sort of bakes the route
  • 00:35:00
    computation into the protocol
  • 00:35:04
    itself and then we Define a clean
  • 00:35:06
    Network
  • 00:35:07
    API that you there's no leakage of the
  • 00:35:10
    network architecture into the
  • 00:35:12
    application why do the architecture need
  • 00:35:13
    why does the application need to know
  • 00:35:14
    about how you do addressing ought to be
  • 00:35:16
    dealing with names right and you just
  • 00:35:19
    make sure it has flexible interface
  • 00:35:21
    semantics so you can do Pub sub or
  • 00:35:23
    whatever else you want it's not limited
  • 00:35:25
    to sockets
  • 00:35:28
    now I
  • 00:35:29
    claim if you do this the architecture is
  • 00:35:32
    evolvable you're
  • 00:35:34
    done you're
  • 00:35:36
    done so let me show you a picture this
  • 00:35:39
    is the picture we had before so we get
  • 00:35:42
    rid of bgp and we put an extensible and
  • 00:35:44
    Abstract interface extensible in that
  • 00:35:46
    you can add functionality abstract in
  • 00:35:48
    that it doesn't show the details of the
  • 00:35:50
    implementation it doesn't leak the
  • 00:35:52
    network information into interdomain
  • 00:35:55
    routing and so now IP is no longer
  • 00:35:58
    embedded in in domain routing you
  • 00:36:00
    replace the network API with something
  • 00:36:02
    that is sensible and
  • 00:36:03
    Abstract IP is no longer embedded in the
  • 00:36:07
    applications and now you have complete
  • 00:36:09
    freedom to change what goes on in
  • 00:36:12
    here now I know this sounds you know
  • 00:36:14
    like you know sort of typical academic
  • 00:36:16
    Voodoo but it's not I mean right now we
  • 00:36:19
    can change L2 right domains can do
  • 00:36:22
    whatever they want in L2 all this does
  • 00:36:24
    is it means everything that happens
  • 00:36:26
    between the application in domain
  • 00:36:27
    routing
  • 00:36:28
    L2 why can't why can't we change L2 and
  • 00:36:31
    not L3 it's because L3 shows up in
  • 00:36:33
    applications L2 doesn't this just means
  • 00:36:35
    everything is like
  • 00:36:37
    L2 we've had no trouble in evolving L2
  • 00:36:40
    Technologies all that says is we're
  • 00:36:42
    going to have the same Freedom if we did
  • 00:36:46
    this so the point of this aside was not
  • 00:36:50
    well it was just because I'm really
  • 00:36:52
    proud of this work and I wanted to
  • 00:36:53
    advertise it but more importantly it's
  • 00:36:55
    to show that this is the power of
  • 00:36:58
    abstraction that you take a problem that
  • 00:37:00
    lots of people have thought about for a
  • 00:37:02
    long time and rather than thinking about
  • 00:37:03
    what's the mechanism that might let me
  • 00:37:04
    do this just say what are the
  • 00:37:06
    abstractions that I need and once you
  • 00:37:08
    figure out the right abstractions often
  • 00:37:10
    you don't have to invent anything else
  • 00:37:12
    extensible and Abstract interfaces
  • 00:37:13
    that's not a new idea right this is just
  • 00:37:16
    old stuff but just recognizing where to
  • 00:37:18
    put those abstractions changes the
  • 00:37:22
    problem but the main focus here was how
  • 00:37:25
    on how to build networks not redefining
  • 00:37:26
    the internet architecture Ure so I want
  • 00:37:29
    to go back and make a few comments about
  • 00:37:30
    abstractions before I end my
  • 00:37:33
    talk so you know abstractions are not
  • 00:37:36
    academic play thingss this is not just
  • 00:37:37
    what we write textbooks about but people
  • 00:37:39
    who build real networks can ignore them
  • 00:37:42
    this completely changes where we focus
  • 00:37:43
    our attention when we build networks it
  • 00:37:46
    enables much greater functionality with
  • 00:37:48
    lower effort and in
  • 00:37:51
    particular no more designing distributed
  • 00:37:53
    control
  • 00:37:55
    protocols we're done inside of
  • 00:37:57
    interdomain routing we're stuck with bgp
  • 00:38:00
    but out inside a domain no more
  • 00:38:02
    distributed control protocols that's
  • 00:38:03
    done once you define a network operating
  • 00:38:05
    system nothing else needs to be
  • 00:38:08
    distributed so now your whole task is to
  • 00:38:11
    Define control programs over this
  • 00:38:13
    abstract model and that really is just
  • 00:38:15
    asking yourself the question if this is
  • 00:38:17
    the network I have what do I want to
  • 00:38:18
    have happen you just write that
  • 00:38:21
    function that's all about what you want
  • 00:38:23
    to have happen now not how it happens
  • 00:38:27
    that's the easiest part of the
  • 00:38:28
    networking is to figure out what you
  • 00:38:30
    want to have happen not how to make it
  • 00:38:33
    happen and so the infrastructure is now
  • 00:38:35
    in three very tractable separate pieces
  • 00:38:38
    it's building the network hypervisor
  • 00:38:40
    which which is hard but it's tractable
  • 00:38:42
    the network operating system again
  • 00:38:44
    that's not a simple task but it's
  • 00:38:45
    tractable and then building forwarding
  • 00:38:47
    elements that support whatever your
  • 00:38:49
    forwarding model is we can do those
  • 00:38:51
    three things you know because we're only
  • 00:38:54
    solving one problem at a time we're not
  • 00:38:55
    solving all three problems at a time
  • 00:38:58
    so the main point of the talk is that
  • 00:39:00
    software defined networking or split
  • 00:39:02
    architecture it's not just a better
  • 00:39:04
    mechanism it's an instantiation of the
  • 00:39:07
    fundamental abstractions that's why it's
  • 00:39:09
    right not because it beats out some
  • 00:39:11
    other mechanism but according to some
  • 00:39:12
    Metric but it captures the right
  • 00:39:15
    abstractions these abstractions were
  • 00:39:17
    needed to separate the concerns that we
  • 00:39:19
    had of the the separate problems we
  • 00:39:21
    needed to
  • 00:39:22
    solve and that the abstractions are
  • 00:39:25
    fundamental the implementation are
  • 00:39:27
    ephemeral we talk about open Flow and
  • 00:39:30
    Onyx and particular
  • 00:39:32
    instantiations I hope 10 years from now
  • 00:39:34
    we're on to something else by God I hope
  • 00:39:36
    we've got something better right but the
  • 00:39:38
    abstractions are probably going to
  • 00:39:40
    remain the
  • 00:39:41
    same so this is both familiar and
  • 00:39:44
    radical there we really didn't need any
  • 00:39:47
    new mechanisms if we replaced open Flow
  • 00:39:49
    with NLS we would be almost as
  • 00:39:51
    happy but it's radically modular you get
  • 00:39:54
    all the benefits of modular programming
  • 00:39:56
    so we can rely build much more
  • 00:39:58
    complicated functionality than we could
  • 00:40:00
    before so our task ahead is really to to
  • 00:40:03
    build these three separable pieces and
  • 00:40:06
    then worry about how to build control
  • 00:40:08
    programs over these abstract models that
  • 00:40:09
    is for the problem you're considering
  • 00:40:12
    what is the right abstract model and
  • 00:40:13
    then how do you build the hypervisor
  • 00:40:16
    that can translate that abstract model
  • 00:40:18
    into to a real physical Network that's
  • 00:40:20
    where the challenge
  • 00:40:22
    Li so in conclusion you know the future
  • 00:40:26
    of networking lives includ cleaner
  • 00:40:27
    abstractions not in defining complicated
  • 00:40:29
    distributed protocols it took operating
  • 00:40:32
    systems researchers a while to figure
  • 00:40:33
    this out first they made it work then
  • 00:40:36
    they made it simple we've now made
  • 00:40:39
    networks work and it's our time to make
  • 00:40:42
    networking a mature discipline by
  • 00:40:43
    figuring out how to extract Simplicity
  • 00:40:45
    from the sea of complexity that we're
  • 00:40:47
    currently in with that thank you and
  • 00:40:50
    questions
  • 00:40:58
    yeah Mark
  • 00:41:00
    again very very inter but I but
  • 00:41:06
    yes yeah two questions
  • 00:41:09
    okay first of all to me it sounds like
  • 00:41:11
    it's more of a
  • 00:41:13
    sck and what I mean by that is that
  • 00:41:16
    people want it to be complex and not
  • 00:41:18
    simple because if it's simple anyone
  • 00:41:20
    else can
  • 00:41:22
    do and I was just wondering what's your
  • 00:41:25
    take on that question is really how long
  • 00:41:29
    for how long can we sustain the current
  • 00:41:31
    way ofing things without actually doing
  • 00:41:34
    what you
  • 00:41:36
    propos I guess eventually we will have
  • 00:41:38
    to do so so let me um and there your
  • 00:41:43
    first question it so there really are
  • 00:41:46
    two separate debates one is the users
  • 00:41:49
    actually want a simple interface and and
  • 00:41:53
    actually Don Norman has said the
  • 00:41:55
    evidence is in and the answer is no you
  • 00:41:57
    you know if you give me a simple cell
  • 00:41:59
    phone and a complicated cell phone I'll
  • 00:42:01
    think this complicated cell phone's got
  • 00:42:02
    additional features I'm going to buy it
  • 00:42:04
    I mean it's just that time and time
  • 00:42:05
    again but do people who build these
  • 00:42:08
    things do they want simpler abstractions
  • 00:42:10
    so they can build the fancy features
  • 00:42:12
    without having to do they want the
  • 00:42:14
    Simplicity but but the end customers
  • 00:42:16
    while they say they want Simplicity they
  • 00:42:18
    never want to be left without a feature
  • 00:42:20
    but but the way you sort of architect
  • 00:42:22
    the the network you want it to be
  • 00:42:24
    simpler so you can build I mean we we
  • 00:42:26
    write modular programs and that
  • 00:42:28
    obviously has been successful because it
  • 00:42:30
    lets us build complexity while not
  • 00:42:32
    having to deal with complex features
  • 00:42:33
    without having to deal with complexity
  • 00:42:35
    all the way through um so your second
  • 00:42:37
    question is how long can we go with the
  • 00:42:40
    the current framework and ask that
  • 00:42:42
    question to the people in the world I
  • 00:42:44
    have no
  • 00:42:45
    idea did you was it oh James first yeah
  • 00:42:49
    so great talk Scott um so one thing
  • 00:42:52
    though that I I I distur me a little bit
  • 00:42:57
    like uh like the academics have given up
  • 00:42:59
    on btp and that that I find really a
  • 00:43:01
    problem because basically um btp is a
  • 00:43:04
    mixture of this fundamental mechanism
  • 00:43:06
    for doing the interdomain rout control
  • 00:43:09
    Andie involving
  • 00:43:11
    policy that pie complex P fully as
  • 00:43:14
    complicated as getting the actual
  • 00:43:16
    mechanism of the network work but it's
  • 00:43:18
    BL because there have been many studies
  • 00:43:20
    and said rexord has done some on how
  • 00:43:22
    that people can cheat on on on policy
  • 00:43:25
    assertions and I think that I would like
  • 00:43:27
    to suffer def find Nan Community to
  • 00:43:29
    think about this problem a little more
  • 00:43:30
    and not just give up and say bgp it's
  • 00:43:33
    going to be make make bgp into a brand
  • 00:43:35
    thing right so whatever comes out under
  • 00:43:37
    Dex J bdp it's still bdp but it actually
  • 00:43:40
    has these principles that you describe
  • 00:43:42
    here in interdomain so so let me respond
  • 00:43:45
    to I just came from the sigcom program
  • 00:43:48
    committee I can guarantee you we have
  • 00:43:50
    not given up on bgp the number of papers
  • 00:43:53
    on bgp it it's still exponentially
  • 00:43:56
    expanding so there been a tremend
  • 00:43:57
    there's still a tremendous amount of
  • 00:43:59
    attention paid to it I I think you you
  • 00:44:01
    you make an incredibly important point
  • 00:44:03
    which is to separate the policy model
  • 00:44:07
    from the instantiation that is currently
  • 00:44:10
    bgp and soort of figure out you know how
  • 00:44:13
    how to make this work and I think
  • 00:44:14
    actually a lot of people Jen Rexford
  • 00:44:16
    Michael shapira and uh Sharon Goldberg
  • 00:44:19
    there's a whole crowd that are really
  • 00:44:21
    trying to think deeply about this there
  • 00:44:22
    are other people who are thinking you
  • 00:44:24
    know my former student Brighton Godfrey
  • 00:44:26
    is thinking about something called
  • 00:44:27
    pathlets that actually is a different
  • 00:44:30
    way of having the same kind of policy
  • 00:44:33
    flexibility but allowing much more
  • 00:44:36
    flexible route computation and so it's a
  • 00:44:39
    you know it it's a different model but
  • 00:44:42
    it's got the same kind of policy
  • 00:44:45
    Independence that you would want and I
  • 00:44:48
    think there's an interesting dialogue
  • 00:44:50
    about uh how we might get from one to
  • 00:44:54
    the other and for instance I I I think
  • 00:44:57
    the pathet model is actually a good
  • 00:44:58
    bilateral model you could actually start
  • 00:45:00
    with that bilaterally but I think
  • 00:45:02
    there's an interesting debate to be had
  • 00:45:04
    about what's the fundamental abstraction
  • 00:45:06
    you want for interdomain routing to
  • 00:45:07
    start building on rather than there have
  • 00:45:10
    been a series of papers while bgp's got
  • 00:45:11
    this problem and if you tweet this
  • 00:45:12
    parameter and you do this to it and you
  • 00:45:14
    take a hammer and go like that then all
  • 00:45:15
    of a sudden it behaves a little
  • 00:45:16
    differently that I I you know sort of
  • 00:45:18
    isn't getting us anywhere
  • 00:45:22
    fast yeah off and on both here in
  • 00:45:25
    Ericson and at my previous employer was
  • 00:45:27
    looking at a slightly different Paradigm
  • 00:45:29
    in terms of the distribution of function
  • 00:45:32
    in that the role of a distributed
  • 00:45:34
    operating system was to provide
  • 00:45:36
    connectivity Primitives that could then
  • 00:45:38
    be
  • 00:45:39
    manipulated but the idea being that as
  • 00:45:41
    far as resilience and other things are
  • 00:45:43
    concerned you needed to be able to do
  • 00:45:47
    that minimum level of network
  • 00:45:49
    convergence with an absolute minimum of
  • 00:45:52
    transactions and that's I I understand
  • 00:45:55
    what you're saying concern is the flow
  • 00:45:59
    of information mean the flow of
  • 00:46:02
    information being too much or or or not
  • 00:46:04
    being guaranteed uh the flow of
  • 00:46:06
    information being too much such that the
  • 00:46:09
    the finite time to produce convergence
  • 00:46:12
    for critical classes of events can can
  • 00:46:14
    be extenuated because basically all
  • 00:46:16
    classes of information seem to have sort
  • 00:46:19
    of the same priority in this I can't
  • 00:46:21
    separate out the resiliency part from
  • 00:46:23
    the higher level Programming Network
  • 00:46:26
    operation
  • 00:46:27
    Network operating system aspects well H
  • 00:46:30
    so so I I think that that was getting to
  • 00:46:32
    the this comment about how I want to
  • 00:46:34
    configure it so yes when when the
  • 00:46:36
    network changes I send that state up but
  • 00:46:40
    I can always configure a low-level
  • 00:46:42
    response like backup paths that say when
  • 00:46:45
    some event happens do this so you can
  • 00:46:47
    preserve conductivity in the short term
  • 00:46:49
    while I figure out what to do in the
  • 00:46:50
    long term yeah but the other thing I
  • 00:46:52
    noticed about that and this is one of
  • 00:46:53
    the things I've been wrestling with is
  • 00:46:55
    that the whole idea up paths means that
  • 00:46:58
    the response to a network event is a
  • 00:47:00
    whole lot of independent decisions that
  • 00:47:03
    actually require an awful lot of
  • 00:47:05
    planning to make sure they don't
  • 00:47:06
    contradict each other exactly exactly
  • 00:47:10
    and that's why you want to look at the
  • 00:47:12
    network View and calculate how should
  • 00:47:15
    these backup paths be constructed so
  • 00:47:18
    that they don't interfere and they're
  • 00:47:19
    actually I mean people are working on
  • 00:47:21
    this to you know so that that you can
  • 00:47:23
    actually make rational decisions that if
  • 00:47:26
    a bunch of people do things
  • 00:47:27
    independently you still don't get into
  • 00:47:29
    trouble okay but but but I mean that but
  • 00:47:31
    but that's absolutely a problem I don't
  • 00:47:33
    think we make it any worse but we don't
  • 00:47:35
    magically solve it either have people
  • 00:47:38
    from I I'm sorry I think we want to talk
  • 00:47:41
    first we can continue after Joel here
  • 00:47:44
    Joel if I've understood you right it was
  • 00:47:46
    an interesting Talk part of what you
  • 00:47:49
    said that was particularly powerful is
  • 00:47:51
    that at an abstraction level you want to
  • 00:47:53
    separate the abstraction for talking
  • 00:47:55
    about forwarding from the exraction
  • 00:47:57
    talking about Network control forgetting
  • 00:47:59
    how you represent those that forgetting
  • 00:48:01
    What machines they're on or anything
  • 00:48:03
    else that you want to talk about them as
  • 00:48:04
    separate abstraction that's very
  • 00:48:07
    colorful and if I look back at some of
  • 00:48:09
    the history of programming and operating
  • 00:48:11
    systems I can see where similar things
  • 00:48:14
    happen but there's a step that I think
  • 00:48:17
    maybe you slid past because it's a
  • 00:48:20
    complicated but I want to ask you to
  • 00:48:21
    look at it for a minute if we're going
  • 00:48:23
    to do that we have to have abstraction
  • 00:48:25
    to talk about things to talk about what
  • 00:48:28
    the pieces the elements of forwarding
  • 00:48:30
    are to talk about what the components of
  • 00:48:33
    of control processing are at the moment
  • 00:48:35
    we have a couple of candidates for
  • 00:48:37
    forwarding longest prefix match which is
  • 00:48:39
    clearly wrong maybe flows that seems to
  • 00:48:43
    be too detail specific maybe something
  • 00:48:46
    else that I don't know what we don't
  • 00:48:47
    seem to be talking about what is the
  • 00:48:49
    right abstraction for we get to network
  • 00:48:53
    control we tend to talk about it in
  • 00:48:54
    terms of Cisco C what everybody uses
  • 00:48:57
    which is clearly completely the wrong
  • 00:49:01
    abstraction we don't have any
  • 00:49:03
    abstractions for talking
  • 00:49:05
    about
  • 00:49:07
    too use but I think that's probably too
  • 00:49:10
    specif for what you are getting at and
  • 00:49:13
    so is there any way to get out what are
  • 00:49:15
    the right abstractions for this so we
  • 00:49:17
    can build up tools the right way
  • 00:49:22
    no I know I I mean I mean when I listen
  • 00:49:25
    to Barbara lisof talk what what struck
  • 00:49:28
    me was she groped her way to what she
  • 00:49:33
    finally put forward is the right
  • 00:49:36
    abstraction but the reasoning process
  • 00:49:39
    behind it was not pretty or or linear
  • 00:49:42
    and I I don't think we're going to do
  • 00:49:44
    any better um I mean I I I I wish I had
  • 00:49:48
    a better answer but I think it's sort of
  • 00:49:51
    you know you you know that you know you
  • 00:49:54
    have an interface right when people the
  • 00:49:56
    the level of PLS go down but but you
  • 00:49:58
    know that that that's the proof of
  • 00:50:02
    correctness thank thank you for very
  • 00:50:06
    interesting I I like to touch on similar
  • 00:50:09
    point but from a different angle brought
  • 00:50:11
    up specifically your point
  • 00:50:15
    Global I'm taking this further your
  • 00:50:18
    Concept in terms ofp netal Network now
  • 00:50:22
    the network generally is aive so it's
  • 00:50:24
    changing all the time and to have a
  • 00:50:27
    global view is not a static it means the
  • 00:50:31
    operator continually has to update these
  • 00:50:34
    table and that is dangerous in a way
  • 00:50:37
    because the information could get wrong
  • 00:50:38
    it could take longer to be uploaded and
  • 00:50:41
    so on so how how do you see that in
  • 00:50:43
    terms of you know updating the
  • 00:50:45
    information in order to have a correct
  • 00:50:48
    Global Network okay so I was hoping that
  • 00:50:51
    Boulder was going to stay under the rug
  • 00:50:53
    but um right so the the story I gave
  • 00:50:57
    was you have state The View and you
  • 00:51:01
    decide on a configuration now that's a
  • 00:51:05
    very clean story because you have no
  • 00:51:06
    history dependence whatsoever clearly if
  • 00:51:09
    you have rapidly Changing State you want
  • 00:51:11
    to put some damping in the response so
  • 00:51:14
    that you are not sort of you know every
  • 00:51:16
    time this changes you do that and you
  • 00:51:18
    know the the the global equivalent rout
  • 00:51:20
    flap damping but but something where you
  • 00:51:22
    sort of have you don't have this
  • 00:51:25
    knee-jerk connection between a change in
  • 00:51:27
    state and a change in configuration so
  • 00:51:28
    you can hopefully reduce the amount of
  • 00:51:31
    the the number of configuration changes
  • 00:51:33
    it's not linear because for optical
  • 00:51:36
    Network for example using optical
  • 00:51:38
    wavelength is not linear it's completely
  • 00:51:41
    nonlinear because you might have all
  • 00:51:43
    these Optical uh impairment with
  • 00:51:46
    changing from One path to another that's
  • 00:51:49
    the issue so it's very you know it's
  • 00:51:51
    very accompass some fast to generate A
  • 00:51:55
    New Path or a new
  • 00:51:57
    uh let's say secondary part for the main
  • 00:52:00
    no no so so I think I'm agreeing with
  • 00:52:01
    you which which is you don't want to
  • 00:52:03
    have this kind of every time there's any
  • 00:52:05
    change you completely recompute you want
  • 00:52:08
    to think carefully about the frequent or
  • 00:52:11
    the common state changes and sort of
  • 00:52:14
    figure out what kind of changes you want
  • 00:52:16
    to instantiate so whether that means
  • 00:52:18
    that you figure out what's in uh sort of
  • 00:52:21
    a nonoptimal but incremental update when
  • 00:52:24
    something happens and I think that's
  • 00:52:25
    going to be technology
  • 00:52:27
    specific and so I I think Optical in
  • 00:52:29
    particular would going to require its
  • 00:52:30
    own sort of change there
  • 00:53:05
    ah so um let let me start with the
  • 00:53:08
    second question that the convergent
  • 00:53:11
    properties of doing routing this way are
  • 00:53:13
    really no worse think what I described
  • 00:53:15
    is essentially OPF you know you get the
  • 00:53:18
    state you bring it up you look at a
  • 00:53:20
    graph and you push it down but it's OPF
  • 00:53:22
    where the distribution model is under
  • 00:53:24
    your control rather than the
  • 00:53:25
    distribution going to every switch you
  • 00:53:27
    sort of go to a replicated set of
  • 00:53:30
    controllers and they push it back out so
  • 00:53:32
    I don't think the convergence gets any
  • 00:53:34
    worse than you know OPF convergence
  • 00:53:37
    which you know for better or worse but
  • 00:53:39
    but we're familiar with it um the
  • 00:53:42
    flexible route computation there I mean
  • 00:53:45
    I I have in mind a very spe I I this
  • 00:53:48
    pathet design has a very specific notion
  • 00:53:50
    of it I'm not saying that that's that
  • 00:53:52
    this is an example of what it might mean
  • 00:53:54
    which is the way you specify policies
  • 00:53:56
    there is rather than getting in a route
  • 00:53:59
    and sort of computing it and only
  • 00:54:00
    advertising certain routes you advertise
  • 00:54:02
    policy compliant route fragments you say
  • 00:54:06
    this is a aout a path fragment that I'm
  • 00:54:08
    willing to
  • 00:54:09
    support and if I only have nearest
  • 00:54:11
    neighbor policies that that's easy if I
  • 00:54:13
    have complicated policies it it's
  • 00:54:16
    longer once you have that any end system
  • 00:54:19
    can take a bunch of these pathlets and
  • 00:54:21
    construct them any way they want to and
  • 00:54:22
    they are guaranteed to have a policy
  • 00:54:25
    compliant path and so that's a way of
  • 00:54:27
    having policy compliant Source routing
  • 00:54:30
    in in a very scalable way that's a
  • 00:54:33
    particular instantiation of it but that
  • 00:54:35
    but but the the goal is to say if you
  • 00:54:38
    don't have flexible route computation
  • 00:54:40
    then you don't have an extensible
  • 00:54:42
    interdomain routing interface and then
  • 00:54:44
    you're probably going to have to change
  • 00:54:45
    the interface and so that the need for
  • 00:54:47
    flexible route computation comes from
  • 00:54:49
    saying we want to be able to define the
  • 00:54:51
    substraction once and leave it there and
  • 00:54:53
    if it's not flexible then we know we're
  • 00:54:54
    going to have to change it and that's
  • 00:54:55
    really hard
  • 00:54:57
    so so I mean so I'm not claiming the
  • 00:54:59
    mechanism is the right mechanism I'm
  • 00:55:00
    saying that the need is is sort of
  • 00:55:04
    fundamental one more
  • 00:55:21
    question conge and it easier and
  • 00:55:30
    com so so I I would
  • 00:55:33
    say so the there two separate pieces of
  • 00:55:36
    my talk there were the the bulk of it
  • 00:55:38
    was about software defined networking
  • 00:55:40
    and I would say that's pretty orthogonal
  • 00:55:42
    to
  • 00:55:43
    IPv6 that the the kinds of control
  • 00:55:45
    mechanisms that we're talking
  • 00:55:47
    about IPv6 is you know sort of its
  • 00:55:51
    advantages and disadvantages are rather
  • 00:55:53
    orthogonal the internet architecture
  • 00:55:55
    stuff I talked about IPv6 would become
  • 00:55:58
    another L2
  • 00:55:59
    technology meaning you're not using in
  • 00:56:02
    that design you're using domain names as
  • 00:56:04
    interdomain addressing and IP addresses
  • 00:56:08
    as internal addressing and so I my
  • 00:56:11
    domain can use IPv6 your domain can use
  • 00:56:13
    ipv 17 and we don't care just like with
  • 00:56:16
    L2
  • 00:56:19
    addresses I have a question as well
  • 00:56:21
    before I let you go sure so software
  • 00:56:23
    Define networking as I mean assuming
  • 00:56:26
    that you can solve all these
  • 00:56:27
    abstractions and all these interface and
  • 00:56:29
    have a problems with that it seem to be
  • 00:56:30
    very um attractive for data centers I
  • 00:56:33
    mean that's the players that are and I
  • 00:56:35
    guess one reason is that they they can
  • 00:56:37
    build their network from scratch and
  • 00:56:38
    then turn it on uh whereas we live in a
  • 00:56:41
    world where we have to S of inject this
  • 00:56:43
    slowly somehow so how can we have this
  • 00:56:45
    work how do we inject SD end in existing
  • 00:56:48
    networks if it at
  • 00:56:54
    all that's a really good question
  • 00:56:57
    I don't know I I mean I I I I it would
  • 00:57:00
    be great to discuss it with you guys but
  • 00:57:01
    I mean how how you would do that
  • 00:57:03
    incrementally within a very large wh I
  • 00:57:07
    don't know all right well that's good to
  • 00:57:08
    have some questions that the professor
  • 00:57:10
    don't have answers to thank you very
  • 00:57:12
    much Scott I think uh another hand for
  • 00:57:16
    Scott excellent sck thank you very much
Tags
  • Software Defined Networking
  • Networking Abstractions
  • Complexity
  • Modular Programming
  • Network Architecture
  • Interdomain Routing
  • Control Plane
  • Data Plane
  • Network Operating System
  • Future of Networking