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