From nobody Sun Aug 2 11:41:11 2015 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 4D0951A88A0 for ; Sun, 2 Aug 2015 11:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tHgUSoOqZAju for ; Sun, 2 Aug 2015 11:41:07 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 1DCC21A889A for ; Sun, 2 Aug 2015 11:41:06 -0700 (PDT) Received: by qgeu79 with SMTP id u79so76579465qge.1 for ; Sun, 02 Aug 2015 11:41:06 -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=SCxBRo8z8fR2oUJC528WanGz87P8tx7N/MLeFkbVz5g=; b=Zp8enEKErOCJoskQpVCl2HGsXTMXXqd5FimnuhFMnyCOg+DU2Vukouh0CUVO3819bO 8iTMgyoy361PjtnSTmzeKCbQGmDfIjvF2ovLFLWa8asFmG1K4QUwFIrjhDxblS/EzgBR vh4FEn3MaDhA4glc/FKLt4CSn0rPPM+gRd0D3EF7yMHGC+tseVIJUx7rlXDyD38rYkHd lwlHWu2qFex00qJMQ0AVlgORQVkeH7AboALrC+dGkZfxUxYJLIxyTzpY7GLmJThKeFmZ a9mQaDZ1/1GwKos913PudE0LlyzI7bnXc58wxDwxDtWhm+YdrK7n2uZUjEKD1qLY0Skl jNQA== X-Gm-Message-State: ALoCoQnXswx6DiqEguX8rvN5fRAQYu3tLWFqO2zKXmPUnEIgFOJusxOyN0sfZoW2ihnUe15PK6uA X-Received: by 10.140.235.71 with SMTP id g68mr20493264qhc.22.1438540866164; Sun, 02 Aug 2015 11:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.62.196 with HTTP; Sun, 2 Aug 2015 11:40:46 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Sun, 2 Aug 2015 14:40:46 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a1135620e52b8f1051c586552 Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 18:41:10 -0000 --001a1135620e52b8f1051c586552 Content-Type: text/plain; charset=UTF-8 Hi Alia, On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas wrote: > Hi Damascane and Jamal, > > First, thank you for your work on this draft. > > As is customary, I have done my AD review of this draft before requesting > IETF Last Call. > > Thanks for making the time. Your effort is very much appreciated. > As part of this, I see that Evangelos, acting as Document Shepherd, found > a number of issues that are written up in his report - and that still > haven't been addressed two months later. Picking an IANA value that isn't > available is one of them. I know these are editorial, but still needed. > > Sorry. Based on the last discussions we had it didnt seem that it was worth changing until we got AD input (for some reason i thought it was you we discussed this with - but likely it was Adrian; i just got back so still jetlagged). We will make an update taking into consideration the comments from Evangelos and yourself. At this time, I really don't think this draft is ready to advance. > There are some things that are editorial or clarifications, as I described > below. > > Please take some serious time and focus to improve this document if you > want it to progress. > > There are two primary major issues. > > First, you haven't in any way justified why the inter-FE communication > needs to be encapsulated in an Ethernet frame. Since you are asking for > the IETF to get an EtherType allocated, that's kind of a bare minimum. > We have this working over ethernet today and our scope is on ethernet L2 networks in a private setting (because that was the charter work item). We need the ethertype for dis-ambiguation of the frames. We do recognize it is possible to run data across different underlying protocols - but it seems even talking about that in the doc was unnecessary editorializing. Second, the draft bounces around a lot around whether this is an > encapsulation that is just inside Ethernet or a general encapsulation that > can be inside IP and other things. > Ok, we will review and remove any uncertainty and just focus on ethernet. > Moreover, it doesn't actually describe the reasoning or handling of the > src/dest information and the packets. > > We will try to clarify. > You really need to better describe precisely the assumptions, behaviors, > and error handling. > > Section 6 tries to cover the above. We will go over it again and fix any gaps we can find. Issues: > > 1) In Sec 5.1.1: "The frame may be dropped if there is congestion on the > receiving FE side. One approach to mitigate this issue is to make sure > that inter-FE LFB frames receive the highest priority treatment > when scheduled on the wire." This suggestion just destroyed the > possibility of respecting the requested CoS of the encapsulated packet and > probably any actual high priority or EF traffic. This recommendation must > be fixed. > > Would wording around this form help: "The frame may be dropped if there is congestion on the receiving FE side. To mitigate this issue is the sending FE side should treat inter-FE LFB frames with high priority. When 802.1p is present, then it is recommended a value of XXX should be used. In the absence of 802.1p, implementation specific treatments at the source FE may be used". To your earlier point i think we need to say something like this around section 6 as well. 2) In Sec 6.1.1: One step is " create the outer ethernet header which is a > duplicate of the > incoming frame's ethernet header. The outer ethernet header may > have an optional 802.1q header (if one was included in the > original frame)." First, what if the incoming packet wasn't in an > ethernet frame? POS does still exist. > Our intent (and deployment) is on ethernet. Clearly we need to emphasize that view. Do you see POS as a necessary ingredient? > Second, why would the 802.1q vlan tag be relevant/valid on the outgoing > port in between FEs? This doesn't really make sense to me. I do see the > next bullet talks about changing the vlan tag value but nothing happens if > the NEID is 0 or absent. > > The context of this was taken directly from code;-> So something was lost in translation. We will fix it. As to the relevance of the vlan tags - the idea of NEID is one of tenancy differentiation. > 3) How can the DSTFE be optional??? Why does sending the Ethernet Frame > to the original destination MAC address work? > > You put some doubt in my mind when I read this;-> So I went and looked at testcases. And in the majority of the policies, we do specify the DSTFE. But there are some cases where _we dont_ and reuse the originally target DSTFE MAC address on the outer header. Does that explain? If not, why do you think it wont work? 4) In Sec 6.2, what happens if none of the optional elements of an IFEInfo > are specified? > Thanks for catching this. There would be no such table entry allowed (and so no processed packets will encounter this scenario). We will update the doc to indicate that when the CE inserts policies in the policy table - the FE MUST validate that the non optional fields are all present (the implementation already does that). > How can this work if there's no required way to describe the destination > FE? > > Am I misunderstanding or are you are implying we need some default DSTFE where a lookup failure happens? Last para in 6.1.1 describes what happens on lookup failure. 5) From p. 22, it looks like the IFETable is defined assuming only > transport over Ethernet. > > Yes - that is the intent > 6) Sec 10: I think you'll find that there are security implications of > taking packets and sending them in an Ethernet packet. Now, I realize that > the different FEs are probably inside the same device on a private network > - but you need to clarify why that's the case. > > Yes, the scope is within the same network. We will add clarification. > Minor Quibble: > > a) There are places where this draft talks about other documents being > written. For instance, on the top of p.13 "For any mapping towards these > definitions a different document to describe the mapping, one per > transport, is expected to be defined." It's fine to have a process in mind > - but this is completely unclear, given that the WG is closed. Are these > documents with a well-known place on-line? Are these ISE drafts? Do you > think these would be AD-sponsored or in rtgwg? > > We can get rid of such text altogether to avoid any confusion we are talking about ethernet only. > b) On the bottom of p. 13, it says "In this version of the specification, > we only focus on data and metadata. Therefore we are not going to describe > how to carry the ExceptionID information (future versions may). " PLEASE > go through the document and get rid of these bits of tentative and future > language. The document is doing and defining what it is. OWN that and fix > the language everywhere. (e.g. bottom of p.14 "would save us") > > Will do. > > Nits: > > 1) On p. 6, "This information may include any source and > destination information (MAC address to use, if ethernet;)" Sadly, I think > the ;) needs to go - what about "e.g. MAC address to use, if Ethernet)". > > will do. > 2) In Sec. 3.1.1, the last paragraph is "The purpose of the inter-FE LFB > is to define standard mechanisms for interconnecting FEs and for that > reason we are not going to touch > anymore on proprietary chip-chip interconnects other than state the > fact they exist and that it is feasible to have translation to and > from proprietary approaches." is a bit informal. Could you please > clean it up a bit? > For instance: "This document defines the inter-FE LFB, a standard > mechanism for interconnecting FEs. Existing proprietary approaches, such > as chip-chip interconnects, may be able to translate to and from the > standard inter-FE LFB." > > Will do. > 3) Sec 4 starts with "We address the inter-FE connectivity requirements by > proposing the inter-FE LFB class." Remember this will be an RFC - please > replace "proposing" with "defining". Similarly, the title of "Figure 6: > Packet format suggestion" - is this what the document is standardizing or > not?? > > Will do. Thanks for the thorough review. cheers, jamal > Thanks, > Alia > > --001a1135620e52b8f1051c586552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,


On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas <akatla= s@gmail.com> wrote:
Hi=C2=A0Damascane and Jamal,

First, thank= you for your work on this draft.

= As is customary, I have done my AD review of this draft before requesting I= ETF Last Call. =C2=A0


Thanks for making the time. Your ef= fort is very much appreciated.

=C2=A0
As part of this, I see that Evangelos, acting as Document Shepherd= , found a number of issues that are written up in his report - and that sti= ll haven't been addressed two months later.=C2=A0 Picking an IANA value= that isn't available is one of them.=C2=A0 I know these are editorial,= but still needed.



Sorry.
Based o= n the last discussions we had it didnt seem that it was =C2=A0worth changin= g
until we got AD input (for some reason i thought it was you we = discussed
this with - but likely it was Adrian; i just got back s= o still jetlagged).=C2=A0
We will make an update taking into cons= ideration the comments from
=C2=A0Evangelos and yourself.


At this time, I really don't t= hink this draft is ready to advance.
There are= some things that are editorial or clarifications, as I described below.

Please take so= me serious time and focus to improve this document if you want it to progre= ss.

There a= re two primary major issues.

First, you haven't in any way justified why the inter-FE = communication needs to be encapsulated in an Ethernet frame.=C2=A0 Since yo= u are asking for the IETF to get an EtherType allocated, that's kind of= a bare minimum.

= We have this working over ethernet today and our scope is on ethernet
=
L2 networks in a private setting (because that was the charter work it= em).=C2=A0
We need the ethertype =C2=A0for dis-ambiguation of the= frames.
We do recognize it is possible to run data across differ= ent underlying
protocols - but it seems even talking about that i= n the doc was unnecessary
editorializing.


Second, the draft bounces around a lot around whet= her this is an encapsulation that is just inside Ethernet or a general enca= psulation that can be inside IP and other things.
=

Ok, we will review and remove any uncertai= nty
and just focus on ethernet.
=C2=A0
Moreover, it doesn't act= ually describe the reasoning or handling of the src/dest information and th= e packets.



We will try to clarify.
=C2=A0
You really need to better describe precisely the= assumptions, behaviors, and error handling.
<= br>

Section 6 tri= es to cover the above. We will go over it again and fix
any gaps = we can find.


Issues:

1) In Sec 5.1.1: =C2=A0"= ;The frame may be dropped if there is congestion on the recei= ving=C2=A0FE side.=C2=A0 One approach to mitigate this issue is to make sur= e that=C2=A0inter-FE LFB frames receive the highest priority treatment when= =C2=A0scheduled on the wire." =C2=A0This suggestion just destroyed the= possibility of respecting the requested CoS of the encapsulated packet and= probably any actual high priority or EF traffic. =C2=A0 This recommendatio= n must be fixed.



Would wording around this form help:
"The fr= ame may be dropped if there is congestion on the receiving FE side.=C2=A0
To mitigate this issue is the sending FE side should treat inter-F= E LFB frames
with high priority. When 802.1p is present, then it = is recommended a value
of XXX should be used. In the absence of 8= 02.1p, implementation specific
treatments at the source FE may be= used".
To your earlier point i think we need to say somethi= ng like this around section
6 as well.

2) In Sec 6.1.1: = One step is "=C2=A0create the outer ethernet header which is a duplica= te of the
=C2=A0 =C2=A0 =C2=A0 incoming frame's ethernet header.=C2= =A0 The outer ethernet header may
=C2=A0 =C2=A0 =C2=A0 have an optional = 802.1q header (if one was included in the
=C2=A0 =C2=A0 =C2=A0 original = frame)." =C2=A0First, what if the incoming packet wasn't in an eth= ernet frame?=C2=A0 POS does still exist.=C2=A0


Our intent (and deployment) =C2=A0is on ethe= rnet. Clearly we need to emphasize
that view.
Do you se= e POS as a necessary ingredient?
=C2=A0
Second, why would the 802.1q vlan tag be = relevant/valid on the outgoing port in between FEs? =C2=A0 This doesn't= really make sense to me.=C2=A0 I do see the next bullet talks about changi= ng the vlan tag value but nothing happens if the NEID is 0 or absent.
=


The context of this w= as taken directly from code;-> So something was
lost in transl= ation. We will fix it.

As to the relevance of the = vlan tags - the idea of NEID is one of tenancy
differentiation.
=C2=A0
<= /div>
3) How can the DSTFE be optional???=C2=A0 Why does sending the Et= hernet Frame to the original destination MAC address work?

<= /blockquote>

You put some doubt in my mind when I read t= his;-> So I went and looked
at testcases. And in the majority = of the policies, we do specify the DSTFE.
But there are some case= s where _we dont_ and reuse the originally
target DSTFE MAC addre= ss on the outer header.
Does that explain? If not, why do you thi= nk it wont work?=C2=A0

<= div dir=3D"ltr">4) In Sec 6.2, what happens if none of the optional element= s of an IFEInfo are specified?

Thank= s for catching this.
There would be no such table entry allowed (= and so no processed packets
will encounter this scenario). We wil= l update the doc to indicate that when the
CE inserts policies in= the policy table - the FE MUST validate that the non
optional fi= elds are all present (the implementation already does that).
=C2= =A0
How can this work = if there's no required way to describe the destination FE?


Am I misunderstanding or are you a= re implying we need some default
DSTFE where a lookup failure hap= pens?
Last para in 6.1.1 describes what happens on lookup failure= .

=
5) From p. 22, it looks like the IFETable is defined assumi= ng only transport over Ethernet.


Yes - that is the intent<= /div>
=C2=A0
=
6) Sec 10: =C2=A0I think you'll find= that there are security implications of taking packets and sending them in= an Ethernet packet.=C2=A0 Now, I realize that the different FEs are probab= ly inside the same device on a private network - but you need to clarify wh= y that's the case.


Yes, the scope is within the same n= etwork. We will add clarification.
=C2=A0
Minor Quibble:
=

a) There are places where this = draft talks about other documents being written.=C2=A0 For instance, on the= top of p.13 "For any mapping towards these definitions a d= ifferent=C2=A0 =C2=A0document to describe the mapping, one per trans= port, is expected to=C2=A0be defined." =C2=A0It's fine to have a p= rocess in mind - but this is completely unclear, given that the WG is close= d.=C2=A0 Are these documents with a well-known place on-line?=C2=A0 Are the= se ISE drafts?=C2=A0 Do you think these would be AD-sponsored or in rtgwg?<= /div>


We can get r= id of such text altogether to avoid any confusion we are
talking = about ethernet only.

=C2=A0
b) On the bottom of p. 13, it says "In = this version of the specification, we only focus on data and metadata.=C2= =A0 Therefore we are not going to describe how to carry the ExceptionID inf= ormation (future versions may). " =C2=A0 PLEASE go through the documen= t and get rid of these bits of tentative and future language.=C2=A0 The doc= ument is doing and defining what it is.=C2=A0 OWN that and fix the language= everywhere. =C2=A0(e.g. bottom of p.14 "would save us")

=

Will do.
=C2=A0

<= font color=3D"#000000" face=3D"PT Mono, Monaco, monospace">Nits:

1) On p. 6, "This information may inc= lude any source and destination=C2=A0information (MAC address to use, if et= hernet;)" =C2=A0Sadly, I think the ;) needs to go - what about "e= .g. MAC address to use, if Ethernet)".


will do.
=C2=A0
2) In Sec. 3.1.1, the = last paragraph is=C2=A0"The purpose of the inter-FE LFB is to define s= tandard mechanisms for=C2=A0interconnecting FEs and for that reason we are = not going to touch
=C2=A0 =C2=A0anymore on proprietary chip-chip interco= nnects other than state the
=C2=A0 =C2=A0fact they exist and that it is = feasible to have translation to and
=C2=A0 =C2=A0from proprietary approa= ches." =C2=A0is a bit informal.=C2=A0 Could you please clean it up a b= it?=C2=A0
For instance: =C2=A0"This document d= efines the inter-FE LFB, a standard mechanism for interconnecting FEs.=C2= =A0 Existing proprietary approaches, such as chip-chip interconnects, may b= e able to translate to and from the standard inter-FE LFB."

<= /div>

Will do.
=C2=A0
=
3) Sec 4 starts with &= quot;We address the inter-FE connectivity requirements by proposing the=C2= =A0inter-FE LFB class." =C2=A0Remember this will be an RFC - please re= place "proposing" with "defining".=C2=A0 Similarly, the= title of "Figure 6: Packet format suggestion" - is this what the= document is standardizing or not??

=

Will do.

Thanks for the thorou= gh review.

cheers,
jamal
=C2= =A0
Thanks,
Alia


--001a1135620e52b8f1051c586552-- From nobody Sun Aug 2 12:36:01 2015 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 DBFBD1ACE0A; Sun, 2 Aug 2015 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Tm9zgXhkzCzX; Sun, 2 Aug 2015 12:35:58 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FDB1ACE06; Sun, 2 Aug 2015 12:35:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 250F9900968; Sun, 2 Aug 2015 12:35:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 617DF1C052B; Sun, 2 Aug 2015 12:35:57 -0700 (PDT) To: Jamal Hadi Salim , Alia Atlas References: From: "Joel M. Halpern" Message-ID: <55BE711C.4020501@joelhalpern.com> Date: Sun, 2 Aug 2015 15:35:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 19:36:00 -0000 A couple of points where I see mis-communication, in line below: On 8/2/15 2:40 PM, Jamal Hadi Salim wrote: > Hi Alia, > > > On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas > wrote: > > Hi Damascane and Jamal, > > First, thank you for your work on this draft. > > As is customary, I have done my AD review of this draft before > requesting IETF Last Call. > > > Thanks for making the time. Your effort is very much appreciated. > ... > > > Issues: > > 1) In Sec 5.1.1: "The frame may be dropped if there is congestion on > the receiving FE side. One approach to mitigate this issue is to > make sure that inter-FE LFB frames receive the highest priority > treatment when scheduled on the wire." This suggestion just > destroyed the possibility of respecting the requested CoS of the > encapsulated packet and probably any actual high priority or EF > traffic. This recommendation must be fixed. > > > > Would wording around this form help: > "The frame may be dropped if there is congestion on the receiving FE side. > To mitigate this issue is the sending FE side should treat inter-FE LFB > frames > with high priority. When 802.1p is present, then it is recommended a value > of XXX should be used. In the absence of 802.1p, implementation specific > treatments at the source FE may be used". > To your earlier point i think we need to say something like this around > section > 6 as well. 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. > > 2) In Sec 6.1.1: One step is " create the outer ethernet header > which is a duplicate of the > incoming frame's ethernet header. The outer ethernet header may > have an optional 802.1q header (if one was included in the > original frame)." First, what if the incoming packet wasn't > in an ethernet frame? POS does still exist. > > > > Our intent (and deployment) is on ethernet. Clearly we need to emphasize > that view. > Do you see POS as a necessary ingredient? 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. > > Second, why would the 802.1q vlan tag be relevant/valid on the > outgoing port in between FEs? This doesn't really make sense to > me. I do see the next bullet talks about changing the vlan tag > value but nothing happens if the NEID is 0 or absent. > > > The context of this was taken directly from code;-> So something was > lost in translation. We will fix it. > > As to the relevance of the vlan tags - the idea of NEID is one of tenancy > differentiation. 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.) > > 3) How can the DSTFE be optional??? Why does sending the Ethernet > Frame to the original destination MAC address work? > > > You put some doubt in my mind when I read this;-> So I went and looked > at testcases. And in the majority of the policies, we do specify the DSTFE. > But there are some cases where _we dont_ and reuse the originally > target DSTFE MAC address on the outer header. > Does that explain? If not, why do you think it wont work? That does not make sense. The InterFE LFB needs to know where to send the packet, and needs to send it there. You can take some implementation shortcuts (although I would bet they will cause you trouble later), but that is not how you specify the protocol behavior. ... From nobody Mon Aug 3 04:06:08 2015 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 F30F61A6FF2 for ; Mon, 3 Aug 2015 04:06:06 -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=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 xfWBjxC4phZA for ; Mon, 3 Aug 2015 04:06:02 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (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 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; 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=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 10.140.133.5 with SMTP id 5mr25130683qhf.84.1438599961358; Mon, 03 Aug 2015 04:06:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.62.196 with HTTP; Mon, 3 Aug 2015 04:05:41 -0700 (PDT) In-Reply-To: <55BE711C.4020501@joelhalpern.com> References: <55BE711C.4020501@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 3 Aug 2015 07:05:41 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a1135df9aabc5ad051c66277a 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 11:06:07 -0000 --001a1135df9aabc5ad051c66277a Content-Type: text/plain; charset=UTF-8 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 --001a1135df9aabc5ad051c66277a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
On Sun, Aug 2, 2015 at 3:35 PM, Joel M. Ha= lpern <jmh@joelhalpern.com> wrote:
A couple of points where I see mis-communication, in line bel= ow:

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

<= div>=C2=A0
This answer seems to miss Alia's point.= =C2=A0 Suppose that we are processing a mix of packets from multiple end-ap= plications (this seems very likely).=C2=A0 Then some of those packets will = be more important than others.=C2=A0 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 h= igher.=C2=A0 So setting everything as high between the two FEs is not a goo= d idea.

=C2=A0
How a= bout we totally remove that text? upstream LFBs will set priority
fields (which pass through the Inter-FE LFB) and down
stream LFB= s (like schedulers) will pay attention to it.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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.=C2=A0 It needs to have the r= ight contents for sending the packet to the next FE, which has nothing to d= o with the underlying Ethernet MAC header.=C2=A0 It may have to do with the= underlying priority, but specifying it as a copy of the header is not a go= od model.
2) The mechanism shoul= d be specified in such a way that it works even if we are not carrying a su= bscriber MAC header.=C2=A0 It should work with just an IP header.=C2=A0 It = should work with media other than Ethernet.=C2=A0 This mechanism is not spe= cific to external Ethernet support.=C2=A0 For example, if you are using thi= s for processing isnide a service environment, the subscribers MAC header i= s likely long gone and irrelevant.



Ok, got it ;->
=
The implementation ended dealing with Ethernet as the "raw
<= div>packet" input into IN1. As i was saying that text was direct trans= lation
from the code. So we need to fix the text.=C2=A0
And yes, I agree that it is possible there will be no ethernet frame arriv= ing
at IN1.
We would like however want to keep the ethe= rnet encapsulation=C2=A0
and not have to deal with POS for exampl= e - would that be fine?

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


Agreed.
=C2=A0
cheers,
jamal
--001a1135df9aabc5ad051c66277a-- From nobody Mon Aug 3 07:31:30 2015 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 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: References: <55BE711C.4020501@joelhalpern.com> Date: Mon, 3 Aug 2015 10:31:23 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0115f36e26086d051c690625 Archived-At: Cc: "Joel M. Halpern" , draft-ietf-forces-interfelfb@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:31:29 -0000 --089e0115f36e26086d051c690625 Content-Type: text/plain; charset=UTF-8 Hi Jamal, On Mon, Aug 3, 2015 at 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. > 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 > --089e0115f36e26086d051c690625 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jamal,

On Mon, Aug 3, 2015 at 7:05 AM, Jamal Hadi Salim <hadi@mojata= tu.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 b= elow:

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

<= div>=C2=A0
This answer seems to miss Alia's point.= =C2=A0 Suppose that we are processing a mix of packets from multiple end-ap= plications (this seems very likely).=C2=A0 Then some of those packets will = be more important than others.=C2=A0 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 h= igher.=C2=A0 So setting everything as high between the two FEs is not a goo= d idea.

=C2=A0
How about we totally remove that text? upstream LFBs will set priority
fields (which pass through the Inter-FE LFB) and down
str= eam LFBs (like schedulers) will pay attention to it.=C2=A0

Congestion control and prioritizati= on need to be addressed.=C2=A0 What I think you are missing is that it is i= mportant to clearly specify how QoS or CoS is handled so that doing an inte= r-FE mechanism doesn't break CoS.
=C2=A0
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.=C2=A0 It needs to have the r= ight contents for sending the packet to the next FE, which has nothing to d= o with the underlying Ethernet MAC header.=C2=A0 It may have to do with the= underlying priority, but specifying it as a copy of the header is not a go= od model.
2) The mechanism shoul= d be specified in such a way that it works even if we are not carrying a su= bscriber MAC header.=C2=A0 It should work with just an IP header.=C2=A0 It = should work with media other than Ethernet.=C2=A0 This mechanism is not spe= cific to external Ethernet support.=C2=A0 For example, if you are using thi= s for processing isnide a service environment, the subscribers MAC header i= s 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 direc= t translation
from the code. So we need to fix the text.=C2=A0
And yes, I agree that it is possible there will be no ethernet fram= e arriving
at IN1.
We would like however want to keep t= he ethernet encapsulation=C2=A0
and not have to deal with POS for= example - would that be fine?
Are you describing a generic packet format that can then be enc= apsulated in an Ethernet frame or IP or so on, or something which is just f= or
Ethernet? =C2=A0 You need to decide what you are documenting.<= /div>

Regards,
Alia

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


Agreed.
=C2=A0
<= div>
cheers,
jamal

--089e0115f36e26086d051c690625-- From nobody Mon Aug 3 07:51:27 2015 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 65C701A1BD1; Mon, 3 Aug 2015 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lPAyH6_bW64u; Mon, 3 Aug 2015 07:51:24 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EF61A1BBC; Mon, 3 Aug 2015 07:51:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B84201C07AB; Mon, 3 Aug 2015 07:51:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9C8A31C003B; Mon, 3 Aug 2015 07:51:20 -0700 (PDT) To: Jamal Hadi Salim , "Joel M. Halpern" References: <55BE711C.4020501@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <55BF7FE7.9060403@joelhalpern.com> Date: Mon, 3 Aug 2015 10:51:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 14:51:25 -0000 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. 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. 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 From nobody Mon Aug 3 07:52:14 2015 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 8219A1A1BB8; Mon, 3 Aug 2015 07:52:12 -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 9lNZDFokamPe; Mon, 3 Aug 2015 07:52:08 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 878E21A1BBB; Mon, 3 Aug 2015 07:52:08 -0700 (PDT) Received: by obre1 with SMTP id e1so100816182obr.1; Mon, 03 Aug 2015 07:52:08 -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=m0OPDLD9yf11+gVTHC4sc608mGn9XoUyq4Ho4sHFqss=; b=SbYM+PiTVYEONowIGvGkpYmxjptt3HkfEAg3dufdWLg0IeFkSU1ry6lReZ1BM++wKB cjN0pEHl5v6/t4i2rzVFx+jaqzQN60LHzr1FaYagVstkW7pppFW2zKdXFZ+Ezp4ZAQOK DywNvO+oxC3o74xkfwcIyFV/h9bm1QArQ1Rvd8Akyrwkidl35mIVcnOglBApZ4Y46ZqI D7Jj86OlhYMqa35WX6o5aoDy/W9Lgly1q2UNRx9Cu7RYauQBBDJ7NwZvSHHb1uUoMfb5 46UbXKT95XwMstVwm640VCsw04cA3UarQOWGErUqZ1EoUByuZL6/yHBwbOlQkmXFiKy7 Vvgw== MIME-Version: 1.0 X-Received: by 10.182.58.81 with SMTP id o17mr16639139obq.13.1438613528029; Mon, 03 Aug 2015 07:52:08 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Mon, 3 Aug 2015 07:52:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Aug 2015 10:52:07 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=e89a8f83a83b4ed5fc051c695075 Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:52:12 -0000 --e89a8f83a83b4ed5fc051c695075 Content-Type: text/plain; charset=UTF-8 Hi Jamal, On Sun, Aug 2, 2015 at 2:40 PM, Jamal Hadi Salim wrote: > Hi Alia, > > > On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas wrote: > >> Hi Damascane and Jamal, >> >> First, thank you for your work on this draft. >> >> As is customary, I have done my AD review of this draft before requesting >> IETF Last Call. >> >> > Thanks for making the time. Your effort is very much appreciated. > > > >> As part of this, I see that Evangelos, acting as Document Shepherd, found >> a number of issues that are written up in his report - and that still >> haven't been addressed two months later. Picking an IANA value that isn't >> available is one of them. I know these are editorial, but still needed. >> >> > > Sorry. > Based on the last discussions we had it didnt seem that it was worth > changing > until we got AD input (for some reason i thought it was you we discussed > this with - but likely it was Adrian; i just got back so still jetlagged). > We will make an update taking into consideration the comments from > Evangelos and yourself. > As you may understand, for an AD-sponsored draft, I do expect that the authors are extremely pro-active. Claiming that the draft is ready to progress when it is very far from that is just a way of wasting all our time - particularly when I pick up the same issues and see whether or not they've been addressed. As this draft is written, it is taking a single implementation and doesn't think through implications or the different aspects. At this time, I really don't think this draft is ready to advance. >> There are some things that are editorial or clarifications, as I >> described below. >> >> Please take some serious time and focus to improve this document if you >> want it to progress. >> >> There are two primary major issues. >> >> First, you haven't in any way justified why the inter-FE communication >> needs to be encapsulated in an Ethernet frame. Since you are asking for >> the IETF to get an EtherType allocated, that's kind of a bare minimum. >> > > We have this working over ethernet today and our scope is on ethernet > L2 networks in a private setting (because that was the charter work item). > We need the ethertype for dis-ambiguation of the frames. > We do recognize it is possible to run data across different underlying > protocols - but it seems even talking about that in the doc was unnecessary > editorializing. > A personal choice to implement it using Ethernet is not a technical justification as to why this needs to be a standard. You are asking for a limited resource - and, as Pat's email indicated, the IEEE are asking that new EtherTypes have formats that include a subtype so that reuse is possible. Are there others interested in deploying this over Ethernet? Why is it necessary to use Ethernet and not IP? > Second, the draft bounces around a lot around whether this is an >> encapsulation that is just inside Ethernet or a general encapsulation that >> can be inside IP and other things. >> > > Ok, we will review and remove any uncertainty > and just focus on ethernet. > > >> Moreover, it doesn't actually describe the reasoning or handling of the >> src/dest information and the packets. >> >> > > We will try to clarify. > > >> You really need to better describe precisely the assumptions, behaviors, >> and error handling. >> >> > Section 6 tries to cover the above. We will go over it again and fix > any gaps we can find. > > > Issues: >> >> 1) In Sec 5.1.1: "The frame may be dropped if there is congestion on >> the receiving FE side. One approach to mitigate this issue is to make sure >> that inter-FE LFB frames receive the highest priority treatment >> when scheduled on the wire." This suggestion just destroyed the >> possibility of respecting the requested CoS of the encapsulated packet and >> probably any actual high priority or EF traffic. This recommendation must >> be fixed. >> >> > > Would wording around this form help: > "The frame may be dropped if there is congestion on the receiving FE side. > To mitigate this issue is the sending FE side should treat inter-FE LFB > frames > with high priority. When 802.1p is present, then it is recommended a value > of XXX should be used. In the absence of 802.1p, implementation specific > treatments at the source FE may be used". > To your earlier point i think we need to say something like this around > section > 6 as well. > > 2) In Sec 6.1.1: One step is " create the outer ethernet header which is a >> duplicate of the >> incoming frame's ethernet header. The outer ethernet header may >> have an optional 802.1q header (if one was included in the >> original frame)." First, what if the incoming packet wasn't in an >> ethernet frame? POS does still exist. >> > > > Our intent (and deployment) is on ethernet. Clearly we need to emphasize > that view. > Do you see POS as a necessary ingredient? > You are describing what is presented as an inter-FE communication and then your text ASSUMES that the traffic is always Ethernet frames where the original Ethernet frame is still available at that point in the pipeline. This is just sloppy and not generic for no reason that I can currently understand. Second, why would the 802.1q vlan tag be relevant/valid on the outgoing >> port in between FEs? This doesn't really make sense to me. I do see the >> next bullet talks about changing the vlan tag value but nothing happens if >> the NEID is 0 or absent. >> >> > The context of this was taken directly from code;-> So something was > lost in translation. We will fix it. > > As to the relevance of the vlan tags - the idea of NEID is one of tenancy > differentiation. > But how is that connected to the inter-FE communication? > > >> 3) How can the DSTFE be optional??? Why does sending the Ethernet Frame >> to the original destination MAC address work? >> >> > You put some doubt in my mind when I read this;-> So I went and looked > at testcases. And in the majority of the policies, we do specify the DSTFE. > But there are some cases where _we dont_ and reuse the originally > target DSTFE MAC address on the outer header. > Does that explain? If not, why do you think it wont work? > Why would a random destination MAC address have anything to do with the next FE in the FE graph? Presumably, the outer encapsulation is to go from one FE to another FE in the graph. If so, then what information the packet being processed has is irrelevant. If not, then you've totally failed to explain your assumptions and purpose. > 4) In Sec 6.2, what happens if none of the optional elements of an IFEInfo >> are specified? >> > > Thanks for catching this. > There would be no such table entry allowed (and so no processed packets > will encounter this scenario). We will update the doc to indicate that > when the > CE inserts policies in the policy table - the FE MUST validate that the non > optional fields are all present (the implementation already does that). > But you made them all optional! > How can this work if there's no required way to describe the destination >> FE? >> > > Am I misunderstanding or are you are implying we need some default > DSTFE where a lookup failure happens? > Last para in 6.1.1 describes what happens on lookup failure. > > 5) From p. 22, it looks like the IFETable is defined assuming only >> transport over Ethernet. >> > > Yes - that is the intent > Why do you have text describing a more generic solution and then actually define an extremely limited one? Regards, Alia > 6) Sec 10: I think you'll find that there are security implications of >> taking packets and sending them in an Ethernet packet. Now, I realize that >> the different FEs are probably inside the same device on a private network >> - but you need to clarify why that's the case. >> >> > Yes, the scope is within the same network. We will add clarification. > > >> Minor Quibble: >> >> a) There are places where this draft talks about other documents being >> written. For instance, on the top of p.13 "For any mapping towards >> these definitions a different document to describe the mapping, one >> per transport, is expected to be defined." It's fine to have a process in >> mind - but this is completely unclear, given that the WG is closed. Are >> these documents with a well-known place on-line? Are these ISE drafts? Do >> you think these would be AD-sponsored or in rtgwg? >> >> > > We can get rid of such text altogether to avoid any confusion we are > talking about ethernet only. > > > >> b) On the bottom of p. 13, it says "In this version of the specification, >> we only focus on data and metadata. Therefore we are not going to describe >> how to carry the ExceptionID information (future versions may). " PLEASE >> go through the document and get rid of these bits of tentative and future >> language. The document is doing and defining what it is. OWN that and fix >> the language everywhere. (e.g. bottom of p.14 "would save us") >> >> > Will do. > > >> >> Nits: >> >> 1) On p. 6, "This information may include any source and >> destination information (MAC address to use, if ethernet;)" Sadly, I think >> the ;) needs to go - what about "e.g. MAC address to use, if Ethernet)". >> >> > will do. > > >> 2) In Sec. 3.1.1, the last paragraph is "The purpose of the inter-FE LFB >> is to define standard mechanisms for interconnecting FEs and for that >> reason we are not going to touch >> anymore on proprietary chip-chip interconnects other than state the >> fact they exist and that it is feasible to have translation to and >> from proprietary approaches." is a bit informal. Could you please >> clean it up a bit? >> > For instance: "This document defines the inter-FE LFB, a standard >> mechanism for interconnecting FEs. Existing proprietary approaches, such >> as chip-chip interconnects, may be able to translate to and from the >> standard inter-FE LFB." >> >> > Will do. > > >> 3) Sec 4 starts with "We address the inter-FE connectivity requirements >> by proposing the inter-FE LFB class." Remember this will be an RFC - >> please replace "proposing" with "defining". Similarly, the title of >> "Figure 6: Packet format suggestion" - is this what the document is >> standardizing or not?? >> >> > Will do. > > Thanks for the thorough review. > > cheers, > jamal > > >> Thanks, >> Alia >> >> > --e89a8f83a83b4ed5fc051c695075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jamal,

On Sun, Aug 2, 2015 at 2:40 PM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
Hi Alia,


On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas <akatl= as@gmail.com> wrote:
Hi=C2=A0Damascane and Jamal,

First, than= k you for your work on this draft.

As is customary, I have done my AD review of this draft before requesting = IETF Last Call. =C2=A0


Thanks for making the time. = Your effort is very much appreciated.

=
=C2=A0
=
As part of this, I see that Evangelos, acting= as Document Shepherd, found a number of issues that are written up in his = report - and that still haven't been addressed two months later.=C2=A0 = Picking an IANA value that isn't available is one of them.=C2=A0 I know= these are editorial, but still needed.



<= div>Sorry.
Based on the last discussions we had it didnt seem tha= t it was =C2=A0worth changing
until we got AD input (for some rea= son i thought it was you we discussed
this with - but likely it w= as Adrian; i just got back so still jetlagged).=C2=A0
We will mak= e an update taking into consideration the comments from
=C2=A0Eva= ngelos and yourself.

As you may understand, for an AD-sponsored draft, I do expect that the au= thors are extremely pro-active.
Claiming that the draft is ready = to progress when it is very far from that is just a way of wasting all our = time - particularly
when I pick up the same issues and see whethe= r or not they've been addressed.
=C2=A0
As this dra= ft is written, it is taking a single implementation and doesn't think t= hrough implications or the different aspects.

At this time, I = really don't think this draft is ready to advance.
<= div>There are some things that are editorial or clarifications, as I d= escribed below.

<= font color=3D"#000000" face=3D"PT Mono, Monaco, monospace">Please take some serious time and focus to improve this document if you= want it to progress.

There are two primary major issues.
First, you haven't in any way justified= why the inter-FE communication needs to be encapsulated in an Ethernet fra= me.=C2=A0 Since you are asking for the IETF to get an EtherType allocated, = that's kind of a bare minimum.

We have this working over ethernet today and our s= cope is on ethernet
L2 networks in a private setting (because tha= t was the charter work item).=C2=A0
We need the ethertype =C2=A0f= or dis-ambiguation of the frames.
We do recognize it is possible = to run data across different underlying
protocols - but it seems = even talking about that in the doc was unnecessary
editorializing= .

A personal choice= to implement it using Ethernet is not a technical justification as to why = this needs to be a standard.
You are asking for a limited resourc= e - and, as Pat's email indicated, the IEEE are asking that new EtherTy= pes have formats that
include a subtype so that reuse is possible= .

Are there others interested in deploying this ov= er Ethernet? =C2=A0 Why is it necessary to use Ethernet and not IP?

=C2=A0
<= div>
Second= , the draft bounces around a lot around whether this is an encapsulation th= at is just inside Ethernet or a general encapsulation that can be inside IP= and other things.

Ok, we will review and remove any uncertainty
and just f= ocus on ethernet.
=C2=A0
Moreover, it doesn't actually = describe the reasoning or handling of the src/dest information and the pack= ets.



We will try to clarify.
=C2=A0
You really need to better desc= ribe precisely the assumptions, behaviors, and error handling.


=
Section 6 tries to cover the above. We will go over it again an= d fix
any gaps we can find.

=

Is= sues:

1) In = Sec 5.1.1: =C2=A0"The frame may be dr= opped if there is congestion on the receiving=C2=A0FE side.=C2=A0 One appro= ach to mitigate this issue is to make sure that=C2=A0inter-FE LFB frames re= ceive the highest priority treatment when=C2=A0scheduled on the wire."= =C2=A0This suggestion just destroyed the possibility of respecting the req= uested CoS of the encapsulated packet and probably any actual high priority= or EF traffic. =C2=A0 This recommendation must be fixed.



Would wordi= ng around this form help:
"The frame may be= dropped if there is congestion on the receiving FE side.=C2=A0
To mitigate this issue is the sending FE side should treat inter-FE L= FB frames
with high priority. When 802.1p is present, then it is = recommended a value
of XXX should be used. In the absence of 802.= 1p, implementation specific
treatments at the source FE may be us= ed".
To your earlier point i think we need to say something = like this around section
6 as well.
2) = In Sec 6.1.1: One step is "=C2=A0create the outer ethernet header whic= h is a duplicate of the
=C2=A0 =C2=A0 =C2=A0 incoming frame's ethern= et header.=C2=A0 The outer ethernet header may
=C2=A0 =C2=A0 =C2=A0 have= an optional 802.1q header (if one was included in the
=C2=A0 =C2=A0 =C2= =A0 original frame)." =C2=A0First, what if the incoming packet wasn= 9;t in an ethernet frame?=C2=A0 POS does still exist.=C2=A0


Our intent (and deployme= nt) =C2=A0is on ethernet. Clearly we need to emphasize
that view.=
Do you see POS as a necessary ingredient?

You are describing what is presented as a= n inter-FE communication and then your text ASSUMES that the
traf= fic is always Ethernet frames where the original Ethernet frame is still av= ailable at that point in the pipeline.
This is just sloppy and no= t generic for no reason that I can currently understand.=C2=A0
Second, why would the 802.1q vlan tag be rel= evant/valid on the outgoing port in between FEs? =C2=A0 This doesn't re= ally make sense to me.=C2=A0 I do see the next bullet talks about changing = the vlan tag value but nothing happens if the NEID is 0 or absent.


The context of th= is was taken directly from code;-> So something was
lost in tr= anslation. We will fix it.

As to the relevance of = the vlan tags - the idea of NEID is one of tenancy
differentiatio= n.
<= div>
But how is that connected to the inter-FE communication?= =C2=A0
=C2=A0
<= div>=C2=A0
=
3) How can the DSTFE be optional???=C2=A0 Why does sending the Etherne= t Frame to the original destination MAC address work?


You put some doubt in my mind when I read= this;-> So I went and looked
at testcases. And in the majorit= y of the policies, we do specify the DSTFE.
But there are some ca= ses where _we dont_ and reuse the originally
target DSTFE MAC add= ress on the outer header.
Does that explain? If not, why do you t= hink it wont work?=C2=A0

Why would a random destination MAC address have anything to do with t= he next FE in the FE graph?

Presumably, the outer = encapsulation is to go from one FE to another FE in the graph.=C2=A0 If so,= then what
information the packet being processed has is irreleva= nt.=C2=A0 If not, then you've totally failed to explain your
= assumptions and purpose.

=C2=A0
4) In Sec 6.2, what happens if none of the optional elements= of an IFEInfo are specified?

Thanks for catching this.
There would be no such table entry all= owed (and so no processed packets
will encounter this scenario). = We will update the doc to indicate that when the
CE inserts polic= ies in the policy table - the FE MUST validate that the non
optio= nal fields are all present (the implementation already does that).

But you made them all optio= nal! =C2=A0=C2=A0
=C2=A0
How can this work = if there's no required way to describe the destination FE?

Am I misunderstanding or are you are imply= ing we need some default
DSTFE where a lookup failure happens?
Last para in 6.1.1 describes what happens on lookup failure.
<= span class=3D"">

5) From p. 22, it looks like the IFETable is defin= ed assuming only transport over Ethernet.

Yes - that is the intent
<= /div>

Why do you have text describing a mor= e generic solution and then actually define an extremely limited one?
=

Regards,
Alia
=C2=A0
<= span style=3D"font-size:14px;line-height:16.996000289917px;background-color= :rgb(255,253,245)">6) Sec 10: =C2=A0I think you'll find that there are = security implications of taking packets and sending them in an Ethernet pac= ket.=C2=A0 Now, I realize that the different FEs are probably inside the sa= me device on a private network - but you need to clarify why that's the= case.


Yes, the scope is within the same network. W= e will add clarification.
=C2=A0
Minor Quibble:

a) There are places whe= re this draft talks about other documents being written.=C2=A0 For instance= , on the top of p.13 "For any mapping towards these definit= ions a different=C2=A0 =C2=A0document to describe the mapping, one p= er transport, is expected to=C2=A0be defined." =C2=A0It's fine to = have a process in mind - but this is completely unclear, given that the WG = is closed.=C2=A0 Are these documents with a well-known place on-line?=C2=A0= Are these ISE drafts?=C2=A0 Do you think these would be AD-sponsored or in= rtgwg?



We can get rid of such text altogether to avoid any confusion we are
talking about ethernet only.

=C2=A0
b) On the bo= ttom of p. 13, it says "In this version of the specification, we only = focus on data and metadata.=C2=A0 Therefore we are not going to describe ho= w to carry the ExceptionID information (future versions may). " =C2=A0= PLEASE go through the document and get rid of these bits of tentative and = future language.=C2=A0 The document is doing and defining what it is.=C2=A0= OWN that and fix the language everywhere. =C2=A0(e.g. bottom of p.14 "= ;would save us")


Will do.
=C2=A0

Nits:

1) On p. 6, "This information may include any source and d= estination=C2=A0information (MAC address to use, if ethernet;)" =C2=A0= Sadly, I think the ;) needs to go - what about "e.g. MAC address to us= e, if Ethernet)".


will do.
=C2=A0
2) In Sec. 3.1.1, t= he last paragraph is=C2=A0"The purpose of the inter-FE LFB is to defin= e standard mechanisms for=C2=A0interconnecting FEs and for that reason we a= re not going to touch
=C2=A0 =C2=A0anymore on proprietary chip-chip inte= rconnects other than state the
=C2=A0 =C2=A0fact they exist and that it = is feasible to have translation to and
=C2=A0 =C2=A0from proprietary app= roaches." =C2=A0is a bit informal.=C2=A0 Could you please clean it up = a bit?=C2=A0
<= div dir=3D"ltr">
For instance: =C2=A0"This documen= t defines the inter-FE LFB, a standard mechanism for interconnecting FEs.= =C2=A0 Existing proprietary approaches, such as chip-chip interconnects, ma= y be able to translate to and from the standard inter-FE LFB."

Will do.
=C2=A0
=
3) Sec 4 starts with "We address the inter-FE connectivity requir= ements by proposing the=C2=A0inter-FE LFB class." =C2=A0Remember this = will be an RFC - please replace "proposing" with "defining&q= uot;.=C2=A0 Similarly, the title of "Figure 6: Packet format suggestio= n" - is this what the document is standardizing or not??


Will do.
Thanks for the thorough review.

cheers= ,
jamal
=C2=A0
Thanks,
Alia



--e89a8f83a83b4ed5fc051c695075-- From nobody Mon Aug 3 15:14:29 2015 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 247CF1B2D0F for ; Mon, 3 Aug 2015 15:14:28 -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=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 c9ZQDqEDvp6m for ; Mon, 3 Aug 2015 15:14:24 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 E01B91A00AE for ; Mon, 3 Aug 2015 15:14:23 -0700 (PDT) Received: by qged69 with SMTP id d69so99239198qge.0 for ; Mon, 03 Aug 2015 15:14:23 -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=zXYd8qukvsj4X+0aRhVArv6FsB+VnljXPMbaHpu7lDc=; b=SRuE26xejJy7kmfC7kr4ivPmneyXOf08nf5RdRxX/zXYFR6mli4oZUqNcfEuS23A+x hjOv+eNleork/skXFTXePADcaXrTKnik2AMs9ZW4UUEFLBbIp68TEq9h7ASB6KHb5V+e chRr9AGguPeWJvRfPbaxXeuW2HLuYC/RlTOMTViV69IIBx55geKoNC3oUXofeuN0Cw9C /GehczwA2f3q6KmdBIsBtuy2GmZfgqMSH2VG/0t2Q8RSYhvsq537paIjvwyLqeuW6Lfq eGs7y6oFAjR3SUuiTQadoO/md83U2U8VpkgDhwECumZF0y+kfxlVdK+4++rr7g1YzKyX JGRw== X-Gm-Message-State: ALoCoQnzV1AP7l/O4lEus2KhOjSg/EF1z5gZmerkxoz0Zqx41EVNMdSiO1itgpmsFAQtuwbksh6m X-Received: by 10.140.133.5 with SMTP id 5mr1075523qhf.84.1438640062997; Mon, 03 Aug 2015 15:14:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.62.196 with HTTP; Mon, 3 Aug 2015 15:14:03 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Mon, 3 Aug 2015 18:14:03 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a1135df9aea448c051c6f7dc0 Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 22:14:28 -0000 --001a1135df9aea448c051c6f7dc0 Content-Type: text/plain; charset=UTF-8 Alia, You raise legit issues. We will work on putting out a new version in the next day or two which will hopefully address all the issues you brought up by being more focussed. Thanks for your patience. cheers, jamal On Mon, Aug 3, 2015 at 10:52 AM, Alia Atlas wrote: > Hi Jamal, > > On Sun, Aug 2, 2015 at 2:40 PM, Jamal Hadi Salim > wrote: > >> Hi Alia, >> >> >> On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas wrote: >> >>> Hi Damascane and Jamal, >>> >>> First, thank you for your work on this draft. >>> >>> As is customary, I have done my AD review of this draft before >>> requesting IETF Last Call. >>> >>> >> Thanks for making the time. Your effort is very much appreciated. >> >> >> >>> As part of this, I see that Evangelos, acting as Document Shepherd, >>> found a number of issues that are written up in his report - and that still >>> haven't been addressed two months later. Picking an IANA value that isn't >>> available is one of them. I know these are editorial, but still needed. >>> >>> >> >> Sorry. >> Based on the last discussions we had it didnt seem that it was worth >> changing >> until we got AD input (for some reason i thought it was you we discussed >> this with - but likely it was Adrian; i just got back so still >> jetlagged). >> We will make an update taking into consideration the comments from >> Evangelos and yourself. >> > > As you may understand, for an AD-sponsored draft, I do expect that the > authors are extremely pro-active. > Claiming that the draft is ready to progress when it is very far from that > is just a way of wasting all our time - particularly > when I pick up the same issues and see whether or not they've been > addressed. > > As this draft is written, it is taking a single implementation and doesn't > think through implications or the different aspects. > > At this time, I really don't think this draft is ready to advance. >>> There are some things that are editorial or clarifications, as I >>> described below. >>> >>> Please take some serious time and focus to improve this document if you >>> want it to progress. >>> >>> There are two primary major issues. >>> >>> First, you haven't in any way justified why the inter-FE communication >>> needs to be encapsulated in an Ethernet frame. Since you are asking for >>> the IETF to get an EtherType allocated, that's kind of a bare minimum. >>> >> >> We have this working over ethernet today and our scope is on ethernet >> L2 networks in a private setting (because that was the charter work >> item). >> We need the ethertype for dis-ambiguation of the frames. >> We do recognize it is possible to run data across different underlying >> protocols - but it seems even talking about that in the doc was >> unnecessary >> editorializing. >> > > A personal choice to implement it using Ethernet is not a technical > justification as to why this needs to be a standard. > You are asking for a limited resource - and, as Pat's email indicated, the > IEEE are asking that new EtherTypes have formats that > include a subtype so that reuse is possible. > > Are there others interested in deploying this over Ethernet? Why is it > necessary to use Ethernet and not IP? > > > >> Second, the draft bounces around a lot around whether this is an >>> encapsulation that is just inside Ethernet or a general encapsulation that >>> can be inside IP and other things. >>> >> >> Ok, we will review and remove any uncertainty >> and just focus on ethernet. >> >> >>> Moreover, it doesn't actually describe the reasoning or handling of the >>> src/dest information and the packets. >>> >>> >> >> We will try to clarify. >> >> >>> You really need to better describe precisely the assumptions, behaviors, >>> and error handling. >>> >>> >> Section 6 tries to cover the above. We will go over it again and fix >> any gaps we can find. >> >> >> Issues: >>> >>> 1) In Sec 5.1.1: "The frame may be dropped if there is congestion on >>> the receiving FE side. One approach to mitigate this issue is to make sure >>> that inter-FE LFB frames receive the highest priority treatment >>> when scheduled on the wire." This suggestion just destroyed the >>> possibility of respecting the requested CoS of the encapsulated packet and >>> probably any actual high priority or EF traffic. This recommendation must >>> be fixed. >>> >>> >> >> Would wording around this form help: >> "The frame may be dropped if there is congestion on the receiving FE >> side. >> To mitigate this issue is the sending FE side should treat inter-FE LFB >> frames >> with high priority. When 802.1p is present, then it is recommended a value >> of XXX should be used. In the absence of 802.1p, implementation specific >> treatments at the source FE may be used". >> To your earlier point i think we need to say something like this around >> section >> 6 as well. >> >> 2) In Sec 6.1.1: One step is " create the outer ethernet header which is >>> a duplicate of the >>> incoming frame's ethernet header. The outer ethernet header may >>> have an optional 802.1q header (if one was included in the >>> original frame)." First, what if the incoming packet wasn't in an >>> ethernet frame? POS does still exist. >>> >> >> >> Our intent (and deployment) is on ethernet. Clearly we need to emphasize >> that view. >> Do you see POS as a necessary ingredient? >> > > You are describing what is presented as an inter-FE communication and then > your text ASSUMES that the > traffic is always Ethernet frames where the original Ethernet frame is > still available at that point in the pipeline. > This is just sloppy and not generic for no reason that I can currently > understand. > > Second, why would the 802.1q vlan tag be relevant/valid on the outgoing >>> port in between FEs? This doesn't really make sense to me. I do see the >>> next bullet talks about changing the vlan tag value but nothing happens if >>> the NEID is 0 or absent. >>> >>> >> The context of this was taken directly from code;-> So something was >> lost in translation. We will fix it. >> >> As to the relevance of the vlan tags - the idea of NEID is one of tenancy >> differentiation. >> > > But how is that connected to the inter-FE communication? > > >> >> >>> 3) How can the DSTFE be optional??? Why does sending the Ethernet Frame >>> to the original destination MAC address work? >>> >>> >> You put some doubt in my mind when I read this;-> So I went and looked >> at testcases. And in the majority of the policies, we do specify the >> DSTFE. >> But there are some cases where _we dont_ and reuse the originally >> target DSTFE MAC address on the outer header. >> Does that explain? If not, why do you think it wont work? >> > > Why would a random destination MAC address have anything to do with the > next FE in the FE graph? > > Presumably, the outer encapsulation is to go from one FE to another FE in > the graph. If so, then what > information the packet being processed has is irrelevant. If not, then > you've totally failed to explain your > assumptions and purpose. > > > >> 4) In Sec 6.2, what happens if none of the optional elements of an >>> IFEInfo are specified? >>> >> >> Thanks for catching this. >> There would be no such table entry allowed (and so no processed packets >> will encounter this scenario). We will update the doc to indicate that >> when the >> CE inserts policies in the policy table - the FE MUST validate that the >> non >> optional fields are all present (the implementation already does that). >> > > But you made them all optional! > > >> How can this work if there's no required way to describe the destination >>> FE? >>> >> >> Am I misunderstanding or are you are implying we need some default >> DSTFE where a lookup failure happens? >> Last para in 6.1.1 describes what happens on lookup failure. >> >> 5) From p. 22, it looks like the IFETable is defined assuming only >>> transport over Ethernet. >>> >> >> Yes - that is the intent >> > > Why do you have text describing a more generic solution and then actually > define an extremely limited one? > > Regards, > Alia > > >> 6) Sec 10: I think you'll find that there are security implications of >>> taking packets and sending them in an Ethernet packet. Now, I realize that >>> the different FEs are probably inside the same device on a private network >>> - but you need to clarify why that's the case. >>> >>> >> Yes, the scope is within the same network. We will add clarification. >> >> >>> Minor Quibble: >>> >>> a) There are places where this draft talks about other documents being >>> written. For instance, on the top of p.13 "For any mapping towards >>> these definitions a different document to describe the mapping, one >>> per transport, is expected to be defined." It's fine to have a process in >>> mind - but this is completely unclear, given that the WG is closed. Are >>> these documents with a well-known place on-line? Are these ISE drafts? Do >>> you think these would be AD-sponsored or in rtgwg? >>> >>> >> >> We can get rid of such text altogether to avoid any confusion we are >> talking about ethernet only. >> >> >> >>> b) On the bottom of p. 13, it says "In this version of the >>> specification, we only focus on data and metadata. Therefore we are not >>> going to describe how to carry the ExceptionID information (future versions >>> may). " PLEASE go through the document and get rid of these bits of >>> tentative and future language. The document is doing and defining what it >>> is. OWN that and fix the language everywhere. (e.g. bottom of p.14 "would >>> save us") >>> >>> >> Will do. >> >> >>> >>> Nits: >>> >>> 1) On p. 6, "This information may include any source and >>> destination information (MAC address to use, if ethernet;)" Sadly, I think >>> the ;) needs to go - what about "e.g. MAC address to use, if Ethernet)". >>> >>> >> will do. >> >> >>> 2) In Sec. 3.1.1, the last paragraph is "The purpose of the inter-FE LFB >>> is to define standard mechanisms for interconnecting FEs and for that >>> reason we are not going to touch >>> anymore on proprietary chip-chip interconnects other than state the >>> fact they exist and that it is feasible to have translation to and >>> from proprietary approaches." is a bit informal. Could you please >>> clean it up a bit? >>> >> For instance: "This document defines the inter-FE LFB, a standard >>> mechanism for interconnecting FEs. Existing proprietary approaches, such >>> as chip-chip interconnects, may be able to translate to and from the >>> standard inter-FE LFB." >>> >>> >> Will do. >> >> >>> 3) Sec 4 starts with "We address the inter-FE connectivity requirements >>> by proposing the inter-FE LFB class." Remember this will be an RFC - >>> please replace "proposing" with "defining". Similarly, the title of >>> "Figure 6: Packet format suggestion" - is this what the document is >>> standardizing or not?? >>> >>> >> Will do. >> >> Thanks for the thorough review. >> >> cheers, >> jamal >> >> >>> Thanks, >>> Alia >>> >>> >> > --001a1135df9aea448c051c6f7dc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alia,

You raise legit issues. We will work on= putting out a new version
in the next day or two which will hope= fully address all the issues you=C2=A0
brought up by being more f= ocussed. Thanks for your patience.

cheers,
jamal

On Mon, Aug 3, 2015 at 10:52 AM, Alia Atlas <= akatlas@gmail.com> wrote:
Hi J= amal,

On Sun, Aug = 2, 2015 at 2:40 PM, Jamal Hadi Salim <hadi@mojatatu.com> wro= te:
Hi Alia,


On Fri, = Jul 31, 2015 at 6:08 PM, Alia Atlas <akatlas@gmail.com> wrot= e:
Hi=C2=A0Damascane and = Jamal,

First, thank you for your work on this dr= aft.

As is customary, I have done = my AD review of this draft before requesting IETF Last Call. =C2=A0<= /font>


<= /div>
Thanks for making the time. Your effort is very much appre= ciated.

=C2=A0
As part of = this, I see that Evangelos, acting as Document Shepherd, found a number of = issues that are written up in his report - and that still haven't been = addressed two months later.=C2=A0 Picking an IANA value that isn't avai= lable is one of them.=C2=A0 I know these are editorial, but still needed.



Sorry.
Based on the last di= scussions we had it didnt seem that it was =C2=A0worth changing
u= ntil we got AD input (for some reason i thought it was you we discussed
this with - but likely it was Adrian; i just got back so still jetla= gged).=C2=A0
We will make an update taking into consideration the= comments from
=C2=A0Evangelos and yourself.

As you may understand, for an AD-sponso= red draft, I do expect that the authors are extremely pro-active.
Claiming that the draft is ready to progress when it is very far from that= is just a way of wasting all our time - particularly
when I pick= up the same issues and see whether or not they've been addressed.
=C2=A0
As this draft is written, it is taking a single impl= ementation and doesn't think through implications or the different aspe= cts.

At this time, I really don't think this draft is ready to adva= nce.
There are some things that are editorial = or clarifications, as I described below.

<= /span>
Please take some serious time and focus to imp= rove this document if you want it to progress.

There are two primary major issues.

First, you haven&#= 39;t in any way justified why the inter-FE communication needs to be encaps= ulated in an Ethernet frame.=C2=A0 Since you are asking for the IETF to get= an EtherType allocated, that's kind of a bare minimum.

We have this working over= ethernet today and our scope is on ethernet
L2 networks in a pri= vate setting (because that was the charter work item).=C2=A0
We n= eed the ethertype =C2=A0for dis-ambiguation of the frames.
We do = recognize it is possible to run data across different underlying
= protocols - but it seems even talking about that in the doc was unnecessary=
editorializing.

A personal choice to implement it using Ethernet is not a technical= justification as to why this needs to be a standard.
You are ask= ing for a limited resource - and, as Pat's email indicated, the IEEE ar= e asking that new EtherTypes have formats that
include a subtype = so that reuse is possible.

Are there others intere= sted in deploying this over Ethernet? =C2=A0 Why is it necessary to use Eth= ernet and not IP?

=C2=A0
Second, the draft bounces around a lot around whether this is an e= ncapsulation that is just inside Ethernet or a general encapsulation that c= an be inside IP and other things.

Ok, we will review and remove any uncertainty
=
and just focus on ethernet.
=C2=A0
Moreover, it doesn't actual= ly describe the reasoning or handling of the src/dest information and the p= ackets.



We will try to clarify.
=C2=A0
You really need to better describe p= recisely the assumptions, behaviors, and error handling.


Section 6 tries to cover the above. We will go over it again and fix<= /div>
any gaps we can find.


Issues:

1) In Sec 5.1.1: =C2=A0= <= span style=3D"font-size:14px;line-height:16.996000289917px;background-color= :rgb(255,253,245)">"The frame may be dropped if there is= congestion on the receiving=C2=A0FE side.=C2=A0 One approach to mitigate t= his issue is to make sure that=C2=A0inter-FE LFB frames receive the highest= priority treatment when=C2=A0scheduled on the wire." =C2=A0This sugge= stion just destroyed the possibility of respecting the requested CoS of the= encapsulated packet and probably any actual high priority or EF traffic. = =C2=A0 This recommendation must be fixed.



Would wording around this f= orm help:
"The frame may be dropped if there is conges= tion on the receiving FE side.=C2=A0
To mitigate this issu= e is the sending FE side should treat inter-FE LFB frames
with hi= gh priority. When 802.1p is present, then it is recommended a value
of XXX should be used. In the absence of 802.1p, implementation specific=
treatments at the source FE may be used".
To your= earlier point i think we need to say something like this around section
6 as well.

2) In Sec 6.1.1: One step is "=C2=A0= create the outer ethernet header which is a duplicate of the
=C2=A0 =C2= =A0 =C2=A0 incoming frame's ethernet header.=C2=A0 The outer ethernet h= eader may
=C2=A0 =C2=A0 =C2=A0 have an optional 802.1q header (if one wa= s included in the
=C2=A0 =C2=A0 =C2=A0 original frame)." =C2=A0Firs= t, what if the incoming packet wasn't in an ethernet frame?=C2=A0 POS d= oes still exist.=C2=A0


Our intent (and deployment) =C2=A0is on ethernet. Clearly we = need to emphasize
that view.
Do you see POS as a necess= ary ingredient?

You= are describing what is presented as an inter-FE communication and then you= r text ASSUMES that the
traffic is always Ethernet frames where t= he original Ethernet frame is still available at that point in the pipeline= .
This is just sloppy and not generic for no reason that I can cu= rrently understand.=C2=A0

Second, why would= the 802.1q vlan tag be relevant/valid on the outgoing port in between FEs?= =C2=A0 This doesn't really make sense to me.=C2=A0 I do see the next b= ullet talks about changing the vlan tag value but nothing happens if the NE= ID is 0 or absent.


The context of this was taken directly from code;-> So somethi= ng was
lost in translation. We will fix it.

<= div>As to the relevance of the vlan tags - the idea of NEID is one of tenan= cy
differentiation.

But how is that connected to the inter-F= E communication? =C2=A0
=C2=A0
=C2=A0
<= /div>
3) How can the DSTFE be optional???=C2=A0 Why does sending the Et= hernet Frame to the original destination MAC address work?

<= /blockquote>

You put some doubt in my mind when I= read this;-> So I went and looked
at testcases. And in the ma= jority of the policies, we do specify the DSTFE.
But there are so= me cases where _we dont_ and reuse the originally
target DSTFE MA= C address on the outer header.
Does that explain? If not, why do = you think it wont work?=C2=A0

=
Why would a random destination MAC address have anything to do w= ith the next FE in the FE graph?

Presumably, the o= uter encapsulation is to go from one FE to another FE in the graph.=C2=A0 I= f so, then what
information the packet being processed has is irr= elevant.=C2=A0 If not, then you've totally failed to explain your
=
assumptions and purpose.

=C2=A0
4) In Sec 6.2, what happens if none of the optional elements of an= IFEInfo are specified?

Thank= s for catching this.
There would be no such table entry allowed (= and so no processed packets
will encounter this scenario). We wil= l update the doc to indicate that when the
CE inserts policies in= the policy table - the FE MUST validate that the non
optional fi= elds are all present (the implementation already does that).

But you made them all optional! = =C2=A0=C2=A0
=C2=A0
How can this work if there's = no required way to describe the destination FE?

=
Am I misunderstanding or are you are implying we need som= e default
DSTFE where a lookup failure happens?
Last pa= ra in 6.1.1 describes what happens on lookup failure.

<= /div>
5= ) From p. 22, it looks like the IFETable is defined assuming only transport= over Ethernet.

Yes - that is the intent
Why do you have text describing a more generic solution and the= n actually define an extremely limited one?

Regard= s,
Alia
=C2=A0
6) Sec 10: =C2=A0I = think you'll find that there are security implications of taking packet= s and sending them in an Ethernet packet.=C2=A0 Now, I realize that the dif= ferent FEs are probably inside the same device on a private network - but y= ou need to clarify why that's the case.

Yes, th= e scope is within the same network. We will add clarification.
<= div>=C2=A0
M= inor Quibble:

For any mapp= ing towards these definitions a different=C2=A0 =C2=A0document to de= scribe the mapping, one per transport, is expected to=C2=A0be defined."= ; =C2=A0It's fine to have a process in mind - but this is completely un= clear, given that the WG is closed.=C2=A0 Are these documents with a well-k= nown place on-line?=C2=A0 Are these ISE drafts?=C2=A0 Do you think these wo= uld be AD-sponsored or in rtgwg?



We can get rid of such text altogether to avoid= any confusion we are
talking about ethernet only.

=C2=A0
b) On the bottom of p. 13, it says "In this version of the specifica= tion, we only focus on data and metadata.=C2=A0 Therefore we are not going = to describe how to carry the ExceptionID information (future versions may).= " =C2=A0 PLEASE go through the document and get rid of these bits of = tentative and future language.=C2=A0 The document is doing and defining wha= t it is.=C2=A0 OWN that and fix the language everywhere. =C2=A0(e.g. bottom= of p.14 "would save us")

<= br>
Will do.
=C2=A0

Nits:

1) On p. 6, "This information may include any source an= d destination=C2=A0information (MAC address to use, if ethernet;)" =C2= =A0Sadly, I think the ;) needs to go - what about "e.g. MAC address to= use, if Ethernet)".


<= /div>
will do.
=C2=A0
2) In Sec. 3.1.1, the last = paragraph is=C2=A0"The purpose of the inter-FE LFB is to define standa= rd mechanisms for=C2=A0interconnecting FEs and for that reason we are not g= oing to touch
=C2=A0 =C2=A0anymore on proprietary chip-chip interconnect= s other than state the
=C2=A0 =C2=A0fact they exist and that it is feasi= ble to have translation to and
=C2=A0 =C2=A0from proprietary approaches.= " =C2=A0is a bit informal.=C2=A0 Could you please clean it up a bit?= =C2=A0
For instance: =C2=A0"This document defi= nes the inter-FE LFB, a standard mechanism for interconnecting FEs.=C2=A0 E= xisting proprietary approaches, such as chip-chip interconnects, may be abl= e to translate to and from the standard inter-FE LFB."

=

Will do.
=C2= =A0
3) Sec 4 star= ts with "We address the inter-FE connectivity requirements by proposin= g the=C2=A0inter-FE LFB class." =C2=A0Remember this will be an RFC - p= lease replace "proposing" with "defining".=C2=A0 Simila= rly, the title of "Figure 6: Packet format suggestion" - is this = what the document is standardizing or not??


Will do.

Thanks= for the thorough review.

cheers,
jamal<= /div>
=C2=A0
=
Thanks,
Alia




--001a1135df9aea448c051c6f7dc0-- From nobody Mon Aug 3 15:17:13 2015 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 445F11B31CA; Mon, 3 Aug 2015 15:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 2gavxCYTBhxD; Mon, 3 Aug 2015 15:17:10 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 B16B61A00E3; Mon, 3 Aug 2015 15:17:09 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so124594359wic.1; Mon, 03 Aug 2015 15:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=zu7TdsUokJGK6CPEFXaxLeuy6hHJEup8kIkVSFt6Ne4=; b=b2EecDaJAci1kI7rraFYbalWYHpeqkhWZTqmgRoIhi3dkfWz0DefTYO+9yiQzCjHNf aiwcDCGds6ZRu0nPx4PaYalc7PnSmWwnjiZTdpVcuY6l7mlKFrLPErGKLlnreJPgU4EJ /g8/pDw/TV+ixBC0egnm/8xRgAKaV/E4EyVeKqBwDxsVnsTxrk07AvdJxIU9foDPDuW8 vWOht7qeAyBEhi2iz4279uHwbJe4Yg1IfNvSkmxBgcSMv0N02yv7GqLOL+bsHyGBdQsJ XA+4ufyuPQ3cgiUkmrBBMAEDSM6vV6+G92A2TNHoFWDaYSubztEbfX3aNCopRdx7hram rDmw== X-Received: by 10.180.24.40 with SMTP id r8mr856893wif.13.1438640228366; Mon, 03 Aug 2015 15:17:08 -0700 (PDT) Received: from EhalepXPS (ppp079166137043.access.hol.gr. [79.166.137.43]) by smtp.gmail.com with ESMTPSA id ft5sm15638406wib.4.2015.08.03.15.17.06 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Aug 2015 15:17:07 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Alia Atlas'" , , References: In-Reply-To: Date: Tue, 4 Aug 2015 01:17:05 +0300 Message-ID: <010501d0ce3a$2211c7c0$66355740$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01D0CE53.475EFFC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDLybpo5ASamEFGTOCbYyohASIHVgCcB4yg Content-Language: el Archived-At: Cc: "'Joel M. Halpern'" Subject: Re: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-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:17:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0106_01D0CE53.475EFFC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings Alia, =20 Thank you very much for your review. Please see inline. =20 Regards, Evangelos. =20 From: forces [mailto:forces-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Friday, July 31, 2015 10:47 PM To: draft-ietf-forces-lfb-subsidiary-management@ietf.org; = forces@ietf.org Cc: Joel M. Halpern Subject: [forces] AD review of = draft-ietf-forces-lfb-subsidiary-management-01 =20 Hi Bhumip, Evangelos, and Jamal, Thanks for your work on this draft. As is customary, I have done my AD = review of the draft before asking that it go forward to IETF Last Call. I have only a few quibbles, so I have advanced this to IETF Last Call. = It is on the IESG telechat on Sept 3. Please do respond and update = the draft during IETF Last Call. As you well know, having authors who = are extremely responsive helps greatly with getting these final steps = done. Minor quibbles: 1) In Sec. 4.4.3, two of the capabilities are described as placeholders. = Can you please clarify what the expected standardized behavior is? I = imagine that the capabilities are filled out as described - though with = unstandardized information. [=CE=95=CE=97] Yes. These parameters are placeholders for future use, in = order not to redefine the LFB class versions. These are simple strings = that define either the attribute names, and the parameters. These should = be read by the CE to know what kind of attributes and parameters it can = safely use. If this is ok, we=E2=80=99ll try to add such text in the = document. 2) In Sec. 4.2, could you please provide a reference to the syslog = severity levels? For instance, the IANA registry = (http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtm= l#syslog-parameters-2 ) and/or RFC 3164 would be lovely. =20 [=CE=95=CE=97] Thank you. We=E2=80=99ll certainly add the references. 3) In the Security Considerations section, a few words about why it is = ok to trust a CE to create a connection to another CE would be useful. =20 =20 [=CE=95=CE=97] The CE that creates these connections could either be: A. The FE manager which is the one responsible for creating these = connections, therefore the FE should trust it. B. An already associated and trusted CE. This document has no effect on the ForCES protocol security. Therefore, = as the CE in question is already the master it should be trusted to = create the connections. Such security issues should concern the CE. If = the CE is faulty, rogue or hacked, there is no way for the FE to know = and will perform any action that the CE requests. =20 We can add this text (or something very similar) to the Security = considerations. =20 Thanks, Alia ------=_NextPart_000_0106_01D0CE53.475EFFC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Greetings Alia,

 

Thank you very much for your review.

Please see inline.

 

Regards,

Evangelos.

 

From:= forces = [mailto:forces-bounces@ietf.org] On Behalf Of Alia = Atlas
Sent: Friday, July 31, 2015 10:47 PM
To: = draft-ietf-forces-lfb-subsidiary-management@ietf.org; = forces@ietf.org
Cc: Joel M. Halpern
Subject: = [forces] AD review of = draft-ietf-forces-lfb-subsidiary-management-01

 

Hi Bhumip, Evangelos, and Jamal,

Thanks for = your work on this draft. As is customary, I have done my AD review of = the draft before asking that it go forward to IETF Last Call.

I = have only a few quibbles, so I have advanced this to IETF Last = Call.  It is on the IESG telechat on Sept 3.    Please do = respond and update the draft during IETF Last Call.  As you well = know, having authors who are extremely responsive helps greatly with = getting these final steps done.

Minor quibbles:

1) In Sec. = 4.4.3, two of the capabilities are described as placeholders.  Can = you please clarify what the expected standardized behavior is?  I = imagine that the capabilities are filled out as described - though with = unstandardized information.

[=CE=95=CE=97] Yes. These parameters are placeholders for future use, in order not = to redefine the LFB class versions. These are simple strings that define = either the attribute names, and the parameters. These should be read by = the CE to know what kind of attributes and parameters it can safely use. = If this is ok, we=E2=80=99ll try to add such text in the = document.


2) In Sec. 4.2, could you please provide a reference to = the syslog severity levels?  For instance, the IANA registry = (http://www.iana.org/assignments/syslog-para= meters/syslog-parameters.xhtml#syslog-parameters-2 ) and/or RFC 3164 = would be lovely.  

[=CE=95=CE=97] Thank you. We=E2=80=99ll certainly add the = references.


3) In the Security Considerations section, a few words = about why it is ok to trust a CE to create a connection to another CE = would be useful.  

 

[=CE=95=CE=97] The CE that creates these connections could either = be:

A.      = The FE manager which is the one responsible for creating these = connections, therefore the FE should trust it.

B.      = An already associated and trusted CE.

This document has no effect on the ForCES protocol security. = Therefore, as the CE in question is already the master it should be = trusted to create the connections. Such security issues should concern = the CE. If the CE is faulty, rogue or hacked, there is no way for the FE = to know and will perform any action that the CE = requests.

 

We can add this text (or something very similar) to the Security = considerations.

 

Thanks,

Alia

------=_NextPart_000_0106_01D0CE53.475EFFC0-- From nobody Mon Aug 3 15:24:36 2015 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-- From nobody Mon Aug 3 16:05:03 2015 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 8F5DD1B31B2; Mon, 3 Aug 2015 16:05:02 -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 xHKDgWutPBAG; Mon, 3 Aug 2015 16:04:58 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 EC70C1B3119; Mon, 3 Aug 2015 16:04:57 -0700 (PDT) Received: by obdeg2 with SMTP id eg2so110459157obd.0; Mon, 03 Aug 2015 16:04:57 -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=Vj2wKyX7HX8ZiGZMYwqbqYklEMcV8NlehRFX1z3GA7w=; b=IRHNjG1WAdUZDeHjT16FYxfT9lMFqm6Zq0kdPlXNty5KqOOtDbzgTe2rL9QGVZbikN ykBgn27rtKETNrVczoFqlUjJ1Hq/m3T/6L30tIe6uUcrV/9Rp8wA1aqzBDutqSfbJqA6 AtdIQrNhOuWXT3ooMgLmXAOb5HNScUL11YaSnASvYADTHExSuUzf8YT7eKU4OTvoS5s7 Ln93vgs45pNev5nQ5FyKBjyoIzdKdS9aZBcNYnl9W7HaoSweHph1qprDffusrVBbj77l b7bESv0CYmN+F+EN9jG7w09Xzj3lJrK6tj4j3t03pHg/xJ03+kVQBR+OC37v/ga9rpvq vpRQ== MIME-Version: 1.0 X-Received: by 10.60.141.135 with SMTP id ro7mr408090oeb.13.1438643097252; Mon, 03 Aug 2015 16:04:57 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Mon, 3 Aug 2015 16:04:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Aug 2015 19:04:57 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=047d7b41c5b4c53afd051c703209 Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:05:02 -0000 --047d7b41c5b4c53afd051c703209 Content-Type: text/plain; charset=UTF-8 Jamal, Thanks - I've asked Joel to help and do a routing directorate review. The timeline is up to you, but I'm not as backlogged anymore. Regards, Alia On Mon, Aug 3, 2015 at 6:14 PM, Jamal Hadi Salim wrote: > Alia, > > You raise legit issues. We will work on putting out a new version > in the next day or two which will hopefully address all the issues you > brought up by being more focussed. Thanks for your patience. > > cheers, > jamal > > On Mon, Aug 3, 2015 at 10:52 AM, Alia Atlas wrote: > >> Hi Jamal, >> >> On Sun, Aug 2, 2015 at 2:40 PM, Jamal Hadi Salim >> wrote: >> >>> Hi Alia, >>> >>> >>> On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas wrote: >>> >>>> Hi Damascane and Jamal, >>>> >>>> First, thank you for your work on this draft. >>>> >>>> As is customary, I have done my AD review of this draft before >>>> requesting IETF Last Call. >>>> >>>> >>> Thanks for making the time. Your effort is very much appreciated. >>> >>> >>> >>>> As part of this, I see that Evangelos, acting as Document Shepherd, >>>> found a number of issues that are written up in his report - and that still >>>> haven't been addressed two months later. Picking an IANA value that isn't >>>> available is one of them. I know these are editorial, but still needed. >>>> >>>> >>> >>> Sorry. >>> Based on the last discussions we had it didnt seem that it was worth >>> changing >>> until we got AD input (for some reason i thought it was you we discussed >>> this with - but likely it was Adrian; i just got back so still >>> jetlagged). >>> We will make an update taking into consideration the comments from >>> Evangelos and yourself. >>> >> >> As you may understand, for an AD-sponsored draft, I do expect that the >> authors are extremely pro-active. >> Claiming that the draft is ready to progress when it is very far from >> that is just a way of wasting all our time - particularly >> when I pick up the same issues and see whether or not they've been >> addressed. >> >> As this draft is written, it is taking a single implementation and >> doesn't think through implications or the different aspects. >> >> At this time, I really don't think this draft is ready to advance. >>>> There are some things that are editorial or clarifications, as I >>>> described below. >>>> >>>> Please take some serious time and focus to improve this document if you >>>> want it to progress. >>>> >>>> There are two primary major issues. >>>> >>>> First, you haven't in any way justified why the inter-FE communication >>>> needs to be encapsulated in an Ethernet frame. Since you are asking for >>>> the IETF to get an EtherType allocated, that's kind of a bare minimum. >>>> >>> >>> We have this working over ethernet today and our scope is on ethernet >>> L2 networks in a private setting (because that was the charter work >>> item). >>> We need the ethertype for dis-ambiguation of the frames. >>> We do recognize it is possible to run data across different underlying >>> protocols - but it seems even talking about that in the doc was >>> unnecessary >>> editorializing. >>> >> >> A personal choice to implement it using Ethernet is not a technical >> justification as to why this needs to be a standard. >> You are asking for a limited resource - and, as Pat's email indicated, >> the IEEE are asking that new EtherTypes have formats that >> include a subtype so that reuse is possible. >> >> Are there others interested in deploying this over Ethernet? Why is it >> necessary to use Ethernet and not IP? >> >> >> >>> Second, the draft bounces around a lot around whether this is an >>>> encapsulation that is just inside Ethernet or a general encapsulation that >>>> can be inside IP and other things. >>>> >>> >>> Ok, we will review and remove any uncertainty >>> and just focus on ethernet. >>> >>> >>>> Moreover, it doesn't actually describe the reasoning or handling of the >>>> src/dest information and the packets. >>>> >>>> >>> >>> We will try to clarify. >>> >>> >>>> You really need to better describe precisely the assumptions, >>>> behaviors, and error handling. >>>> >>>> >>> Section 6 tries to cover the above. We will go over it again and fix >>> any gaps we can find. >>> >>> >>> Issues: >>>> >>>> 1) In Sec 5.1.1: "The frame may be dropped if there is congestion on >>>> the receiving FE side. One approach to mitigate this issue is to make sure >>>> that inter-FE LFB frames receive the highest priority treatment >>>> when scheduled on the wire." This suggestion just destroyed the >>>> possibility of respecting the requested CoS of the encapsulated packet and >>>> probably any actual high priority or EF traffic. This recommendation must >>>> be fixed. >>>> >>>> >>> >>> Would wording around this form help: >>> "The frame may be dropped if there is congestion on the receiving FE >>> side. >>> To mitigate this issue is the sending FE side should treat inter-FE LFB >>> frames >>> with high priority. When 802.1p is present, then it is recommended a >>> value >>> of XXX should be used. In the absence of 802.1p, implementation specific >>> treatments at the source FE may be used". >>> To your earlier point i think we need to say something like this around >>> section >>> 6 as well. >>> >>> 2) In Sec 6.1.1: One step is " create the outer ethernet header which is >>>> a duplicate of the >>>> incoming frame's ethernet header. The outer ethernet header may >>>> have an optional 802.1q header (if one was included in the >>>> original frame)." First, what if the incoming packet wasn't in >>>> an ethernet frame? POS does still exist. >>>> >>> >>> >>> Our intent (and deployment) is on ethernet. Clearly we need to emphasize >>> that view. >>> Do you see POS as a necessary ingredient? >>> >> >> You are describing what is presented as an inter-FE communication and >> then your text ASSUMES that the >> traffic is always Ethernet frames where the original Ethernet frame is >> still available at that point in the pipeline. >> This is just sloppy and not generic for no reason that I can currently >> understand. >> >> Second, why would the 802.1q vlan tag be relevant/valid on the outgoing >>>> port in between FEs? This doesn't really make sense to me. I do see the >>>> next bullet talks about changing the vlan tag value but nothing happens if >>>> the NEID is 0 or absent. >>>> >>>> >>> The context of this was taken directly from code;-> So something was >>> lost in translation. We will fix it. >>> >>> As to the relevance of the vlan tags - the idea of NEID is one of tenancy >>> differentiation. >>> >> >> But how is that connected to the inter-FE communication? >> >> >>> >>> >>>> 3) How can the DSTFE be optional??? Why does sending the Ethernet >>>> Frame to the original destination MAC address work? >>>> >>>> >>> You put some doubt in my mind when I read this;-> So I went and looked >>> at testcases. And in the majority of the policies, we do specify the >>> DSTFE. >>> But there are some cases where _we dont_ and reuse the originally >>> target DSTFE MAC address on the outer header. >>> Does that explain? If not, why do you think it wont work? >>> >> >> Why would a random destination MAC address have anything to do with the >> next FE in the FE graph? >> >> Presumably, the outer encapsulation is to go from one FE to another FE in >> the graph. If so, then what >> information the packet being processed has is irrelevant. If not, then >> you've totally failed to explain your >> assumptions and purpose. >> >> >> >>> 4) In Sec 6.2, what happens if none of the optional elements of an >>>> IFEInfo are specified? >>>> >>> >>> Thanks for catching this. >>> There would be no such table entry allowed (and so no processed packets >>> will encounter this scenario). We will update the doc to indicate that >>> when the >>> CE inserts policies in the policy table - the FE MUST validate that the >>> non >>> optional fields are all present (the implementation already does that). >>> >> >> But you made them all optional! >> >> >>> How can this work if there's no required way to describe the destination >>>> FE? >>>> >>> >>> Am I misunderstanding or are you are implying we need some default >>> DSTFE where a lookup failure happens? >>> Last para in 6.1.1 describes what happens on lookup failure. >>> >>> 5) From p. 22, it looks like the IFETable is defined assuming only >>>> transport over Ethernet. >>>> >>> >>> Yes - that is the intent >>> >> >> Why do you have text describing a more generic solution and then actually >> define an extremely limited one? >> >> Regards, >> Alia >> >> >>> 6) Sec 10: I think you'll find that there are security implications of >>>> taking packets and sending them in an Ethernet packet. Now, I realize that >>>> the different FEs are probably inside the same device on a private network >>>> - but you need to clarify why that's the case. >>>> >>>> >>> Yes, the scope is within the same network. We will add clarification. >>> >>> >>>> Minor Quibble: >>>> >>>> a) There are places where this draft talks about other documents being >>>> written. For instance, on the top of p.13 "For any mapping towards >>>> these definitions a different document to describe the mapping, one >>>> per transport, is expected to be defined." It's fine to have a process in >>>> mind - but this is completely unclear, given that the WG is closed. Are >>>> these documents with a well-known place on-line? Are these ISE drafts? Do >>>> you think these would be AD-sponsored or in rtgwg? >>>> >>>> >>> >>> We can get rid of such text altogether to avoid any confusion we are >>> talking about ethernet only. >>> >>> >>> >>>> b) On the bottom of p. 13, it says "In this version of the >>>> specification, we only focus on data and metadata. Therefore we are not >>>> going to describe how to carry the ExceptionID information (future versions >>>> may). " PLEASE go through the document and get rid of these bits of >>>> tentative and future language. The document is doing and defining what it >>>> is. OWN that and fix the language everywhere. (e.g. bottom of p.14 "would >>>> save us") >>>> >>>> >>> Will do. >>> >>> >>>> >>>> Nits: >>>> >>>> 1) On p. 6, "This information may include any source and >>>> destination information (MAC address to use, if ethernet;)" Sadly, I think >>>> the ;) needs to go - what about "e.g. MAC address to use, if Ethernet)". >>>> >>>> >>> will do. >>> >>> >>>> 2) In Sec. 3.1.1, the last paragraph is "The purpose of the inter-FE >>>> LFB is to define standard mechanisms for interconnecting FEs and for that >>>> reason we are not going to touch >>>> anymore on proprietary chip-chip interconnects other than state the >>>> fact they exist and that it is feasible to have translation to and >>>> from proprietary approaches." is a bit informal. Could you please >>>> clean it up a bit? >>>> >>> For instance: "This document defines the inter-FE LFB, a standard >>>> mechanism for interconnecting FEs. Existing proprietary approaches, such >>>> as chip-chip interconnects, may be able to translate to and from the >>>> standard inter-FE LFB." >>>> >>>> >>> Will do. >>> >>> >>>> 3) Sec 4 starts with "We address the inter-FE connectivity requirements >>>> by proposing the inter-FE LFB class." Remember this will be an RFC - >>>> please replace "proposing" with "defining". Similarly, the title of >>>> "Figure 6: Packet format suggestion" - is this what the document is >>>> standardizing or not?? >>>> >>>> >>> Will do. >>> >>> Thanks for the thorough review. >>> >>> cheers, >>> jamal >>> >>> >>>> Thanks, >>>> Alia >>>> >>>> >>> >> > --047d7b41c5b4c53afd051c703209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jamal,

Thanks - I've asked Joel to = help and do a routing directorate review.
The timeline is up to y= ou, but I'm not as backlogged anymore.

Regards= ,
Alia

On Mon, Aug 3, 2015 at 6:14 PM, Jamal Hadi Salim <hadi@mojatatu= .com> wrote:
Alia,

You raise legit issues. We will work on putting out a= new version
in the next day or two which will hopefully address = all the issues you=C2=A0
brought up by being more focussed. Thank= s for your patience.

cheers,
jamal
=

On Mon, Aug 3, 2015 at 10:52 AM, Alia At= las <akatlas@gmail.com> wrote:
Hi Jamal,

On Sun, Aug 2, 2015 at 2:40 PM, Jamal Hadi Salim <hadi@mojat= atu.com> wrote:
Hi Alia,


On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas <akatlas@gma= il.com> wrote:
Hi=C2=A0Damascane and Jamal,

First, thank you = for your work on this draft.

As is= customary, I have done my AD review of this draft before requesting IETF L= ast Call. =C2=A0


Thanks for making the time. Your e= ffort is very much appreciated.

=C2=A0
=
As part of this, I see that Evangelos, acting as Document Shep= herd, found a number of issues that are written up in his report - and that= still haven't been addressed two months later.=C2=A0 Picking an IANA v= alue that isn't available is one of them.=C2=A0 I know these are editor= ial, but still needed.



Sorry.
<= div>Based on the last discussions we had it didnt seem that it was =C2=A0wo= rth changing
until we got AD input (for some reason i thought it = was you we discussed
this with - but likely it was Adrian; i just= got back so still jetlagged).=C2=A0
We will make an update takin= g into consideration the comments from
=C2=A0Evangelos and yourse= lf.

As you may unde= rstand, for an AD-sponsored draft, I do expect that the authors are extreme= ly pro-active.
Claiming that the draft is ready to progress when = it is very far from that is just a way of wasting all our time - particular= ly
when I pick up the same issues and see whether or not they'= ;ve been addressed.
=C2=A0
As this draft is written, it= is taking a single implementation and doesn't think through implicatio= ns or the different aspects.

At this time, I really don't think this = draft is ready to advance.
There are some thin= gs that are editorial or clarifications, as I described below.

Please take some seriou= s time and focus to improve this document if you want it to progress.

There are two pr= imary major issues.

= First, you haven't in any way justified why the inter-FE communica= tion needs to be encapsulated in an Ethernet frame.=C2=A0 Since you are ask= ing for the IETF to get an EtherType allocated, that's kind of a bare m= inimum.

We= have this working over ethernet today and our scope is on ethernet
L2 networks in a private setting (because that was the charter work item= ).=C2=A0
We need the ethertype =C2=A0for dis-ambiguation of the f= rames.
We do recognize it is possible to run data across differen= t underlying
protocols - but it seems even talking about that in = the doc was unnecessary
editorializing.

A personal choice to implement it using Ethe= rnet is not a technical justification as to why this needs to be a standard= .
You are asking for a limited resource - and, as Pat's email= indicated, the IEEE are asking that new EtherTypes have formats that
=
include a subtype so that reuse is possible.

= Are there others interested in deploying this over Ethernet? =C2=A0 Why is = it necessary to use Ethernet and not IP?

=C2=A0
Second, the draft bounces around a lot around= whether this is an encapsulation that is just inside Ethernet or a general= encapsulation that can be inside IP and other things.
<= /div>

Ok, we will review and remove = any uncertainty
and just focus on ethernet.
=C2= =A0
Moreov= er, it doesn't actually describe the reasoning or handling of the src/d= est information and the packets.



We = will try to clarify.
=C2=A0
You really ne= ed to better describe precisely the assumptions, behaviors, and error handl= ing.


Section 6 tries to cover the above. We will go= over it again and fix
any gaps we can find.

=

<= font color=3D"#000000" face=3D"PT Mono, Monaco, monospace">Issues:

= 1) In Sec 5.1.1: =C2=A0"The frame may= be dropped if there is congestion on the receiving=C2=A0FE side.=C2=A0 One= approach to mitigate this issue is to make sure that=C2=A0inter-FE LFB fra= mes receive the highest priority treatment when=C2=A0scheduled on the wire.= " =C2=A0This suggestion just destroyed the possibility of respecting t= he requested CoS of the encapsulated packet and probably any actual high pr= iority or EF traffic. =C2=A0 This recommendation must be fixed.
<= br>


Would= wording around this form help:
"The frame may be drop= ped if there is congestion on the receiving FE side.=C2=A0
To mitigate this issue is the sending FE side should treat inter-FE LFB fr= ames
with high priority. When 802.1p is present, then it is recom= mended a value
of XXX should be used. In the absence of 802.1p, i= mplementation specific
treatments at the source FE may be used&qu= ot;.
To your earlier point i think we need to say something like = this around section
6 as well.

2) In Sec 6.1.1: On= e step is "=C2=A0create the outer ethernet header which is a duplicate= of the
=C2=A0 =C2=A0 =C2=A0 incoming frame's ethernet header.=C2=A0= The outer ethernet header may
=C2=A0 =C2=A0 =C2=A0 have an optional 802= .1q header (if one was included in the
=C2=A0 =C2=A0 =C2=A0 original fra= me)." =C2=A0First, what if the incoming packet wasn't in an ethern= et frame?=C2=A0 POS does still exist.=C2=A0

Our intent (and deployment) =C2=A0is on = ethernet. Clearly we need to emphasize
that view.
Do yo= u see POS as a necessary ingredient?

You are describing what is presented as an inter-FE commu= nication and then your text ASSUMES that the
traffic is always Et= hernet frames where the original Ethernet frame is still available at that = point in the pipeline.
This is just sloppy and not generic for no= reason that I can currently understand.=C2=A0

Second, why would the 802.1q vlan tag be relevant/valid on the outgoing= port in between FEs? =C2=A0 This doesn't really make sense to me.=C2= =A0 I do see the next bullet talks about changing the vlan tag value but no= thing happens if the NEID is 0 or absent.


The context of this was taken directly fro= m code;-> So something was
lost in translation. We will fix it= .

As to the relevance of the vlan tags - the idea = of NEID is one of tenancy
differentiation.
=

But how is that c= onnected to the inter-FE communication? =C2=A0
=C2=A0
=C2=A0
=
3) How can the DSTFE be optional???=C2=A0 = Why does sending the Ethernet Frame to the original destination MAC address= work?


You put some = doubt in my mind when I read this;-> So I went and looked
at t= estcases. And in the majority of the policies, we do specify the DSTFE.
But there are some cases where _we dont_ and reuse the originally
target DSTFE MAC address on the outer header.
Does that e= xplain? If not, why do you think it wont work?=C2=A0

Why would a random destination MAC addres= s have anything to do with the next FE in the FE graph?

Presumably, the outer encapsulation is to go from one FE to another F= E in the graph.=C2=A0 If so, then what
information the packet bei= ng processed has is irrelevant.=C2=A0 If not, then you've totally faile= d to explain your
assumptions and purpose.

=C2=A0
4) In Sec 6.2, what happens if none of th= e optional elements of an IFEInfo are specified?
Thanks for catching this.
There would be no s= uch table entry allowed (and so no processed packets
will encount= er this scenario). We will update the doc to indicate that when the
CE inserts policies in the policy table - the FE MUST validate that the = non
optional fields are all present (the implementation already d= oes that).

But you = made them all optional! =C2=A0=C2=A0
=C2=A0
How can th= is work if there's no required way to describe the destination FE?

Am I misunderstanding or are you a= re implying we need some default
DSTFE where a lookup failure hap= pens?
Last para in 6.1.1 describes what happens on lookup failure= .

5) From p. 22, it looks like the IFETable is defined = assuming only transport over Ethernet.

Yes - that is the intent

Why do you have text describing a more g= eneric solution and then actually define an extremely limited one?

Regards,
Alia
=C2=A0
6) Sec 10: =C2=A0I think you'll find that there are security impl= ications of taking packets and sending them in an Ethernet packet.=C2=A0 No= w, I realize that the different FEs are probably inside the same device on = a private network - but you need to clarify why that's the case.=


=
Yes, the scope is within the same network. We will add cl= arification.
=C2=A0
Minor Quibble:

a) There are places where this draft talks abou= t other documents being written.=C2=A0 For instance, on the top of p.13 &qu= ot;For any mapping towards these definitions a different= =C2=A0 =C2=A0document to describe the mapping, one per transport, is expect= ed to=C2=A0be defined." =C2=A0It's fine to have a process in mind = - but this is completely unclear, given that the WG is closed.=C2=A0 Are th= ese documents with a well-known place on-line?=C2=A0 Are these ISE drafts?= =C2=A0 Do you think these would be AD-sponsored or in rtgwg?



We can get rid of s= uch text altogether to avoid any confusion we are
talking about e= thernet only.

=C2=A0
b) On the bottom of p. 13, it says "In = this version of the specification, we only focus on data and metadata.=C2= =A0 Therefore we are not going to describe how to carry the ExceptionID inf= ormation (future versions may). " =C2=A0 PLEASE go through the documen= t and get rid of these bits of tentative and future language.=C2=A0 The doc= ument is doing and defining what it is.=C2=A0 OWN that and fix the language= everywhere. =C2=A0(e.g. bottom of p.14 "would save us")

=

Will do.
=C2=A0

Nits:

1) On p. 6, "This inform= ation may include any source and destination=C2=A0information (MAC address = to use, if ethernet;)" =C2=A0Sadly, I think the ;) needs to go - what = about "e.g. MAC address to use, if Ethernet)".


will do.
= =C2=A0
2) In Sec. 3.1.1, the last paragraph is=C2=A0"The purpose of the= inter-FE LFB is to define standard mechanisms for=C2=A0interconnecting FEs= and for that reason we are not going to touch
=C2=A0 =C2=A0anymore on p= roprietary chip-chip interconnects other than state the
=C2=A0 =C2=A0fac= t they exist and that it is feasible to have translation to and
=C2=A0 = =C2=A0from proprietary approaches." =C2=A0is a bit informal.=C2=A0 Cou= ld you please clean it up a bit?=C2=A0
For instance= : =C2=A0"This document defines the inter-FE LFB, a standard mechanism = for interconnecting FEs.=C2=A0 Existing proprietary approaches, such as chi= p-chip interconnects, may be able to translate to and from the standard int= er-FE LFB."


Will do.
=C2=A0
3) Sec 4 starts with "We address the inter-FE connec= tivity requirements by proposing the=C2=A0inter-FE LFB class." =C2=A0R= emember this will be an RFC - please replace "proposing" with &qu= ot;defining".=C2=A0 Similarly, the title of "Figure 6: Packet for= mat suggestion" - is this what the document is standardizing or not??<= div>

Will do.<= /div>

Thanks for the thorough review.

cheers,
jamal
=C2=A0
Thanks,
Alia




--047d7b41c5b4c53afd051c703209-- From nobody Mon Aug 31 15:19:11 2015 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 931CA1B6764 for ; Mon, 31 Aug 2015 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 Rm0vrjJeTJPQ for ; Mon, 31 Aug 2015 15:19:08 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 AEC181B675D for ; Mon, 31 Aug 2015 15:19:07 -0700 (PDT) Received: by wicjd9 with SMTP id jd9so13892750wic.1 for ; Mon, 31 Aug 2015 15:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=17jUBRg0HeCfs81oz8VzOMO5k1GotxBCFEVAfJFX34c=; b=JUUleEpiQjvPF7idGOmy9UOLx6tEVYVxVKKMI7oZk+ntSIRylooOc4w4OzSGwX/Wri TyhYXjRTMeCpW7TvVWpeZwHyAnKVfO6BZK9Y6BUudUiWWPno67dISGnQLTnNXMjLq/2Y 8RVhbtG9qNKLTeM5iUuKB+20IIAaZ8j1CCHI9p4VD6Uos0wxhlDCJ5i9zwbyA3v22xLJ KimNYecbmyCWxkBnsYreVdGKEi4AKVHWkDdsC+BIObnvNgZd4PDl+MX0Wo/2v2WN6Iy+ DDcQC/1Eg+Jm18w2iEX502odL+w+zl2CZzDjXbfKD92/2CHySM+KMNZ1nhvOPxixhDQ6 oY/Q== X-Received: by 10.194.95.103 with SMTP id dj7mr13755024wjb.118.1441059546346; Mon, 31 Aug 2015 15:19:06 -0700 (PDT) Received: from EhalepXPS (ppp079166119211.access.hol.gr. [79.166.119.211]) by smtp.gmail.com with ESMTPSA id wx9sm24201388wjb.6.2015.08.31.15.19.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Aug 2015 15:19:05 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Tue, 1 Sep 2015 01:19:03 +0300 Message-ID: <011f01d0e43b$0c0d0e50$24272af0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDkOsxEaeXdQozeQYqn1BGx2Exk3wAACYkw Content-Language: el Archived-At: Subject: [forces] FW: New Version Notification for draft-ietf-forces-lfb-subsidiary-management-02.txt 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, 31 Aug 2015 22:19:10 -0000 Greetings to the list, We have just updated the subsidiary management draft. Regards, Evangelos. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 01, 2015 1:16 AM > To: Evangelos Haleplidis; Jamal Hadi Salim; Bhumip Khasnabish; > bhumip.khasnabish@ztetx.com; Evangelos Haleplidis; Jamal Hadi Salim; > Bhumip Khasnabish; bhumip.khasnabish@ztetx.com > Subject: New Version Notification for = draft-ietf-forces-lfb-subsidiary- > management-02.txt >=20 >=20 > A new version of I-D, draft-ietf-forces-lfb-subsidiary-management- > 02.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Name: draft-ietf-forces-lfb-subsidiary-management > Revision: 02 > Title: IETF ForCES Logical Function Block (LFB) Subsidiary > Management > Document date: 2015-08-31 > Group: Individual Submission > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-forces-lfb-subsidiary-man= agement-02.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-forces-lfb-subsidiary-managem= ent/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-forces-lfb-subsidiary-management-0= 2 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-lfb-subsidiary-mana= gement-02 >=20 > Abstract: > Deployment experience has demonstrated the value of using the > Forwarding and Control Element Separation (ForCES) architecture to > manage resources other than packet forwarding. In that spirit, the > Forwarding Element Manager (FEM) is modelled by creating a Logical > Functional Block (LFB) to represent its functionality. We refer to > this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element > (CE) that controls a Forwarding Element's (FE) resources can also > manage its configuration via the SM LFB. This document introduces > the SM LFB class, an LFB class that specifies the configuration > parameters of an FE. The configuration parameters include new LFB > class loading, CE associations as well as to provide manipulation = of > debug mechanisms along with a general purpose attribute definition > to > describe config information. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > The IETF Secretariat