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

Alia Atlas <akatlas@gmail.com> Mon, 03 August 2015 14:31 UTC

Return-Path: <akatlas@gmail.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 DC86D1A039D; Mon, 3 Aug 2015 07:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 OrzsfXwR0sIK; Mon, 3 Aug 2015 07:31:24 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 A5AC81A00C7; Mon, 3 Aug 2015 07:31:24 -0700 (PDT)
Received: by obre1 with SMTP id e1so100316418obr.1; Mon, 03 Aug 2015 07:31:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R77ftrW9HkJH3RkgvJqyGJOk1Du3PZD2h32T+ZrXbUo=; b=OMSnB6xXZX7dVNzq15IM2vntFeMNNvO+KEEMLVtbMauwmz4jXZ30M7/pN8WYm5oGSc UNzpihL1/pUFvkpXvjJjwVWTl847la+Xsbg5usCbaU2jDkpAc6h43K10ziJwYfY/Rwux Ew3omwEBIeJBNFhF6v/iqctQsYSuhrMzvhpvh7lxE4yjOneBPLzuIwM4ilg70r19IDg8 ohi8q5OwKV7KeutmpbSXvAEI1jmnaxuqfeNvHiaF841bABu9Kr+J13sCSTtGk2OnJQrs 5nVpi9QZHbC8xShhn1PgVKIje3/2OFdqwCn3iwFHqOrGGqtfnwJH/1L647u2C9Kpz7Mo pJcw==
MIME-Version: 1.0
X-Received: by 10.60.54.1 with SMTP id f1mr17309420oep.68.1438612283850; Mon, 03 Aug 2015 07:31:23 -0700 (PDT)
Received: by 10.60.41.99 with HTTP; Mon, 3 Aug 2015 07:31:23 -0700 (PDT)
In-Reply-To: <CAAFAkD8FoiAfgrPJYMqZ8eeEQtbRxe8J5+dpyGqDvX_QZ=YsWA@mail.gmail.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>
Date: Mon, 3 Aug 2015 10:31:23 -0400
Message-ID: <CAG4d1rcnTfXwRtNJTWWdOp5XnwWoQT-Ouge1bY422X3YYuPjQQ@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Jamal Hadi Salim <hadi@mojatatu.com>
Content-Type: multipart/alternative; boundary=089e0115f36e26086d051c690625
Archived-At: <http://mailarchive.ietf.org/arch/msg/forces/uA29vyKOfoOcnhI5wZ6W56elceU>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, draft-ietf-forces-interfelfb@ietf.org, "forces@ietf.org" <forces@ietf.org>
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 14:31:29 -0000

Hi Jamal,

On Mon, Aug 3, 2015 at 7:05 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

>
> On Sun, Aug 2, 2015 at 3:35 PM, Joel M. Halpern <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.
>

Congestion control and prioritization need to be addressed.  What I think
you are missing is that it is important to clearly specify how QoS or CoS
is handled so that doing an inter-FE mechanism doesn't break CoS.


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

Are you describing a generic packet format that can then be encapsulated in
an Ethernet frame or IP or so on, or something which is just for
Ethernet?   You need to decide what you are documenting.

Regards,
Alia

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
>