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

Erik Nordmark <> Tue, 21 July 2015 15:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B8EE91A89B0; Tue, 21 Jul 2015 08:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.935
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZXtQstYQaqAg; Tue, 21 Jul 2015 08:23:48 -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 244661B2FA3; Tue, 21 Jul 2015 08:21:59 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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 <>, Erik Nordmark <>
References: <> <> <>
From: Erik Nordmark <>
Message-ID: <>
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: <>
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: <>
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: 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 < 
> <>> 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 
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:
> <>

Let me have a look.

Thanks again,

> cheers,
> jamal