Subject: FW: Requirements

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 23 Sep 2003 18:12:20 -0700

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
>