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