Hi Stefano, We agree on the overarching point, which is that the statement isn’t clear as written.
I take your point about reading it in the context of SRv6 Network Programming, and I would absolutely agree that it’s right to talk about “the Network Programming paradigm”, but right now I don’t see this paradigm as defining “a data plane” in a useful sense. I won’t go into greater detail on this right now since it may represent a serious tangent and might not end up being relevant depending on how the authors (and WG if the document is adopted) decide to address the concern. Thanks for your helpful reply, —John On Oct 13, 2021, at 7:53 PM, Stefano Salsano <stefano.sals...@uniroma2.it<mailto:stefano.sals...@uniroma2.it>> wrote: Hi John, I agree that the statement "this solution does not require any SRH data plane change" needs to be clarified, also because there is no formal definition of a "data plane", hence it is even more vague the "SRH data plane". My understanding of "SRH data plane" here is the combination of RFC 8754 AND RFC 8986 (SRv6 Network Programming). The second sentence in the draft says: "SRv6 Network Programming [RFC8986] defines a framework to build a network program with topological and service segments carried in a Segment Routing header (SRH) [RFC8754]." So I think the context of the draft is SRv6 Network programming... in this context the basic idea is that you can add new features (i.e. new instructions) in specific nodes and add the "network program" in the packet header so that you know in advance which nodes will execute which instructions. In this way you can include in your network a mix of "legacy" RFC 8754 nodes (that do not need to implement the new features) and nodes that support the new features (e.g. the CSID flavours). I think this gives a reasonable interpretaion of "does not require any SRH data plane change"... though I agree it could be better explained ciao Stefano
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
