Re: [forces] AD review of draft-ietf-forces-interfelfb-01
Alia Atlas <akatlas@gmail.com> Mon, 03 August 2015 23:05 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: forces@ietfa.amsl.com
Delivered-To: forces@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: <CAAFAkD9=1RFgg52fvaXKJuotvJEr2=74GKH6uqxJZRRZ8aH-NQ@mail.gmail.com>
References: <CAG4d1rfXwh_rq--ZmQpnX_zUGYtEsKwbc+mQhim4bx7QkiO_pA@mail.gmail.com> <CAAFAkD-oo3guuoSLOzA9RJSWLs2iGxRuzTr_rkeGTtr0c_EaTA@mail.gmail.com> <CAG4d1reFShSnBd_eL4qqSP3TngBoWfUwGv9DL7UFcP3oWeHKnQ@mail.gmail.com> <CAAFAkD9=1RFgg52fvaXKJuotvJEr2=74GKH6uqxJZRRZ8aH-NQ@mail.gmail.com>
Date: Mon, 03 Aug 2015 19:04:57 -0400
Message-ID: <CAG4d1rfA-MGY=AwAdXgqdjq+XOLs7vuMaOxkW8yPjWOMZrrhFg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Jamal Hadi Salim <hadi@mojatatu.com>
Content-Type: multipart/alternative; boundary="047d7b41c5b4c53afd051c703209"
Archived-At: <http://mailarchive.ietf.org/arch/msg/forces/oke-sfWvXWZNkIPTSNd4gs1Z1S0>
Cc: "forces@ietf.org" <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 <forces.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/forces>, <mailto:forces-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/forces/>
List-Post: <mailto:forces@ietf.org>
List-Help: <mailto:forces-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/forces>, <mailto:forces-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2015 23:05:02 -0000
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 <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 > brought up by being more focussed. Thanks for your patience. > > cheers, > jamal > > On Mon, Aug 3, 2015 at 10:52 AM, Alia Atlas <akatlas@gmail.com> wrote: > >> Hi Jamal, >> >> On Sun, Aug 2, 2015 at 2:40 PM, Jamal Hadi Salim <hadi@mojatatu.com> >> wrote: >> >>> Hi Alia, >>> >>> >>> On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas <akatlas@gmail.com> 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 >>>> >>>> >>> >> >
- [forces] AD review of draft-ietf-forces-interfelf… Alia Atlas
- Re: [forces] AD review of draft-ietf-forces-inter… Jamal Hadi Salim
- Re: [forces] AD review of draft-ietf-forces-inter… Joel M. Halpern
- Re: [forces] AD review of draft-ietf-forces-inter… Jamal Hadi Salim
- Re: [forces] AD review of draft-ietf-forces-inter… Alia Atlas
- Re: [forces] AD review of draft-ietf-forces-inter… Alia Atlas
- Re: [forces] AD review of draft-ietf-forces-inter… Joel M. Halpern
- Re: [forces] AD review of draft-ietf-forces-inter… Jamal Hadi Salim
- Re: [forces] AD review of draft-ietf-forces-inter… Jamal Hadi Salim
- Re: [forces] AD review of draft-ietf-forces-inter… Alia Atlas