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

[Jamal Hadi Salim <[e-mail]>]

Hi Alia,


On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas <[e-mail]> 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.


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.


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?


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


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

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


> 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


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