Subject: Re: FW: Requirements

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Sep 2003 22:30:44 -0400

I would tend to treat the entire issue of inter-FE topology as out of scope
for the initial FORCES work.  I would expect CEs to either be configured
with the topology information, or to run any one of the many topology
discovery protocols.
This led me to consider it to be out of scope for the model.

However, folks want some information about inter-FE topology to be within
scope for FORCES.  If so, I would place it as FE attributes.

Yours,
Joel M. Halpern

At 07:14 PM 9/23/2003 -0700, you wrote:
>Joel --
>But I thought we agree (at least within the FE model design team, from our
>previous conference calls) that FE-topology is outside of the FE model,
>and so inter-FE topology info is not going to be part of the FE attributes
>as we define today. Therefore, explicit topology query/reply must be
>provided by the base protocol itself, because you aren't going to get that
>directly from FE model.
>Now, having said that, I agree with you that IF some specialized LFB is
>chartered with some kind of discovery function, then the FE topology info
>can be indirectly but effectively gathered by querying the attributes of
>such LFB -- but that is a big "IF" and is only one of the many possible
>approaches.
>So to cover the case when some FEs indeed have such topology info with
>them, a simple topology query/reply will do the work.
>
>Oh, you don't need to apologize -- the most probable outcome of a "draft"
>design is -- Oops, it doesn't work! Always better know that today than
>tomorrow though.
>
>Lily
>
> > -----Original Message-----
> > From: Forwarding and Control Element Separation
> > [mailto:[email-masked]]On Behalf Of Joel M. Halpern
> > Sent: Tuesday, September 23, 2003 6:54 PM
> > To: [email-masked]
> > Subject: Re: FW: Requirements
> >
> >
> > Actually, this implication is what concerns me.
> >
> > There must be a mechanism for the CE to query FE attributes.
> > I would sincerely hope that such attributes would be extensible.
> > It would seem sensible that one portion of those attributes
> > could and would
> > be used to reflect whatever knowledge about inter-FE topology
> > the FE had.
> > Thus, the information would be accessible.
> > But there would not be a inter-FE topology query/reply in the
> > protocol.
> > The protocol would have FE attribute query / reply, which
> > would cover many
> > cases.
> >
> > Yours,
> > Joel M. Halpern
> >
> > PS: I like your proposed rewording of the framework text.
> >
> > PPS: I truly am sorry to raise this so late.  It wasn't until
> > reviewing
> > protocol proposals that I realized the implication of the
> > requirements text.
> >
> > At 06:12 PM 9/23/2003 -0700, you wrote:
> > >Our mail server has been acting very badly lately -- I
> > didn't see this
> > >email posted to the list even after 4 hours and so here it
> > is again -- I
> > >believe what I said here basically concurs with Avri and Ellen.
> > >
> > >-----Original Message-----
> > >From: Yang, Lily L
> > >Sent: Tuesday, September 23, 2003 1:52 PM
> > >To: 'Forwarding and Control Element Separation'
> > >Subject: RE: Requirements
> > >
> > >
> > >Joel -- Sorry to ping you again when you are already tired
> > of talking :-)
> > >
> > >When you said, "a) whether to fix the requirement in the
> > I-D", did you
> > >mean the architectural requirement (section 5, #10) or the protocol
> > >requirement (section 7, #10), or both?  I do believe there
> > is different
> > >implications here depending on which one you were talking about.
> > >
> > >What I heard so far on this thread is that some FEs may have inter-FE
> > >topology info but all FEs do not. So the protocol MUST
> > support "inter-FE
> > >topology query/reply" in case some FEs are capable of
> > providing that info
> > >to CE. Architecturally, it is optional whether or not to use
> > such protocol
> > >mechanism -- as long as somehow CE can gather this
> > infomation, either by
> > >explicitly query over ForCES protocol, or by static
> > configuration, or by
> > >some dynamic discovery mechanism outside of ForCES.
> > >
> > >So I think a simple "inter-FE topology query/reply" is
> > indeed required in
> > >the ForCES protocol. But if FE can't provide that info, the
> > burden is on
> > >CE to gather that info by other means.
> > >
> > >I would like to see some consensus on this so that I can
> > make sure the
> > >framework draft accurately reflects it.
> > >
> > >Lily
> > >
> > > > -----Original Message-----
> > > > From: Forwarding and Control Element Separation
> > > > [mailto:[email-masked]]On Behalf Of Joel M. Halpern
> > > > Sent: Tuesday, September 23, 2003 4:26 AM
> > > > To: [email-masked]
> > > > Subject: Re: Requirements
> > > >
> > > >
> > > > I do not agree that all FEs have this (inter-FE topology
> > > > information).  I
> > > > have agreed that some FEs may have it.  And that having
> > standard FE
> > > > attributes to represent this is probably useful.
> > > > I do not agree that there is value in the requirement.  It
> > > > will not help us
> > > > choose among protocols.  It has already demonstrated a
> > drive to cause
> > > > protocol elements that are not needed.
> > > >
> > > > However, I have said enough for a while.  The working group
> > > > nee3ds to decide
> > > > a) whether to fix the requirement in the I-D
> > > > b) whether to clarify some other way what is needed / wanted
> > > > to meet the
> > > > requirement
> > > > or whether the group actively likes the requirement.
> > > >
> > > > Yours,
> > > > Joel M. Halpern
> > > >
> > > > At 10:50 PM 9/22/2003 -0700, you wrote:
> > > > >Hi Joel
> > > > >
> > > > >I understand your concern regarding the architectural
> > > > requirement (sec
> > > > >5, #10) and I think we could clarify the text there, if still
> > > > >possible...or may be use the Framework draft to clarify
> > > > this? Lily, any
> > > > >ideas?
> > > > >However, I believe that the protocol requirement text is
> > fine and it
> > > > >should remain. From what I have heard so far, you agree that
> > > > a) all FEs
> > > > >have this info, b) some FEs might acquire this thru some inter-FE
> > > > >discovery protocol or via FE manager and they should not
> > be precluded
> > > > >from ForCES, c) CE needs this info. If you agree with a, b &
> > > > c then it
> > > > >is natural to have some protocol mechanism to support this
> > > > (whether it
> > > > >is a general or special mechanism is a separate
> > > > issue)...unless you want
> > > > >to have a non-standard way to do this, which defeats the
> > purpose of
> > > > >ForCES. You have also agreed that it is ok to have some optional
> > > > >mechanism for this. Now if you were in the Requirements
> > team, which
> > > > >unfortunately you were not :), would you rather define optional
> > > > >requirements or mandatory ones ? This has a direct impact on the
> > > > >protocol design and interoperability.
> > > > >
> > > > >Also, I don't remember there having been any arguments or big
> > > > >discussions around this requirement before atleast in the
> > > > design team.
> > > > >The only feeback we had received was from the IESG was
> > to clarify the
> > > > >text in the Protocol Req section 7, which we did.
> > > > >
> > > > >I hope you will understand my point of view.
> > > > >Thanks a lot
> > > > >Hormuzd
> > > > >
> > > > >-----Original Message-----
> > > > >From: Forwarding and Control Element Separation
> > > > >[mailto:[email-masked]] On Behalf Of Joel M. Halpern
> > > > >Sent: Saturday, September 20, 2003 5:57 PM
> > > > >To: [email-masked]
> > > > >Subject: Re: [FORCES] Requirements
> > > > >
> > > > >A large part of my problem with this requirement is that it leads
> > > > >sensible
> > > > >implementors (such as yourself) to think that they need
> > > > special protocol
> > > > >mechanisms to support this.  It also leads sensible FE
> > > > implementors to
> > > > >think that they are somehow required to provide this
> > implementation.
> > > > >
> > > > >1) FE's better not be required to provide inter-FE topology
> > > > information.
> > > > >
> > > > >2) Allowing FEs which have such information to provide
> > it does not
> > > > >require
> > > > >special protocol mechanisms in any reasonably designed
> > protocol.  CEs
> > > > >will
> > > > >need to ask FEs for many pieces of FE level information.
> >  If we must
> > > > >have a
> > > > >requirement in this area at all, it should be a requirement
> > > > that the set
> > > > >of
> > > > >FE information a CE can query should include support for optional
> > > > >information about inter-FE connectivity.  (A CE should not
> > > > be required
> > > > >to
> > > > >ask about this, an FE should not be required to provide
> > this, and it
> > > > >really
> > > > >should not be treated as special information requiring
> > > > special protocol
> > > > >support mechanisms.
> > > > >
> > > > >Another way of looking at this is that there are many kinds of
> > > > >information
> > > > >that an FE might be able to provide that might or might not be
> > > > >communicable
> > > > >in the initial set of information mandated for CE-FE
> > > > querying.  For lots
> > > > >of
> > > > >reasons, the protocol MUST be extensible.  Making support of this
> > > > >information important relative to selecting / defining
> > the protocol
> > > > >seems a
> > > > >serious mistake.
> > > > >
> > > > >Yours,
> > > > >Joel M. Halpern
> > > > >
> > > > >At 05:35 PM 9/20/2003 -0700, you wrote:
> > > > > >The text for this requirement has always been inter-FE
> > > > topology (since
> > > > > >v-02).
> > > > > >I am pretty sure but I'll check with Todd anyways on this.
> > > > > >
> > > > > >If we do not provide protocol mechanisms to support this,
> > > > then there
> > > > > >will
> > > > > >have to be non-standard ways to obtain this information
> > > > from the FEs
> > > > > >which
> > > > > >provide this info, which we would like to avoid.
> > > > > >
> > > > > >Thanks
> > > > > >Hormuzd
> > > >
> >