[+tsvwg - this draft is undergoing a WG adoption call to move it from nvo3 to intarea]
Commenting on just the TSVWG coordination concerns, as a TSVWG co-chair. Legend: > > Adrian Farrel (RTG Dir reviewer) > Tom Herbert (GUE draft author) David Black (TSVWG co-chair) > > It seems to me that there is some careful coordination needed with other > > work on encapsulation of transport or network protocols in UDP. This > > idea clearly has value in NVO3, but I should have thought it sat better > > in the TSVWG. I hope the NVO3 chairs have discussed this with the TSVWG > > chairs to ensure that there is no friction. This is particularly > > important because it will be important to recognise that only one of > > this draft and draft-manner-tsvwg-gut is likely to make it to RFC. > > > Much of the content around TSV issues (e.g. zero UDP6 checksum and > congestion control) is based on that in MPLS/UDP and GRE/UDP. And those are the two most relevant documents to work from. GRE/UDP needs a little more tweaking before RFC publication is requested. Specifically, I need to supply some improved congestion control text to the authors - doing that is on my "round tuit" list. > > You seem to have correctly addressed the three issues that have most > > worried the TSVWG (checksum, congestion and security), so that is all > > good, but I would recommend getting the TSVWG involved for a full and > > detailed review now and for each future revision of the document. In > > fact, I would have tended towards making this a TSVWG document, but so > > long as the chairs, the ADs, and the WGs are happy, that should be fine. > > > > --- > > > > Overall, this work is a good idea and needed. When we did MPLS-in-UDP > > there was a background proposal to generalise and only burn one port > > number for al UDP encapsulations. This achieves that end. > > > > However, I think this proposal may be too general and too extensible. > > Future-proof is good, but there seem to be a lot of bells and whistles > > defined here that have no specific use proposed, and no indication that > > a future use might ever be defined. I think it is one thing that it > > should be possible to extend a protocol, and another that it defines > > multiple fields and extension mechanisms that might never be used. > > > Yes, two of the authors on this draft are also authors for GRE/UDP. > GRE/UDP has received excellent review in TSVWG and we would like to > have similar review of GUE. That will definitely happen ;-). My preference is for encapsulation header design to be done in WGs that work on encapsulations - TSVWG is not such a WG, but is more than happy to advise on Transport concerns, such as those identified above. Thanks, --David _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
