[Int-area] RTG Dir QA review of draft-ietf-nvo3-gue - TSVWG coordination

["Black, David" <[e-mail]>]

[+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