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

Jamal Hadi Salim <hadi@mojatatu.com> Mon, 13 July 2015 11:53 UTC

Return-Path: <hadi@mojatatu.com>
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 B8CCA1AC408 for <rtgwg@ietfa.amsl.com>; Mon, 13 Jul 2015 04:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 tHuNfXlfd6nx for <rtgwg@ietfa.amsl.com>; Mon, 13 Jul 2015 04:53:32 -0700 (PDT)
Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (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 D5B921AD255 for <rtgwg@ietf.org>; Mon, 13 Jul 2015 04:52:29 -0700 (PDT)
Received: by oiab3 with SMTP id b3so133590380oia.1 for <rtgwg@ietf.org>; Mon, 13 Jul 2015 04:52:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HNjEl7uSv903U2Kc5VDX3hCz69LE6JaQVUX1LWrkgkU=; b=mZPsHFM3P6Go7b4u2CeLmSIGewBi+VnOg14AbxKH7GAJ8qITVpWd+BS4796J7AOfSc be24FSbdS9U7cnGSNwp1Sc4XtXfGMDKZ6lut8gc8fH8ok9ty/JRE9dxi/ts9GXHLkz1i vevrMp7lRdiRQZN6e9FtcF+94PS8FBeabTy3dz0z+H0GAOjE9LzQMnEO/OtSkbMeJwaj n5+AUmaAcOjKlSo7BVIoH3yM2FXCRiExxucY5VRhrRq0M6zUCeBUvHdIFVkC9q+Hu6QN 2zPaV2FQZ0f1CurbpKaEjsWF5NKNqE2lbQe1UELqK5nox5J9SwkDiUNAI+ZE59kbEx96 YJaA==
X-Gm-Message-State: ALoCoQkISzf2tJSeht4YhWiFJCRbuS5U7/h/k/Vt62m2sDMR8DIB6JhQpO64ZUYHjnMuIaZFgm7F
X-Received: by 10.202.191.139 with SMTP id p133mr13609270oif.130.1436788349220; Mon, 13 Jul 2015 04:52:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.88.194 with HTTP; Mon, 13 Jul 2015 04:52:09 -0700 (PDT)
In-Reply-To: <559AB820.9000309@acm.org>
References: <CAAFAkD-vfrXA0ejLE7Gnk=q8wZbS4SzC7+=_TJY+qzTXv4R9OQ@mail.gmail.com> <559AB820.9000309@acm.org>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Mon, 13 Jul 2015 07:52:09 -0400
Message-ID: <CAAFAkD8YugDgPoS_mt3H+nRoWHGz9TX+YocbmdRyPwpFOt_+2Q@mail.gmail.com>
Subject: Re: RtgDir review: draft-rtg-dt-encap-02
To: Erik Nordmark <nordmark@acm.org>
Content-Type: multipart/alternative; boundary=001a113de0882c5d46051ac05b91
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/BZFIARmgC6iaPgLY0jf-qUnFgiE>
X-Mailman-Approved-At: Thu, 16 Jul 2015 10:49:11 -0700
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: Mon, 13 Jul 2015 11:53:34 -0000

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> 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