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

Jamal Hadi Salim <> Mon, 03 August 2015 11:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F30F61A6FF2 for <>; Mon, 3 Aug 2015 04:06:06 -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=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xfWBjxC4phZA for <>; Mon, 3 Aug 2015 04:06:02 -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 481A61A6FEE for <>; Mon, 3 Aug 2015 04:06:02 -0700 (PDT)
Received: by qgeh16 with SMTP id h16so85095588qge.3 for <>; Mon, 03 Aug 2015 04:06:01 -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=fsgWebEWLK1kPn7ujyTHn0RTEfLBJvadU/dscwQXts4=; b=BVcb9WCjH481XzXNB7LO5xP6yT0K/9dIaWgz7eF3QlBwC9tTpjQ/dSx6M3VGGrx1oM xn9Dgb8hoJrBeP7pRlyrSwJ6jHrJFXgeRtwMsW7cJARdJL0ivJ1fZNRe0XDt2qAIGIqe xOxhOXxe7AOVPsFY/kg54HNXLORU8Pbi0Oq3Xu0baYxz33L6D4rC4//xOJjusa/c2ORW dg0ThuMjEwJn48VDrx5L9PalBSfNXYTM75TIwssl576Dxmw0piqCJeeI4d/i9aBUjSjc lG6+a0euJiSYPAQsAZ25Eh+F9HoIH4g4HfUlhwUNnMk2R6Ek/4qNGNlMtzLniVXQOArx VAJg==
X-Gm-Message-State: ALoCoQlAVxmu3GMBKjZt0Kg8sCmdHE9KKpK3NAhZ5KEkPcOEoxmxj670jJWRaYBkTd/4r1QNy+cH
X-Received: by with SMTP id 5mr25130683qhf.84.1438599961358; Mon, 03 Aug 2015 04:06:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Aug 2015 04:05:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Jamal Hadi Salim <>
Date: Mon, 03 Aug 2015 07:05:41 -0400
Message-ID: <>
To: "Joel M. Halpern" <>
Content-Type: multipart/alternative; boundary="001a1135df9aabc5ad051c66277a"
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 11:06:07 -0000

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