1 / 26

Operators and the IETF

Operators and the IETF. RIPE Days Kiev. The IETF. The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. [ RFC 3935 ]. The Dream. In a perfect world

airell
Download Presentation

Operators and the IETF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Operators andthe IETF RIPE Days Kiev

  2. The IETF The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. [RFC 3935]

  3. The Dream In a perfect world The IETF creates standard protocols with operator input and they work great Deployment and operationalization concerns are consistently addressed The level of operator engagement makes sense when compared to vendor and academic involvement Operators always know when their input is needed Operators always provide their input when it’s needed

  4. The Reality Many operators are not engaged enough A significant portion of operators (particularly mid/small size) don’t join IETF mailing lists nor do they show up to IETF meetings Academics and vendors rule many decision making processes within the IETF The operators expected to deploy these technologies often don’t even know that they are being developed Critical new technologies are being developed with little to no direct operator input Things may be and often are broken.

  5. The IETF A closed off group of engineers disconnected from the reality. In fact it is a group of engineers having not enough exposure to operational reality. That is a problem. Operator participation in the IETF is below 10%. This frequently leads to situations when IETF developed solutions do not get traction in the field or field develops alternatives to IETF solutions. IETF is open for receiving feedback. IETF is open for operators to participate. There is a perception of vendor dominance in the IETF – and there is much truth in that. However it should not scare you off from participating there. Overall IETF is a friendly environment – there may be exceptions. There is an Ombudsteam for dealing with those exceptions.

  6. Network Operations Lifecycle

  7. Structure of the IETF • Specific topics are being discussed in working groups. Around 120 WGs active at the moment. • Logically close working groups are combined together into areas. • Areas:GEN, RTG, TSV, INT, SEC, ART, OPS. • 3 physical meetings per year, next one is in Singaporein two months. ~1200 attendees. Multiple virtual meetings for specific WGs between physical meetings. • Actual work gets done on the mailing lists in between the meetings. • Document lifecycle. • Consensus.

  8. GEN – General Area • General administrative aspects. • MTGVENUE While may not be seen as important or relevant, in fact it is important and relevant. Imagine 1200 nerds left without cookies and coffee during the breaks between the meetings.

  9. RTG – Routing Area • Gluing the loopbacks together. • LSR • IDR, SIDR, BESS • BIER, PIM, (MBONED) • MPLS, PALS, CCAMP, SPRING, TEAS, PCE, SFC • NVO3, TRILL, LSVR, RIFT • I2RS • DETNET • ROLL, MANET OSPF got acquired by ISIS (or vice versa) BIER is a new multicast forwarding dataplane mechanism Large portion of new developments in routing are related to data center space

  10. TSV – Transport Area • Payload encapsulation. • QUIC, TAPS • TCPM, TCPINC, MPTCP QUIC is the most visible and impactful development – also impactful to the operations community.

  11. INT – Internet Area • IPv6 lives here. • 6MAN, SUNSET4 • 6LO, LPWAN, 6TISCH • NTP, TICTOC • HOMENET • DHC

  12. SEC – Security Area • We all can feel secure now. • TLS • IPSECME • DOTS TLS 1.3 is about to be finalized. Effects of encryption document has been getting to rough consensus.

  13. ART – Applications and Realtime Area • The network as users see it. • CBOR • CORE • RTCWEB • HTTPBIS • DOH

  14. OPS – Operations and Management Area • Yes, IETF does operations too (that was a joke). • V6OPS • GROW, SIDROPS • NETMOD, NETCONF • ANIMA • DIME, RADEXT, OPSAWG OPS area does not (typically) work on protocols, instead it works on best current practices and recommendations.

  15. BGP in the IETF • BGP related development does not happen in one place. You need to know where to look for specific aspects. • IDR – base protocol except of BGPsec • SIDR – BGPsec and RPKI architecture and protocol mechanics • GROW – BGP deployment except of BGPsec • SIDROPS – BGPsecand RPKI deployment • BESS – BGP as a building block for various services on top (EVPN) • RTGWG – BGP-related but not BGP-specific aspects (routing policy model) • OPSAWG – various use cases for BGP constructs (communities)

  16. Interesting developments in IDR • BGP SPF. • Extended messages. • OPEN policy. • Flowspec maintenance (IPv6), indirect redirects. • Route Server BFD bootstrap. • BGP automesh, automatic session establishment. BGP SPF and BGP LS mechanisms got intermixed and resulted in a separate WG – LSVR.

  17. Interesting developments in NVO3 • Geneve as Proposed Standard. • VXLAN-GPEand GUE as Informational. • EVPN as an option of NVO3 control plane. VXLAN is not a deliverable of NVO3 WG. VXLAN has significant limitations and new deployments should carefully consider whether it is a suitable option in a longer term.

  18. Interesting developments in NETMOD • YANG model catalog and YANG module for YANG model catalog. • YANG model metadata, revisions, versioning. • Protocol specific work is happening in protocol specific WGs. • Revised Datastores - NMDA Open questions to address – the split between IETF and Openconfig modelling paradigms.

  19. Interesting developments in OPSAWG • CASM – coordinated address space management • TACACS maintenance • Telemetry of all flavors • Network Slicing and derivatives TACACS protocol specification is 20 years old. Current protocol does not withstand any modern security critics.

  20. Interesting developments in L2SM • Service model – a model that controls element level models • How to describe L2VPN service • Experiment continued from L3SM – which was a good learning experience that IETF does not necessary have enough operational expertise inhouse.

  21. Discussion topics – BGP Communities • Communities are used and abused for carrying various types of information that may or may not belong to BGP. • BGP as the universal signalling protocol. • Standard • Extended • Large • There is a need to have AS4 clean extcomm equivalent for L3VPN RTs. EVPN is not fully AS4 clean. There appears to be a need for more fine grained control of propagation scope. • Do we need another type of BGP communities? If yes, how they could look like?

  22. Discussion topics – Control Plane Security TCP MD5 authentication is broken. TCP-AO has been around for over a decade. There are no practical implementations. Keyed MD5 has a few implementations. Do we care about control plane security? KARP WG eventually shut down due to lack of energy.

  23. Discussion topics – Network OAM • The network works, that is fine. Can we characterize how well does it work? If something is not right, can we point to the exact place where things are broken? • Passive • Active • Hybrid • IOAM – In-situ OAM • Continuity Check • Connectivity Verification • Performance Management

  24. Discussion topics – Network Slicing • Partitioning of network resources – both link resources and node resources. • TDM-style hard resource guaranteed sub-channels • Dedicated node resources – lookup, fabric, buffering • Coordination of resource reservation • Management of network slicing. • In essence network slicing is a broader concept of VPN or network virtualization, expanded to cover entities that provide other than network-only functions. It is not a new concept as such. It is a new fancy hype name though.

  25. Summary & discussion • IETF does mostly protocol work, not end to end architecture work. • Vendor implementations may and do diverge from IETF specifications. • IETF does not have enough operational representation in its community. • Missing or suboptimal functionality can be added in or fixed, it just needs to be communicated. The louder you shout the bigger the chance is of IETF community hearing that. • IETF is open for operators to voice their concerns and wishes.

  26. What next? Talk to us: Just after this session outside. Or at any other time. About: Specific drafts you have concerns about or issues with Other introductions with the authors or IETF participants Something like a BoF / Track at upcoming RIPE events Anything else related to the IETF

More Related