On 7/13/15 1:52 PM, Jamal Hadi Salim wrote:
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]
<mailto:[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.
I just realized the subject line saying draft-rtg-dt-encap-02. We did
add some bullets at the end of most sections in
draft-ietf-rtgwg-dt-encap-00.
I don't know if those help, but hopefully they can serve as a prompt for
getting even more concrete guidelines.
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.
Let me ask for volunteers to craft some text tomorrow.
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
<http://simula.stanford.edu/%7Ealizade/papers/conga-sigcomm14.pdf>
Let me have a look.
Thanks again,
Erik
cheers,
jamal
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
