Return-Path: 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 ; 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 ; 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 ; 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; 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: <55BE711C.4020501@joelhalpern.com> <55BF7FE7.9060403@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 3 Aug 2015 18:24:04 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a1135620ebc18f4051c6fa15c Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@ietf.org, Alia Atlas 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 22:24:34 -0000 --001a1135620ebc18f4051c6fa15c Content-Type: text/plain; charset=UTF-8 On Mon, Aug 3, 2015 at 10:51 AM, Joel M. Halpern 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 > > 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 >> > --001a1135620ebc18f4051c6fa15c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 10:51 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
While we need to = explain the choice of Ethernet, assuming such explanation then using that f= or the outer encapsulation seems fine.=C2=A0 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.
=C2=A0
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 t= he next 1-2 days. We feel that=C2=A0
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

=C2=A0
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@joe= lhalpern.com>> wrote:

=C2=A0 =C2=A0 A couple of points where I see mis-communication, in line bel= ow:

=C2=A0 =C2=A0 On 8/2/15 2:40 PM, Jamal Hadi Salim wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 This answer seems to miss Alia's point.=C2= =A0 Suppose that we are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 processing a mix of packets from multiple end-a= pplications (this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 seems very likely).=C2=A0 Then some of those pa= ckets will be more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 important than others.=C2=A0 If there is conges= tion, and if packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 drops are needed to keep things working, then y= ou want to drop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the inter-FE packets whose underlying IP packet= is lower
=C2=A0 =C2=A0 =C2=A0 =C2=A0 priority, while retaining the ones whose underl= ying IP priority
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (DSCP inferred drop precedence, ...) is higher.= =C2=A0 So setting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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.

=C2=A0 =C2=A0 I think that there are actually two issues here.
=C2=A0 =C2=A0 1) There is no reason for the outer MAC header to be (from a<= br> =C2=A0 =C2=A0 specification point of view) a copy of the inner MAC header.= =C2=A0 It
=C2=A0 =C2=A0 needs to have the right contents for sending the packet to th= e next
=C2=A0 =C2=A0 FE, which has nothing to do with the underlying Ethernet MAC<= br> =C2=A0 =C2=A0 header.=C2=A0 It may have to do with the underlying priority,= but
=C2=A0 =C2=A0 specifying it as a copy of the header is not a good model.
=C2=A0 =C2=A0 2) The mechanism should be specified in such a way that it wo= rks
=C2=A0 =C2=A0 even if we are not carrying a subscriber MAC header.=C2=A0 It= should work
=C2=A0 =C2=A0 with just an IP header.=C2=A0 It should work with media other= than
=C2=A0 =C2=A0 Ethernet.=C2=A0 This mechanism is not specific to external Et= hernet
=C2=A0 =C2=A0 support.=C2=A0 For example, if you are using this for process= ing isnide a
=C2=A0 =C2=A0 service environment, the subscribers MAC header is likely lon= g gone
=C2=A0 =C2=A0 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 translati= on
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?

=C2=A0 =C2=A0 It is fine to carry packets from multiple tenants across this=
=C2=A0 =C2=A0 mechanism.=C2=A0 However, ForCES does not rely on vlan tags f= or
=C2=A0 =C2=A0 differentiation. Rather, it uses metadata.=C2=A0 So I don'= ;t see why you
=C2=A0 =C2=A0 are worrying about the incoming vlan tag (which may not even = be there.)


Agreed.

cheers,
jamal

--001a1135620ebc18f4051c6fa15c--