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

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

On Mon, Aug 3, 2015 at 10:51 AM, Joel M. Halpern <[e-mail]>
wrote:

> While we need to explain the choice of Ethernet, assuming such explanation
> then using that for the outer encapsulation seems fine.  It was the
> assumption that the inner encapsulation was Ethernet that seemed
> problematic.
>
>

We are going to get rid of that detail. It was confusing.


> It seems to me that if we are careful in the wording, we probably can also
> allow for other carriage means to be defined later.
>
>
Ok, we will publish a new version in the next 1-2 days. We feel that
a focus will help to get rid of the confusion. If there is tweaking that
can be made to allow other transports that would be great.

cheers,
jamal



> Yours,
> Joel
>
> On 8/3/15 7:05 AM, Jamal Hadi Salim wrote:
>
>>
>> On Sun, Aug 2, 2015 at 3:35 PM, Joel M. Halpern <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     A couple of points where I see mis-communication, in line below:
>>
>>     On 8/2/15 2:40 PM, Jamal Hadi Salim wrote:
>>
>>
>>         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.
>>
>>
>> How about we totally remove that text? upstream LFBs will set priority
>> fields (which pass through the Inter-FE LFB) and down
>> stream LFBs (like schedulers) will pay attention to it.
>>
>>     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.
>>
>>
>>
>> Ok, got it ;->
>> The implementation ended dealing with Ethernet as the "raw
>> packet" input into IN1. As i was saying that text was direct translation
>> from the code. So we need to fix the text.
>> And yes, I agree that it is possible there will be no ethernet frame
>> arriving
>> at IN1.
>> We would like however want to keep the ethernet encapsulation
>> and not have to deal with POS for example - would that be fine?
>>
>>     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.)
>>
>>
>> Agreed.
>>
>> cheers,
>> jamal
>>
>