Subject: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-01.txt

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 25 Feb 2013 06:46:40 -0500

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Feb 25, 2013 at 6:29 AM
Subject: New Version Notification for
draft-joachimpillai-forces-interfelfb-01.txt
To: [email-masked]
Cc: [email-masked]

A new version of I-D, draft-joachimpillai-forces-interfelfb-01.txt
has been successfully submitted by Jamal Hadi Salim and posted to the
IETF repository.

Filename:        draft-joachimpillai-forces-interfelfb
Revision:        01
Title:           ForCES Inter-FE LFB
Creation date:   2013-02-25
Group:           Individual Submission
Number of pages: 18
URL:
http://www.ietf.org/internet-drafts/draft-joachimpillai-forces-interfelfb-01.txt
Status:
http://datatracker.ietf.org/doc/draft-joachimpillai-forces-interfelfb
Htmlized:
http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-joachimpillai-forces-interfelfb-01

Abstract:
   Forwarding and Control Element Separation (ForCES) defines an
   architectural framework and associated protocols to standardize
   information exchange between the control plane and the forwarding
   plane in a ForCES Network Element (ForCES NE).  RFC5812 has defined
   the ForCES Model provides a formal way to represent the capabilities,
   state, and configuration of forwarding elements within the context of
   the ForCES protocol, so that control elements (CEs) can control the
   FEs accordingly.  More specifically, the model describes the logical
   functions that are present in an FE, what capabilities these
   functions support, and how these functions are or can be
   interconnected.

   At the moment the ForCES charter restricts the LFB topology to be
   within an FE.  This documents describes a non-intrusive way to extend
   the LFB topology across FEs.

The IETF Secretariat

---

From: Joel <[email-masked]>
Date: Mon, 25 Feb 2013 13:09:01 -0500

Thank you for submitting this draft.

It seem to me that the encapsulation needs to include a bit more context 
information, probably in the form of a fixed header.   this would seem 
to allow us to include a fragmentation mechanisms.  Unfortunately, non 
of the other options liste in the draft seem viable.
In conjunction with this, the fixed header could include information 
about what the target entity for the message is, in he case of 
virtualized FEs.  Ts makes sense since conceptually the determination of 
which FE the packet is going to has to be done before the LFB in that FE 
gets a hold of it to process the TLVs.

I do wonder if we could use a structure parallel to the existing ForCES 
protocol fixed header without too much distortion.  the format has the 
relevant IDs and correlators we could use for fragmentation.

Given the above, why do we need separate NESelector-TLVs and 
ExceptionID-TLVs?  it seems that there are pieces of metadata, and could 
be carried easily and appropriately in the Metadata-TLV.

Yours,
Joel M. Halpern

On 2/25/2013 6:46 AM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 25 Feb 2013 14:36:53 -0500

On Mon, Feb 25, 2013 at 1:09 PM, Joel <[email-masked]> wrote:
> information, probably in the form of a fixed header.
>  this would seem to
> allow us to include a fragmentation mechanisms.  Unfortunately, non of the
> other options liste in the draft seem viable.

What is your thought on carrying fragmentation details as an optional
TLV? Unless fragmenting would be considered a norm and non-fragement
would be considered an exception.

> In conjunction with this, the fixed header could include information about
> what the target entity for the message is, in he case of virtualized FEs.

Again that would be sensible if the normal path is we always carry
that information.
The assumption is some people may not be interested.

> Ts makes sense since conceptually the determination of which FE the packet
> is going to has to be done before the LFB in that FE gets a hold of it to
> process the TLVs.
>

aha, makes a lot of sense.

> relevant IDs and correlators we could use for fragmentation.

Our thought process was to try and not use bits that most people dont
want to use. But you make a good arguement for a small common header
(in the case of virtualized FEs).

> ExceptionID-TLVs?  it seems that there are pieces of metadata, and could be
> carried easily and appropriately in the Metadata-TLV.

Maybe not the NESeletor, but i dont think you can escape the ExceptionID TLV.
Exception IDs live in a different namespace from metadata (and a good chunk
are IANA controlled just like metadata).

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Mon, 25 Feb 2013 14:45:20 -0500

Putting the fragment header inside the TLV construct means that we then 
have to describe how the TLVs are reassembled around the fragment 
header.  I fear that fragmentation will be a common case, since there 
are many full MTU size packets, and we are heading information to EVER 
packet.  So just put it in the fixed header.

With regard to the exception IDs, I realized that I am having trouble 
understanding what that TLV is for.  After all, the exception IDs are 
form the information of the CE.

Yours
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 26 Feb 2013 08:25:03 -0500

On Mon, Feb 25, 2013 at 2:45 PM, Joel <[email-masked]> wrote:
> Putting the fragment header inside the TLV construct means that we then have
> to describe how the TLVs are reassembled around the fragment header.  I fear
> that fragmentation will be a common case, since there are many full MTU size
> packets, and we are heading information to EVER packet.  So just put it in
> the fixed header.

I remember now a good reason we wanted fragmentation as optional:
Given we'd like to allow this to work over other transports it is possible
(for example over UDP/IP) that the underlying transport can provide
the fragmentation service.

> understanding what that TLV is for.  After all, the exception IDs are form
> the information of the CE.

If i got what you are saying: We _do_ need a new Exception top level, correct?
I would say given the name space separation from metadata (per LFB lib) we
need it regardless of whether it is used here.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 26 Feb 2013 08:29:38 -0500

> (in the case of virtualized FEs).

Joel, if the forces common Header was to be used, this would be a unidirectional
message (like redirect to/from CE). Leaving the fragmentation issue aside,
would you see a new message type? Can we abuse the correlator to store
the NE ID (assuming the message is unidirectional, that space is wasted
otherwise).

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 26 Feb 2013 08:58:59 -0500

My thought was that rather than send an NE ID we could reasonably expect 
that any physical device supporting multiple NEs could ensure that the 
FEs had distinct IDs, and could just use the FEID which is already in 
the fixed header.

yours,
Joel

---

From: Joel <[email-masked]>
Date: Tue, 26 Feb 2013 09:02:03 -0500

Why would we use a transport protocol between two adjacent FEs?
I will grant that if we are wrapping it up in IP, we could use the IP 
fragmentation.  But that seems an awful lot of overhead.  Between two 
devices which have layer 2 connectivity to each other.
A UDP header does not see to do us any good.
And I do not want a flow controlled or retransmitting transport within 
the IP dataplane.

Your,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 26 Feb 2013 17:00:37 -0500

On Tue, Feb 26, 2013 at 8:58 AM, Joel <[email-masked]> wrote:
> that any physical device supporting multiple NEs could ensure that the FEs
> had distinct IDs, and could just use the FEID which is already in the fixed
> header.

>From what i have seen around virtualization, the NEID is an important piece
because the FEIDs may infact overlap across tenants. So we need that info
somewhere.

> And I do not want a flow controlled or retransmitting transport within the
> IP dataplane.

It is feasible that a service chain may go across networks (in particular
with virtualization involved) and therefore one has to run over IP.
We wanted to leave that option open. Agreed, if you were to go that path,
you dont want some reliable transport that will retransmit. Not sure if you
want something that handles congestion control (UDP would be out).
But the general idea was we did not want to impose connectivity/transport
to be used.  Our goal is just to get the information across that allows
us to continue the service graph.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 26 Feb 2013 17:10:34 -0500

can you elaborate on the case of overlapping FEIDs?
I can think of two cases I know of:
1) Each FE is a complete virtual machine.  In that case, each one has 
its own MAC address.
2) The individual FEs are created through the ForCES manipulation of a 
master FE.  In that case, the master can assign the FE-IDs so that they 
don't overlap.

I presume there are other cases I have missed?

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 26 Feb 2013 18:13:23 -0500

On Tue, Feb 26, 2013 at 5:10 PM, Joel <[email-masked]> wrote:
> 1) Each FE is a complete virtual machine.  In that case, each one has its
> own MAC address.

That would cover what i am interested in:
The only difference is when you have multiple tenants. All possibly running
on the same location. In that case even the MAC address is game to be
overlapping.
VLANs (one per tenant) could be used to restrict tenant broadcast domains if
you are running over 802.1q to resolve that challenge; other proposals
have been
made in the gazillion tunneling proposals out there like VXLAN and what the
nvo3 folks are doing; some network/NEID is needed to map the proposal here
to any of these approaches should there be need to - but we are striving for
simplicity as well and not depend on their presence (per the fixed header
discussion).

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 26 Feb 2013 19:18:02 -0500

If you have multiple tenants, you have to have other means of tenant 
isolation.  Generally, MAC addresses are not duplicated across tenants 
in the same physical device.  Also, there is usually also enforced VLAN 
segregation.

It would seem that combination would cover what ou wanted to accomplish 
with the NEID.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 27 Feb 2013 07:32:04 -0500

On Tue, Feb 26, 2013 at 7:18 PM, Joel <[email-masked]> wrote:
> isolation.  Generally, MAC addresses are not duplicated across tenants in
> the same physical device.  Also, there is usually also enforced VLAN
> segregation.

We probably dont differ in that thought. We are saying in presence of
such infrastructure it could be made use of. i.e someone would take
the NEID and map it to a vlanid and we are set. Or if they want to
use the VXLAN, they could etc.
This is why we were making the NESelector optional.
But if they want to use none of the above, they should be able to set the
NEID somewhere. If we are going to use a fixed header - then somewhere
in there would be an optional NEID.

cheers,
jamal

> It would seem that combination would cover what ou wanted to accomplish with
> the NEID.
>

---

From: Joel <[email-masked]>
Date: Wed, 27 Feb 2013 09:08:03 -0500

Optional fields in the basic message demultiplex path make me nervous. 
They tend to be less tested and more error prone.  Architecturally, 
prefer if messages are addresses consistently.

Among other things, that meas that you have to ensure consistent 
configuration on the generator and receiver.  Which is error-prone.

Thus I am looking for simple and consistent.

Also, unless there i a case where we need the NEID, we should not have 
it as addressing / delivery information.   Even as piece of extra 
metadata that a receiving LFB can check if it wants, there really should 
be a case where it adds value before we define it and expect generators 
to add it.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 27 Feb 2013 13:47:41 -0500

On Wed, Feb 27, 2013 at 9:08 AM, Joel <[email-masked]> wrote:
> Optional fields in the basic message demultiplex path make me nervous. They
> tend to be less tested and more error prone.  Architecturally, prefer if
> messages are addresses consistently.
>

So it seems like we could just re-use our 24B header then. It would
have a slightly different interpretation when it is an interfe redirect
message type is used.
e.g the from/to would be FEID addresses.

> Also, unless there i a case where we need the NEID, we should not have it as
> addressing / delivery information.   Even as piece of extra metadata that a
> receiving LFB can check if it wants, there really should be a case where it
> adds value before we define it and expect generators to add it.
>

So back to my original question Joel:
if the message is unidirectional(from one FE to another) and we
have this 64bit correlator field available that is not useful
(since semantics of correlator are bidirectional) then we could abuse it
to store a 32-bit NEID when needed. A value of 0 or in case the NEID
is mapped to something like a VLAN or some other tunnelid implies
it is to be ignored.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Wed, 27 Feb 2013 13:53:58 -0500

We could use the correlator for the NEID.  What I was actually thinking 
of is using it for the fragment numbers (and use some flag bits for 
fragmenting when the message is carried over a size-limited packet stream.
There are probably enough bits that we could use a flag to indicate the 
correlator is being reused, and then use one piece for the NEID and one 
for the fragmentation ID.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 27 Feb 2013 16:11:38 -0500

We have enough flag space and a spare 32 bit out of the correlator
for the fragmentation info.

cheers,
jamal

On Wed, Feb 27, 2013 at 1:53 PM, Joel <[email-masked]> wrote:
> We could use the correlator for the NEID.  What I was actually thinking of
> is using it for the fragment numbers (and use some flag bits for fragmenting
> when the message is carried over a size-limited packet stream.
> correlator is being reused, and then use one piece for the NEID and one for
> the fragmentation ID.
>
> Yours,
> Joel
>
>
>>> They