Subject: Re: Metadata model for the ForCES model

From: "Yang, Lily L" <[email-masked]>
Date: Thu, 5 Feb 2004 09:41:11 -0800

Jamal -- I don't quite understand your last statement below. Don't you agree:
1) FE-FE is indeed out of scope for now.
2) In prinicple, the metadata model that Zsolt posted is still necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) metadata modeling.
3) It is extra nice (bonus) if this same metadata model can work across both intra-FE and inter-FE domain. 

It is absolutely important for the WG to agree on 1) and 2) above. 3) is optional but nice to have, so lets not be too concerned about it for the time being.

Lily

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]]On Behalf Of Jamal Hadi Salim
Sent: Thursday, February 05, 2004 8:56 AM
To: [email-masked]
Subject: Re: Metadata model for the ForCES model

The problem (challenge actually) is this stuff exists already.
Looking the other way may not be the best option.
I agree with Zsolt's statements below.
If we want to say its outside the scope, then the text on metdata
that Zsolt posted is overkill already and may need a lot of chopping.

cheers,
jamal

On Wed, 2004-02-04 at 12:31, Alex Audu wrote:
> I am assuming this meta-data thing is all in context of having the CE
> successfully
> configure the FEs.  Unless this requires  FE-FE communication, I don't see any
> reasons for extending this to include FE-FE.
>
> Regards,
> Alex.
>
>
> Zsolt Haraszti wrote:
>
> > A couple of comments:
> >
> > 1. The fact is that most real distributed (multiblade) routers
> >     forward metadata from one blade (e.g., ingresss) to another
> >     (e.g., egress).  This simply allows optimal distribution of
> >     processing functions across the involved FEs.
> >     Not only that they forward metadata in addition to the IP packet
> >     being sent, but it may also be that the packet is not a
> >     complete/valid IP packet.  Since this is all within the node,
> >     it's all legitimate.
> >
> > 2. Just because it is not an IP packet or not only an IP packet,
> >     it does not mean that ForCES must include it in its scope.
> >     If it is not in the scope, so be it.  Then it will be left
> >     for the vendors, or to some other standards bodies to deal
> >     with it. (FYI, the NPF is addressing the inter-FE metadata
> >     encapsulation via a messaging LFB and messaging protocol).
> >     BTW, I think the ForCES work is still very useful, even if
> >     the inter-FE messaging is not in its scope.
> >
> > 3. Even if the inter-FE messaging could be put into the ForCES
> >     scope, we should still ignore it for the time being, and
> >     focus on the model and the CE-FE communication.
> >
> > /zsolt
> >
> > Joel M. Halpern wrote:
> > > 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, [email-masked] 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
> > >> 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, [email-masked] 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.
> > >
> > >
> > >

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 5 Feb 2004 12:50:03 -0500

> It is absolutely important for the WG to agree on 1) and 2) above. 3) is optional but nice to have, so lets not be too concerned about it for the time being.

I dont see why modelling 3) should be any different.
The transporting of such metadata is definetely out of scope.

cheers,
jamal

---

From: [email-masked]
Date: Fri, 6 Feb 2004 10:07:08 +0900

I don't think I quite agree.

Yes FE-FE _protocols_ are out of scope.  but LFB - LFB even when across
FE should not be out of scope for the model.  How that info get
conveyed across the FE boundary is out of scope, but the info should
not be.

So I guess I am saying that I see (3) as more then just nice.

a.

On 6 feb 2004, at 02.41, Yang, Lily L wrote:

> 2) In prinicple, the metadata model that Zsolt posted is still
> necessary (i.e., not overkill) even just for intra-FE (LFB to LFB)
> metadata modeling.
> 3) It is extra nice (bonus) if this same metadata model can work
> across both intra-FE and inter-FE domain.
>
> It is absolutely important for the WG to agree on 1) and 2) above. 3)
> is optional but nice to have, so lets not be too concerned about it
> for the time being.
>
> Lily
>