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

Jamal Hadi Salim <> Mon, 03 August 2015 22:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4041B1B31DB for <>; Mon, 3 Aug 2015 15:24: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 isYpoCwYpslj for <>; Mon, 3 Aug 2015 15:24: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 CEE9C1B31D6 for <>; Mon, 3 Aug 2015 15:24:24 -0700 (PDT)
Received: by qgeh16 with SMTP id h16so98990450qge.3 for <>; Mon, 03 Aug 2015 15:24:24 -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=RhmQ/9EhnQZTXHGQ2x5H6epjscOIHCGy92dci6FAt7M=; b=RztEVi56AUIx91gC4tC8r5naPhZPaoYFfHiwxu9Iu1ChgpGzhPj6r9WUbShIc9oQst YJaCRzLG42JlpXpiyX97Ckkk+/FW3V/FEzz9fcoKKgcu1v+OhaNngEwahGQYKaTY8jok 0XLpgKmlYPUtJThJjuqzeyG0TCbvqKeCciniZc2cGbtWXitNoADeo0pAcwJsipDw4xM9 11jR3PCxZ5WeeM0DIlHWMcRps53LEWPF+BR7vLhJjon6yk74mcris7QjbeJ4CWb1NyoT 5iN8kkbHa9ydVT8RlR1oxkdvrIcLAgmbPVP5D6hw7CqWsH2Rd49mH3lDODh85Kp8CRAm 5NQg==
X-Gm-Message-State: ALoCoQl6OgLaBeaex9OVHC6UhVMdZf3c0Y3nqjc9ombBrli6Zfu7UomF+wAueBqRSTp+Odf24loe
X-Received: by with SMTP id g68mr1144942qhc.22.1438640663952; Mon, 03 Aug 2015 15:24:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Aug 2015 15:24:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Jamal Hadi Salim <>
Date: Mon, 03 Aug 2015 18:24:04 -0400
Message-ID: <>
To: "Joel M. Halpern" <>
Content-Type: multipart/alternative; boundary="001a1135620ebc18f4051c6fa15c"
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 22:24:34 -0000

On Mon, Aug 3, 2015 at 10:51 AM, Joel M. Halpern <>

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

We are going to get rid of that detail. It was confusing.

> 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.
Ok, we will publish a new version in the next 1-2 days. We feel that
a focus will help to get rid of the confusion. If there is tweaking that
can be made to allow other transports that would be great.


> Yours,
> Joel
> 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