> On Thu, Jul 17, 2014 at 6:27 AM, Ken Gray (kegray) <[email protected]> wrote: >> Where Dino and I agree, and not to pick on Uri - I've seen the statement >> "additional headers/metadata" a few times now and it STILL sounds like >> "work around SFC", particularly in respect to the metadata part (since >> passing metadata was one of SFC's points). >> >> If you want to tilt at that windmill, I don't think that binding the >> solution to a particular transport encap is the optimal way to do it (if >> you can avoid doing so). >> > By this line of thinking TCP options should be moved to extension > headers. If the meta data is part of the transport protocol and needed > for its operation then it's should be within the transport header not > buried at some other place in the packet. There's already a lot of > precedent for this in IETF protocols and we had more than thirty years > of operational experience dealing with optional data in several core > protocols. I really don't see that the encapsulation protocol case is > so unique that a new model needs to be adopted.
Well stated and 100% agree. Dino _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
