Hi Nick, > CRH looks interesting from a technical point of view.
Can you enumerate what you find interesting in it ? For me the fundamental drawback of MPLS or SR-MPLS is requirement mapping. CRH falls in the same bucket - requires yet one more mapping abstraction. I have proven with the referenced IP-TE + NP document that you can do path engineering without any mapping. In fact even without any change to IPv6 protocol. So what are those technical merits - 16 or 32 bit SIDs ? One size fit all again ? What is the delta against SR-MPLS technically speaking ? Note that nothing prevents you to run MPLS over IP if that is the issue. Best, R. On Fri, May 15, 2020 at 6:21 PM Nick Hilliard <n...@foobar.org> wrote: > Zafar Ali (zali) wrote on 15/05/2020 13:53: > > It is clear to all that the current draft and adoption request is an > > attempt to circumvent the standard practice. > > Zafar, > > Speaking as an unaffiliated operator who runs kit from plenty of > vendors, CRH looks interesting from a technical point of view. > > Juniper seems to be claiming running code, so it would be a more > productive use of working group time if we concentrated on rough > consensus on the technical merits rather than getting side-tracked with > procedural distractions. > > Nick > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
