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

[Alia Atlas <[e-mail]>]

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.

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.

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.

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.  Moreover, it doesn't actually describe
the reasoning or handling of the src/dest information and the packets.

You really need to better describe precisely the assumptions, behaviors,
and error handling.


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.

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

3) How can the DSTFE be optional???  Why does sending the Ethernet Frame to
the original destination MAC address work?

4) In Sec 6.2, what happens if none of the optional elements of an IFEInfo
are specified?  How can this work if there's no required way to describe
the destination FE?

5) From p. 22, it looks like the IFETable is defined assuming only
transport over Ethernet.

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.



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?

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


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)".

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

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

Thanks,
Alia