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

Jamal Hadi Salim <> Mon, 13 July 2015 11:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B8CCA1AC408 for <>; Mon, 13 Jul 2015 04:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tHuNfXlfd6nx for <>; Mon, 13 Jul 2015 04:53:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5B921AD255 for <>; Mon, 13 Jul 2015 04:52:29 -0700 (PDT)
Received: by oiab3 with SMTP id b3so133590380oia.1 for <>; Mon, 13 Jul 2015 04:52:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id p133mr13609270oif.130.1436788349220; Mon, 13 Jul 2015 04:52:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Jul 2015 04:52:09 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Jamal Hadi Salim <>
Date: Mon, 13 Jul 2015 07:52:09 -0400
Message-ID: <>
Subject: Re: RtgDir review: draft-rtg-dt-encap-02
To: Erik Nordmark <>
Content-Type: multipart/alternative; boundary=001a113de0882c5d46051ac05b91
Archived-At: <>
X-Mailman-Approved-At: Thu, 16 Jul 2015 10:49:11 -0700
Cc: draft-rtg-dt-encap <>, "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jul 2015 11:53:34 -0000

Sorry for the latency - this got buried because i wasnt on the cc so my
gave it low prio.

On Mon, Jul 6, 2015 at 1:17 PM, Erik Nordmark <> 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
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
>> 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

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