Erik, Sorry for the latency - this got buried because i wasnt on the cc so my filters gave it low prio.
On Mon, Jul 6, 2015 at 1:17 PM, Erik Nordmark <[email protected]> wrote: > On 6/30/15 2:20 PM, Jamal Hadi Salim wrote: > [..] > The design team tried to stay away from potentially contentions discussion > by putting firm recommendations in place. Thus currently the document is > more of "things to think about" and some tradeoffs, and less of > recommendations (and no requirements). > > Alia has asked for more of a list of choices for the protocol designers, > and this is definitely something which folks can help with as we continue > this work in the RTGWG. But I also think we need to let the specific > in-flight WGs (NVO3, SFC, and BIER) use this document as input but figure > out their own tradeoffs and answers. > Generally the message was as you described. I probably should have used the term "guidelines" instead of "recommendations". I was looking for guidelines and i sometimes didnt grok them. I liked some of the format in section 18. It provides context ("Here's what a NIC does for TSO") and then provides guidelines ("optional protocol fields should not contain values that must be updated on a per segment basis .."). I realize that this specific example is closer to implementation details - which may change (or get obsolete) over time but it serves as a good example of what i was trying to say. I also realize this may be hard to keep consistent across the document - so take it as input of where it may make sense to use such formatting. 6. Terminology >> >> The capitalized keyword MUST is used as defined in >> http://en.wikipedia.org/wiki/Julmust >> >> Missing the context on what looks like a high calorie delicious drink. >> and should that be https?;-> >> >> > Since you are the first to discover the lack of https in that URL, you get > a free beverage of your choice (in the bar in Prague if you will be there). > > I will be there. I suspect they dont have Julmust ;-> > >> > o In the case of IP transport use >=14 bits of UDP source port, plus >> outer IPv6 flowid for entropy. >> >> Looks like a typo. <=14 bits? >> >> No; 14 or 16 depending on the environment. I'll reword as such. > > Ok. Re-reading the first 2-3 paragraphs in section 7 do present the context well. >> > Many Internet protocols use fixed values (typically managed by the >> IANA function) for their next-protocol field. That facilitates >> interpretation of packets by middleboxes and e.g., for debugging >> purposes, but might make the protocol evolution inflexible. Our >> collective experience with MPLS shows an alternative where the label >> can be viewed as an index to a table containing processing >> instructions and the table content can be managed in different ways. >> Would it not be useful to provide a reference here? Just reading this >> has questions popping for me - who populates this tag-indexed table of >> instructions and could interop be impacted? >> >> The DT added the above text based on comments at the mike from Stewart > Bryant. I don't know if there is any reference for the general concept. > Anybody else know? > > In general this implies some control-plane mechanism to populate the table. > Maybe an addendum to describe that the control-plane or some human would administer this would be useful. > >> Is there a reference to work which says quiet periods (which i am >> implicitly >> reading that in the text above) can be used to change the hash selection? >> I would think that one needs to closely observe packet trends to make >> such a decision. So please provide some ref to some scholarly or >> engineering work. >> > I don't know of citations to such work; perhaps my co-authors have some. > I recall reading about using markers, but that was a long time ago. > It would help i think to have some reference. I am not sure if this applies: http://simula.stanford.edu/~alizade/papers/conga-sigcomm14.pdf cheers, jamal
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
