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

Jamal Hadi Salim <hadi@mojatatu.com> Mon, 03 August 2015 22:24 UTC

Return-Path: <hadi@mojatatu.com>
X-Original-To: forces@ietfa.amsl.com
Delivered-To: forces@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4041B1B31DB for <forces@ietfa.amsl.com>; Mon, 3 Aug 2015 15:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isYpoCwYpslj for <forces@ietfa.amsl.com>; Mon, 3 Aug 2015 15:24:32 -0700 (PDT)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE9C1B31D6 for <forces@ietf.org>; Mon, 3 Aug 2015 15:24:24 -0700 (PDT)
Received: by qgeh16 with SMTP id h16so98990450qge.3 for <forces@ietf.org>; Mon, 03 Aug 2015 15:24:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.140.235.71 with SMTP id g68mr1144942qhc.22.1438640663952; Mon, 03 Aug 2015 15:24:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.62.196 with HTTP; Mon, 3 Aug 2015 15:24:04 -0700 (PDT)
In-Reply-To: <55BF7FE7.9060403@joelhalpern.com>
References: <CAG4d1rfXwh_rq--ZmQpnX_zUGYtEsKwbc+mQhim4bx7QkiO_pA@mail.gmail.com> <CAAFAkD-oo3guuoSLOzA9RJSWLs2iGxRuzTr_rkeGTtr0c_EaTA@mail.gmail.com> <55BE711C.4020501@joelhalpern.com> <CAAFAkD8FoiAfgrPJYMqZ8eeEQtbRxe8J5+dpyGqDvX_QZ=YsWA@mail.gmail.com> <55BF7FE7.9060403@joelhalpern.com>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Mon, 3 Aug 2015 18:24:04 -0400
Message-ID: <CAAFAkD_RM01HFAruc+kffxs_00Ye0d8X1PRo_od7LxSvz=+6Nw@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary=001a1135620ebc18f4051c6fa15c
Archived-At: <http://mailarchive.ietf.org/arch/msg/forces/KalOPi_112_DAMPiwrjQVehHvvE>
Cc: "forces@ietf.org" <forces@ietf.org>, draft-ietf-forces-interfelfb@ietf.org, Alia Atlas <akatlas@gmail.com>
Subject: Re: [forces] AD review of draft-ietf-forces-interfelfb-01
X-BeenThere: forces@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ForCES WG mailing list <forces.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/forces>, <mailto:forces-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/forces/>
List-Post: <mailto:forces@ietf.org>
List-Help: <mailto:forces-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/forces>, <mailto:forces-request@ietf.org?subject=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 <jmh@joelhalpern.com>
wrote:

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

cheers,
jamal



> 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 <jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.com>> 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
>>
>