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

Erik Nordmark <nordmark@acm.org> Tue, 21 July 2015 15:23 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EE91A89B0; Tue, 21 Jul 2015 08:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXtQstYQaqAg; Tue, 21 Jul 2015 08:23:48 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244661B2FA3; Tue, 21 Jul 2015 08:21:59 -0700 (PDT)
Received: from [31.133.179.67] (dhcp-b343.meeting.ietf.org [31.133.179.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6LFLoam008006 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2015 08:21:52 -0700
Subject: Re: RtgDir review: draft-rtg-dt-encap-02
To: Jamal Hadi Salim <hadi@mojatatu.com>, Erik Nordmark <nordmark@acm.org>
References: <CAAFAkD-vfrXA0ejLE7Gnk=q8wZbS4SzC7+=_TJY+qzTXv4R9OQ@mail.gmail.com> <559AB820.9000309@acm.org> <CAAFAkD8YugDgPoS_mt3H+nRoWHGz9TX+YocbmdRyPwpFOt_+2Q@mail.gmail.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <55AE638E.3000302@acm.org>
Date: Tue, 21 Jul 2015 17:21:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAAFAkD8YugDgPoS_mt3H+nRoWHGz9TX+YocbmdRyPwpFOt_+2Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVZU9aOH1UdqbUYtp8AofoIKORAMkOX7Q6R8qCJFJi7pR0ffdhZo0r+8dZ9wGOVmsz0W3RSONY1d2oFHPkH9i+je
X-Sonic-ID: C;ZvrSNbwv5RGAgIM848vClw== M;XAOhNrwv5RGAgIM848vClw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/g7nto3KhKePkOFMvkyF-KP9g9ms>
Cc: draft-rtg-dt-encap <draft-rtg-dt-encap@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 15:23:49 -0000

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 <nordmark@acm.org 
> <mailto:nordmark@acm.org>> 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