Re: RtgDir review: draft-rtg-dt-encap-02

[Erik Nordmark <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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