headers
Jamal Hadi Salim | 1 Feb 2004 03:02

Re: FE Capabilities and attributes section of the model draft

On Sat, 2004-01-31 at 18:11, Joel M. Halpern wrote:

> The FE Attributes are certainly related to the FE state.  They are intended
> to model the state aspects of the FE as a whole that the CE will need
> cognizance of.

Fine - its one of those greyish things.
FEAttributesType could be abstracted further into three categories:
- FEProductData = { vendor, model}
- LFBpolicyData = { LFBInstances, LFBTopology}
- FERunningState = { FEStatus, FEConfiguredNeighbor }

I dont think youll have to change SupportedAttributes if you rearranged
things.

> The examples I included are pretty weak, but we assume that
> there will be some useful attributes.

The example is OK i found. There could be more.

>
> >- The FE should probably have a name and provisioned numeric ID.
>
> The FE presumably has / needs an identity.  However, whether it needs a
> name, a numeric ID within the protocol, or merely an IP address is yet to
> be determined.  If it is internal to the protocol, then it should be
> reflected in the model.

The name or ID i am refering to are for more for management purposes;
Maybe its an implementation specific, so i will wait.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 1 Feb 2004 16:14

Re: Metadata model for the ForCES model

Hi Zsolt,

Some comments:

+ I think with FE-FE metadata we are now treading into FE-FE
domain. I have no problem with this, at least the model related to the
metadata would be good to see in the draft. A lot of chip vendors (and
box vendors) already have protocols implementing interFE metadata
transfers as proprietary - they call them "stacking protocols"
(typically attached to a frame). While it may be too early to get
involved in such a beast, i think it should be put into consideration
(it is only mentioned in passing). I had a conversation on this in MPLS
with Alan Dekok and wouldnt mind coauthoring a draft with interested
people.

+ The first 3 sections are well written
Theres a claim that register based metadata is "more efficient". This
claim is not substantiated in any text. Also not sure why a scheme
on how metadata is _implemented_ needs to be mentioned in a model.
Metadata "moves" with the packet. Model shouldnt care how.

+ section 4 The Proposed Metadata Model

- I think a TLV with flags would be appropriately model metadata.
[tag = type; split the type bits into some 4 bits for flags]
I also think there is no reason to limit the length to 32 bits
hence the reason a TLV would be a good represantation.

+ section 5 Metadata Production and Consumption
"There may be multiple consumers for the same metadata"
(Continue reading)

Permalink | Reply | 12 comments |
headers
Zsolt Haraszti | 3 Feb 2004 22:13
Picon
Favicon

Re: Metadata model for the ForCES model

Jamal,

Thanks for your valuable comments.  See my replies embedded.

On Sun, 2004-02-01 at 10:14, Jamal Hadi Salim wrote:
> Hi Zsolt,
>
> Some comments:
>
> + I think with FE-FE metadata we are now treading into FE-FE
> domain. I have no problem with this, at least the model related to the
> metadata would be good to see in the draft. A lot of chip vendors (and
> box vendors) already have protocols implementing interFE metadata
> transfers as proprietary - they call them "stacking protocols"
> (typically attached to a frame). While it may be too early to get
> involved in such a beast, i think it should be put into consideration
> (it is only mentioned in passing).
Good comment.  The consideration I had was that we nail down an
LFB-to-LFB communication model which should be independent of
whether the communicating LFBs are on the same FE or on two or more
separate FEs.  This model does not specify how the communication
happens, it only says that if we want to define LFB classes and program
LFBs instance via the ForCES protocol, this is how we have to think
about passing per-packet state from one LFB to another.  So, so far
the model text leaves the actual implementation of LFB-to-LFB
communication completely open (well, the ForCES model does not ever
require that LFBs within an FE are  implemented as distinct processing
stages...).

Within an FE I expect that the vendors will always have infinite
(Continue reading)

Permalink | Reply | 11 comments |
headers
Joel M. Halpern | 3 Feb 2004 22:56

Re: Metadata model for the ForCES model

Interesting.  I had not read your meta-data description as addressing that.
I had assumed that the only reason for talking about FE-FE level meta-data
was to make clear it was out of scope.  Since packets leaving an FE are
presumed to be IP packets, I would expect normally want those to be just
plain vamilla IP packets.
Some implementations may use the available information to try to do
something extra.  That has been true of all routers.  But I would not
expect it to be within scope for ForCES.

Yours,
Joel M. Halpern

At 04:13 PM 2/3/2004 -0500, Zsolt Haraszti wrote:
>The consideration I had was that we nail down an
>LFB-to-LFB communication model which should be independent of
>whether the communicating LFBs are on the same FE or on two or more
>separate FEs.  This model does not specify how the communication
>happens, it only says that if we want to define LFB classes and program
>LFBs instance via the ForCES protocol, this is how we have to think
>about passing per-packet state from one LFB to another.  So, so far
>the model text leaves the actual implementation of LFB-to-LFB
>communication completely open (well, the ForCES model does not ever
>require that LFBs within an FE are  implemented as distinct processing
>stages...).
>
>Within an FE I expect that the vendors will always have infinite
>freedom how the ForCES model is realized.
>
>Between FEs's, however, the model does put some requirements on the
>implementation.  At the minimum, it implies that a certain set of
(Continue reading)

Permalink | Reply | 9 comments |
headers
Steven Blake | 3 Feb 2004 23:15

Re: Metadata model for the ForCES model

On Tue, 2004-02-03 at 16:56, Joel M. Halpern wrote:

> Interesting.  I had not read your meta-data description as addressing that.
> I had assumed that the only reason for talking about FE-FE level meta-data
> was to make clear it was out of scope.  Since packets leaving an FE are
> presumed to be IP packets, I would expect normally want those to be just
> plain vamilla IP packets.
> Some implementations may use the available information to try to do
> something extra.  That has been true of all routers.  But I would not
> expect it to be within scope for ForCES.

Ingress FE X receives packet, performs forwarding lookup, determines
packet should exit node on output interface Z on FE Y, via nexthop W.
Packet is forwarded to from FE X to Y.  How does FE Y determine Z & W?
o  Y performs duplicate forwarding lookup
o  Y uses metadata passed from FE X to convey Z & W.

Either case involves CE-FE configuration on Y.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <steven.blake <at> ericsson.com>
Ericsson IP Infrastructure                +1 919-472-9913
Permalink | Reply | 8 comments |
headers
Joel M. Halpern | 3 Feb 2004 23:25

Re: Metadata model for the ForCES model

Given that the Fi reference point is explicitly outside of scope ("is not
currently defined by the ForCES architecture"), I had assumed that for now
the only choice was for FE Y to perform a duplicate lookup.
Or, to phrase it differently, I would say that under the current
environment FE X would determine that its next hop is FE Y, and FE Y would
determine that its next hop is W.  It is certainly true that this requires
CE configuration of FE X and FE Y.  But it does not require or expect any
metadata to be passed from FE X to FE Y.

In general, given that Fi is outside of scope, I think of all traffic to
another FE as if it were to another NE.

Yours,
Joel M. Halpern

At 05:15 PM 2/3/2004 -0500, Steven Blake wrote:
>On Tue, 2004-02-03 at 16:56, Joel M. Halpern wrote:
>
> > Interesting.  I had not read your meta-data description as addressing that.
> > I had assumed that the only reason for talking about FE-FE level meta-data
> > was to make clear it was out of scope.  Since packets leaving an FE are
> > presumed to be IP packets, I would expect normally want those to be just
> > plain vamilla IP packets.
> > Some implementations may use the available information to try to do
> > something extra.  That has been true of all routers.  But I would not
> > expect it to be within scope for ForCES.
>
>Ingress FE X receives packet, performs forwarding lookup, determines
>packet should exit node on output interface Z on FE Y, via nexthop W.
>Packet is forwarded to from FE X to Y.  How does FE Y determine Z & W?
(Continue reading)

Permalink | Reply | 7 comments |
headers
avri | 4 Feb 2004 02:13
Picon
Favicon
Gravatar

Re: Metadata model for the ForCES model

On 2004-02-04, at 07.25, Joel M. Halpern wrote:

> In general, given that Fi is outside of scope, I think of all traffic
> to
> another FE as if it were to another NE.
>

Wouldn't that violate the rule that an NE, no matter how many parts it
is composed of, should appear to be a single entity.  If we assume that
FE-FE messaging is normal IP as if it were NE-NE then we may have
problems meeting that requirement.

I agree the current charter prohibits making FE-FE protocols a work
item, but I don't think that eliminates the need for implementations to
have a solution other then the passing of straight IP packets.
Including a metadata model that covers this seems like a good idea.
Personally I am glad someone is working on it.  I know I am more
concerned with the WG getting the model right then worrying about
specific protocol implementations.

a.
Permalink | Reply | 6 comments |
headers
Joel M. Halpern | 4 Feb 2004 02:22

Re: Metadata model for the ForCES model

I do not believe that would violate single system appearence at all.
Appearing as a single system is a matter of management protocol
interactions and routing protocol advertisements.  It has nothing to do
with the packets flowing between FEs.

Yours,
Joel M. Halpern

At 10:13 AM 2/4/2004 +0900, avri <at> acm.org wrote:
>On 2004-02-04, at 07.25, Joel M. Halpern wrote:
>
>>In general, given that Fi is outside of scope, I think of all traffic
>>to
>>another FE as if it were to another NE.
>
>Wouldn't that violate the rule that an NE, no matter how many parts it
>is composed of, should appear to be a single entity.  If we assume that
>FE-FE messaging is normal IP as if it were NE-NE then we may have
>problems meeting that requirement.
>
>I agree the current charter prohibits making FE-FE protocols a work
>item, but I don't think that eliminates the need for implementations to
>have a solution other then the passing of straight IP packets.
>Including a metadata model that covers this seems like a good idea.
>Personally I am glad someone is working on it.  I know I am more
>concerned with the WG getting the model right then worrying about
>specific protocol implementations.
>
>a.
(Continue reading)

Permalink | Reply | 5 comments |
headers
avri | 4 Feb 2004 03:04
Picon
Favicon
Gravatar

Re: Metadata model for the ForCES model

Well, if IP is used between FEs, without any metadata in the exchange,
then wouldn't it involve  forwarding as it it were a hop?  And while it
is true that the receiving FE could treat the packet specially and not
modify the packet based on the extra hop, this would involve implicit
'metadata' that this wasn't being forwarded from outside the NE and not
as if between NEs.

Also, wouldn't there be a concern with the assignment of IP addresses
to each of the FEs.  Or would this be done based on some internal
private IP address space.

Maybe I don't really understand what you mean when you say an FE passes
a packet to another FE as if it were being passed to another NE.

a.

On 2004-02-04, at 10.22, Joel M. Halpern wrote:

> I do not believe that would violate single system appearence at all.
> Appearing as a single system is a matter of management protocol
> interactions and routing protocol advertisements.  It has nothing to do
> with the packets flowing between FEs.
>
> Yours,
> Joel M. Halpern
>
> At 10:13 AM 2/4/2004 +0900, avri <at> acm.org wrote:
>> On 2004-02-04, at 07.25, Joel M. Halpern wrote:
>>
>>> In general, given that Fi is outside of scope, I think of all traffic
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joel M. Halpern | 4 Feb 2004 03:25

Re: Metadata model for the ForCES model

There probably is an issue of hop count.  Personally, I consider such
double decrementing a very good idea, as it avoids accidental internal loops.

Other than that, the IP addresses are just the interface IP addresses of
the NE.  If the links between the FEs are multi-access, they will need IP
addresses.  They will need them even if that network is otherwise
concealed, and even if the protocol were not IP.

One can craft all sorts of reasons why it might be nice to treat the Fi
links differently.  And later, we might choose to do so.  But the topology
and scope documents clearly state that we are not defining a protocol for
that.  And we can meet a reasonable definition of a "single system image"
without defining or using a special protocol on those links.
Given that the system works when we treat those links as carrying IP over
BACK (ie any technology used for the interconnect which supports IP
packets) it seems that we keep our work bounded and within defined scope if
for now we just use that.

Yours,
Joel M. Halpern

At 11:04 AM 2/4/2004 +0900, avri <at> acm.org wrote:
>Well, if IP is used between FEs, without any metadata in the exchange,
>then wouldn't it involve  forwarding as it it were a hop?  And while it
>is true that the receiving FE could treat the packet specially and not
>modify the packet based on the extra hop, this would involve implicit
>'metadata' that this wasn't being forwarded from outside the NE and not
>as if between NEs.
>
>Also, wouldn't there be a concern with the assignment of IP addresses
(Continue reading)

Permalink | Reply | 3 comments |

Gmane