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