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

["Joel M. Halpern" <[e-mail]>]

A couple of points where I see mis-communication, in line below:

On 8/2/15 2:40 PM, Jamal Hadi Salim wrote:
> Hi Alia,
>
>
> On Fri, Jul 31, 2015 at 6:08 PM, Alia Atlas <[e-mail]
> <mailto:[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.
>
...
>
>
>     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.

This answer seems to miss Alia's point.  Suppose that we are processing 
a mix of packets from multiple end-applications (this seems very 
likely).  Then some of those packets will be more important than others. 
  If there is congestion, and if packet drops are needed to keep things 
working, then you want to drop the inter-FE packets whose underlying IP 
packet is lower priority, while retaining the ones whose underlying IP 
priority (DSCP inferred drop precedence, ...) is higher.  So setting 
everything as high between the two FEs is not a good idea.

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

I think that there are actually two issues here.
1) There is no reason for the outer MAC header to be (from a 
specification point of view) a copy of the inner MAC header.  It needs 
to have the right contents for sending the packet to the next FE, which 
has nothing to do with the underlying Ethernet MAC header.  It may have 
to do with the underlying priority, but specifying it as a copy of the 
header is not a good model.
2) The mechanism should be specified in such a way that it works even if 
we are not carrying a subscriber MAC header.  It should work with just 
an IP header.  It should work with media other than Ethernet.  This 
mechanism is not specific to external Ethernet support.  For example, if 
you are using this for processing isnide a service environment, the 
subscribers MAC header is likely long gone and irrelevant.

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

It is fine to carry packets from multiple tenants across this mechanism. 
  However, ForCES does not rely on vlan tags for differentiation. 
Rather, it uses metadata.  So I don't see why you are worrying about the 
incoming vlan tag (which may not even be there.)

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

That does not make sense.  The InterFE LFB needs to know where to send 
the packet, and needs to send it there.  You can take some 
implementation shortcuts (although I would bet they will cause you 
trouble later), but that is not how you specify the protocol behavior.
...