John Scudder has entered the following ballot position for draft-ietf-spring-nsh-sr-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this clean, easy-to-review document. I do have one point I'd like to flag. I'm making this a DISCUSS to ensure the IESG has a chance to discuss the point raised, and intend to clear after the telechat. In his review (https://datatracker.ietf.org/doc/review-ietf-spring-nsh-sr-11-rtgdir-lc-bryant-2022-05-28/) Stewart Bryant makes a good point: ``` There is one point that the IESG should ponder. The authors have asked for a IP type assignment. This is a limited registry that needs to last the lifetime of the IP protocol suite. NSH started its life 9 years ago and has been a standard for 4 years and in all this time has not needed such as allocation. Neither SRv6 nor NSH are petite or lightweight protocols. So I wonder if the identification of NSH should happen at the IP layer as proposed, or whether an intermediate multiplexing layer such as UDP should be used? The extra processing for UDP is one test and the extra MTU is 8 octets. The decision for the IESG is whether in their view the extent of deployment and the gain in performance is such that they should authorise the allocation of the IP type. ``` AFAICT the argument against using a UDP encap is "it's more overhead" (which is true, but I think Stewart's point is that the UDP overhead is pretty small as a fraction of the SRv6 and NSH overheads). Anyway, it seems like it would be good to at least consider this question. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Related to the DISCUSS question, it seems as though a few words would be in order, early in the document, about the encapsulation. I do see (now that Jim pointed it out to me OOB :-) that Section 11.1 requests an IP protocol number from IANA, and the rest is arguably "obvious". Nonetheless, it seems worth a few sentences. Obviously, if Stewart's suggestion to move to a UDP encap were used, that would also call for a few sentences to describe it. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
