Re: [forces] AD review of draft-ietf-forces-interfelfb-01

"Joel M. Halpern" <> Mon, 03 August 2015 14:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 65C701A1BD1; Mon, 3 Aug 2015 07:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lPAyH6_bW64u; Mon, 3 Aug 2015 07:51:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30EF61A1BBC; Mon, 3 Aug 2015 07:51:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B84201C07AB; Mon, 3 Aug 2015 07:51:21 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9C8A31C003B; Mon, 3 Aug 2015 07:51:20 -0700 (PDT)
To: Jamal Hadi Salim <>, "Joel M. Halpern" <>
References: <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Mon, 03 Aug 2015 10:51:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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
Archived-At: <>
Cc: "" <>,, Alia Atlas <>
Subject: Re: [forces] AD review of draft-ietf-forces-interfelfb-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ForCES WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2015 14:51:25 -0000

While we need to explain the choice of Ethernet, assuming such 
explanation then using that for the outer encapsulation seems fine.  It 
was the assumption that the inner encapsulation was Ethernet that seemed 

It seems to me that if we are careful in the wording, we probably can 
also allow for other carriage means to be defined later.


On 8/3/15 7:05 AM, Jamal Hadi Salim wrote:
> On Sun, Aug 2, 2015 at 3:35 PM, Joel M. Halpern <
> <>> wrote:
>     A couple of points where I see mis-communication, in line below:
>     On 8/2/15 2:40 PM, Jamal Hadi Salim wrote:
>         This answer seems to miss Alia's point.  Suppose that we are
>         processing a mix of packets from multiple end-applications (this
>         seems very likely).  Then some of those packets will be more
>         important than others.  If there is congestion, and if packet
>         drops are needed to keep things working, then you want to drop
>         the inter-FE packets whose underlying IP packet is lower
>         priority, while retaining the ones whose underlying IP priority
>         (DSCP inferred drop precedence, ...) is higher.  So setting
>         everything as high between the two FEs is not a good idea.
> How about we totally remove that text? upstream LFBs will set priority
> fields (which pass through the Inter-FE LFB) and down
> stream LFBs (like schedulers) will pay attention to it.
>     I think that there are actually two issues here.
>     1) There is no reason for the outer MAC header to be (from a
>     specification point of view) a copy of the inner MAC header.  It
>     needs to have the right contents for sending the packet to the next
>     FE, which has nothing to do with the underlying Ethernet MAC
>     header.  It may have to do with the underlying priority, but
>     specifying it as a copy of the header is not a good model.
>     2) The mechanism should be specified in such a way that it works
>     even if we are not carrying a subscriber MAC header.  It should work
>     with just an IP header.  It should work with media other than
>     Ethernet.  This mechanism is not specific to external Ethernet
>     support.  For example, if you are using this for processing isnide a
>     service environment, the subscribers MAC header is likely long gone
>     and irrelevant.
> Ok, got it ;->
> The implementation ended dealing with Ethernet as the "raw
> packet" input into IN1. As i was saying that text was direct translation
> from the code. So we need to fix the text.
> And yes, I agree that it is possible there will be no ethernet frame
> arriving
> at IN1.
> We would like however want to keep the ethernet encapsulation
> and not have to deal with POS for example - would that be fine?
>     It is fine to carry packets from multiple tenants across this
>     mechanism.  However, ForCES does not rely on vlan tags for
>     differentiation. Rather, it uses metadata.  So I don't see why you
>     are worrying about the incoming vlan tag (which may not even be there.)
> Agreed.
> cheers,
> jamal