I am sure most of you would have heard by now that IIESoc have been working behind the scenes for "Connections 2018" - a Pre-IETF 103 forum in bangalore on October 31st - Novemeber 1st 2018, to get protocol developers, academicians and network operators together on the same platform to discuss the latest problems facing the internet and the solutions relevant to them. This is being done with a focus on India and Indian contributions to the Internet.
This blog is part of the speaker series that introduces the various amazing speakers that are part of the event. First in the series is Adrian Farrel.
Bio: Adrian Farrel is an innovator and standards-maker in Internet technologies working within the Internet Engineering Task Force (IETF) where he has participated in the development of Multiprotocol Label Switching (MPLS), Generalized MPLS (GMPLS), Path Computation Element (PCE), and various Software Defined Networking (SDN) technologies. He served as one of two IETF Routing Area Directors for six years, and now chairs the Layer 2 VPN Service Model (L2SM) working group. He is the co-author of over 70 RFCs, currently serves as the Independent Submissions RFC Editor, and has written, edited, or contributed to seven books on Internet technologies and three books of fairy stories.
Talk: Service Function Chaining
An emerging function in the provision of services in IP-enabled networks is Service Function Chaining (SFC). This talk will look at the motivation for SFC with special focus on its deployment in data centres, and then will describe the architecture developed by the IETF's SFC working group. We will examine the different functional components of an SFC system and how they are combined to direct traffic off its normal path s that it can be acted on by service functions hosted at different places in the network.
The SFC working group has developed a protocol-independent encapsulation called the Network Service Header (NSH). The NSH allows packets to be marked according to the service functions that they must traverse, and can be applied to any payload and with any transport protocol. But two alternate approaches have been suggested in the MPLS and SPRING working groups to achieve the same function as the NSH in existing forwarding systems using either MPLS or Segment Routing encapsulations, thus allowing legacy routers to participate in SFC. Furthermore, there is a proposal to achieve SFC by extensions to L3VPN techniques being progressed by the BESS working group.
Lastly we will consider the control and management necessary for SFC. We will look at approaches for central control using an SDN-based central controller, BGP southbound instructions, or distributed BGP information exchange.
Checkout other talks at - https://www.connections.iiesoc.in/abstract
We also asked Adrian a few questions regarding his IETF contributions and involvement.
1. How did you get involved in the IETF? Was there a particular issue that led to your involvement? I was working for British software house, Data Connection, and we were looking for the next thing in communications having just completed a suite of ATM products. MPLS was rearing its head and I started to read the Internet-Drafts that existed to try to work out what we could implement. Pretty soon I had some questions for the authors and also a pile of editorial suggestions and clarifications that I offered up on the mailing list.
My first IETF meeting was IETF-40 held in Washington DC in December 1997. A remarkable meeting where the MPLS working group filled all the chairs and people sat on the floor in the gangways and all around the front of the room. I distinguished myself at that meeting by wearing a tie - it hadn't occurred to me to read any background information!
2. What is your opinion on the importance of the IETF in the Internet eco-system?
The IETF is *the* standards body for the Internet. Of course, the same work could be done by any standards body, but the IETF has the experience and knowledge-base which is incredibly important as the "why" and "how" of the Internet is crucial for successful extension and development. I also think that the way the IETF works with direct collaboration between engineers and open access to all our work and standards underlies the strength of the Internet.
3. What technical changes do you see coming in the next few years?
All of the obvious things like a continued growth in traffic, the move of more and more things to a distributed cloud, a significant increase in the number of people who can access the Internet, a massive rise in the number of attached devices, and application demands for higher quality of service. But what is interesting to me about these things is how they will change the core assumptions about how the Internet is built.
Obviously we are finally seeing a big swing towards IPv6, and security and privacy have been recognised as crucial elements of tomorrow's Internet. There are also some fundamental shifts in how the plumbing of the Internet works, with changes to forwarding and routing for service function chaining, segment routing, and data centre operation getting a lot of attention in the IETF. I also anticipate pressure to make the IP layer more deterministic to address the needs of future applications (including those introduced by 5G), and this will challenge both the protocols and the architecture of the Internet.
4. What are some of the most interesting changes you have seen at the IETF? When I started work in the IETF it was predominantly attended by North Americans and Europeans. Now, while preserving a lot of that culture, it is opening up to participation from other regions, especially Asia. I see this as critically important to the future of the organisation because so much of the innovation in the Internet today comes from there. Additionally, the way that networks are built in countries that are seeing huge growth in subscribers is very different to the legacy networks deployed in Europe or the USA.
We are also seeing a resurgence in remote working. That is actually how things should be because it means that the Internet is delivering on its potential. Thus, attendance at face-to-face meetings has been declining, but there is a dramatic increase in the number of people who participate at those meetings remotely whether on their own or via a hub. This will prove a challenge for the IETF financially, but my biggest concern is that missing out on physical attendance means losing out on the hugely valuable side meetings and corridor conversations that are actually how work progresses best. I hope that IETF hubs and periodic regional gatherings can help to mitigate this, and I'm the IETF will evolve to incorporate this new way of working.
5. What would be your advice for a new-comer from the sub-continent, on how to get involved?
It's the same for everyone, and please believe me that I too started off not knowing how to participate or how to find a way in to what looks like a pretty closed organisation.
The secret is in the word collaboration. Don't look to make a big impact or make a world-changing contribution on day one, but do look to see how you can help other people do their work.
So, for example, if you have read a draft for your day job, give feedback and make suggestions. If something isn't clear to you, say so: if you managed to work it out after a while, then maybe you can suggest some additional text that would help future readers. If something is broken or suboptimal, discuss it without trying to make anyone look stupid or wrong. And if you spot some typos, point them out. Obviously (?), make all of your communications polite and even humble, but don't be afraid to speak up on the mailing lists. In fact, most document authors are incredibly grateful that you have read their work, the fact that you go on to comment about it in a positive way and actually help to make it better is a complete delight to them. A document is the author's baby: they want to hear you say it is beautiful, they want you to help wipe its nose, and they want you to tell everyone (on a public mailing list) how clever it is.
If you have a new idea then write it up as a draft. But don't try to make it complete and perfect: recall that this is an engineering organisation, not an academic journal. Try your hardest to find people to collaborate with. Maybe you can see people with similar interests on the mailing list; maybe you have customers or suppliers; or maybe just ask on the mailing list for help.
Dont miss this oppurtunity to join us for the event. The tickets for the event are availaible at - https://www.connections.iiesoc.in/tickets