Re: [forces] AD review of draft-ietf-forces-interfelfb-01

Jamal Hadi Salim <hadi@mojatatu.com> Mon, 03 August 2015 22:14 UTC

Return-Path: <hadi@mojatatu.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 247CF1B2D0F for <forces@ietfa.amsl.com>; 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 <forces@ietfa.amsl.com>; 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 <forces@ietf.org>; Mon, 3 Aug 2015 15:14:23 -0700 (PDT)
Received: by qged69 with SMTP id d69so99239198qge.0 for <forces@ietf.org>; 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: <CAG4d1reFShSnBd_eL4qqSP3TngBoWfUwGv9DL7UFcP3oWeHKnQ@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>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Mon, 3 Aug 2015 18:14:03 -0400
Message-ID: <CAAFAkD9=1RFgg52fvaXKJuotvJEr2=74GKH6uqxJZRRZ8aH-NQ@mail.gmail.com>
To: Alia Atlas <akatlas@gmail.com>
Content-Type: multipart/alternative; boundary=001a1135df9aea448c051c6f7dc0
Archived-At: <http://mailarchive.ietf.org/arch/msg/forces/oCKxpWhW8INUa44WwMlMRH_ySMQ>
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 22:14:28 -0000

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