On this Packet Pushers Priority Queue episode, we chat with Cisco’s Jim Guichard & Paul Quinn about the topic of Network Service Header (NSH). What is NSH meant to be? What might we use NSH for? What will it take to make NSH a widely adopted reality? This is a follow up to Show 238, where Greg was not feeling the NSH magic. The plan was to show Greg the light. Did Jim & Paul succeed?
What We Discuss
Jim and Paul share…
- How we ended up here.
- Quick IETF update.
- SFC WG.
- Drafts, adoptions, etc.
- Update from last IETF: initial testing.
- Services today.
- Coupled to topology for insertion AND policy.
- This worked (kinda) but things are changing: “cloud” and “SDN.”
- Physical and virtual.
Greg asks a series of hard questions about NSH, including…
- Why is it necessary to use in-band signalling by injecting a tag into packet? This approach requires several layers of complexity.
- The concept of using tags/labels header appears to perpetuate a vision of device-centricity instead of service delivery. There are many other companies using flow states in devices to build NFV service chains. What makes NSH more compelling that direct operation on flow states?
- The network service header is used to create the service plane – but so do SDN applications. This provides traffic steering capabilities AND metadata passing – I would use an API for this. Why embed data into every packet and make devices monitor that state?
- NSH provides path identification, loop detection, service hop awareness,and service specific OAM capabilities – why ? To create distributed, non-specific, incoherent service models that achieve eventual consistency? What is the value of replicating legacy service networking models for a future software only service graph that has a tenuous (at best) link to 40 year old networking architecture?