ForCES Meeting Minutes – Dec 10, 2001, 1930-2200 Notetakers: David Putzolu, Patrick Droz draft-ietf-forces-requirements-01 – Avri Doria Focus on changes since last draft – open issues that were unresolved in -00 Changes: Tightened up definitions Pre-association phase and post-association phase – what is pre-association phase vs. post-association phase? Agreed that pre-association was discovery (who is my FE/who is my CE?) and post-association was connection establishment and control of FE by CE Multiple-CE issue – decided to allow multiple CEs but declare that CE-CE communication would be out of scope for the ForCES protocol – re-charter later if we want to do it FE Model – must express logical packet processing capabilities of the FE Two layer model Management issue – NE appears as one entity on the network – including management. However, people may still want to use a MIB for their FE, etc. Recognized and accepted that external management may access a FE for monitoring and transitioning from pre- to post-association phase. Transport Protocol – for IP networks an RFC2914 compliant transport will be used. Still need application layer reliability (e.g. acknowledge command success) Questions? Kathleen Nichols – PacketDesign: Question on QoS section – reference to a draft – should correct references to be to RFCs not drafts V. Sharma – Q: When you have mgmt traffic – typically you go to the CE directly rather than the FE. A: We assume that most access is through the CE – just accepting the fact that some may want to go directly to FE – cannot preclude it. David McDysan - Worldcom – Q: Messages received by FE that need to be processed by CE. May want to mention in requirements that ability to place controllers or multiple controllers in the network is needed. Be more detailed Ram Gopal – Nokia – Q: Why does the FE Manager talk to the FE – should it talk via the CE? A: Pre-association phase is where FE mgr. needs to talk to FE – it is the entity that informs the FE who its CE is. Q: Is CE and FE mgr in scope of ForCES? A: Yes, CE and FE managers are outside scope of protocol, but exist. Comment: Should elucidate that these are not part of the protocol or say that the minimum requirements and say rest is off the table (e.g. we don't care). ? - Q: Maybe in this document we need to address the issue of crashing of FE or CE. A: Will go back and check if there, if not will add it. ? - Comment: May often have management PDUs going through the FE to the CE – is an engineering issue Alan DeKok – Solidum: Q: 6.2.1.1 Some short text on classification – DiffServ model draft should be referenced here. Chairs: Last call? No strong opinion in the room – decided to do another iteration of the draft before going to last call. draft-crouch-forces-applicability-00 – ForCES Applicability Statement – Mark Handley Why does ForCES need one? Try to make sure we are all on the same page – say both what we want to do and what ForCES isn't. Don't expect this to become standard until ForCES protocol itself goes to RFC ? - Comment: This is perfect for an informational RFC – good place to discuss important issues like what uses of ForCES. A: Don't want to micromanage but do want to give good guidelines. Manav Mishra - Intel: FE to FE communication question – haven't mentioned FE to FE or CE to CE. A: Still don't have consensus. Margaret Wasserman – Wind River: Value of writing this now? Isn't this requirements? A: These are more bounding the problem than specifying requirements for a solution. ? - Comment: We are scoping what the design and application of the protocol should look at – don't use it for Dave McDysan - WorldCom: Requirements should take inspiration from this – maybe should defer this till later. Also, label-switching being out of scope may make this work more experimental as we may need that function to be used in production. A: IESG initially directed us to focus on the things that don't exist – IP. Bill Fenner – Routing AD: Look at applicability statement as something saying what we don't have to solve as opposed what we do have to solve. Thus lets us focus better on what we do need to solve. A: Agree completely. Reason this document was people were talking about using ForCES for thing such as controlling an entire WAN from one central box, etc., - wanted to focus ForCES more to not solve all possible configurations. Chairs: Should we make this a working group document? Rough consensus in the room for making this a WG document. Will take to list for confirmation. draft-anderson-forces-model-00 – ForCES Model and Architecture – Todd Anderson Architecture Picture ? - Comment: Can be extremely complicated to have multiple CE coordination – would be interesting to see on the list who wants to do this. Ram Gopal: What if one CE set controls one FE, another set con Margaret Wasserman: CE sets useful for failover, etc. Ram Gopal - Any CE should be able to talk to any FE. ? – From ForCES protocol perspective should we have one CE or multiple CEs? Is it relevant? A: Need to just explain this model in order to have the FE be aware of multiple CEs. Comment: Don't want to duplicate what is in other working groups. A: GR is out of scope – most seem to think that Avri Doria: Comments: FEs are logical FEs; Many CEs can be talking to same FE at same time – up to CEs to keep themselves coordinated. CEs also need a way to discover other CEs – that may need to be dealt with. A: Maybe that is part of GC. Margaret Wasserman: Do the FEs need to tell CEs if other CEs have done something? If we can keep that out of scope things are simpler. Avri Doria: Agreement – FEs should not need to keep CEs coordinated. Ram Gopal: This brings out some open issues in requirements and applicability documents. FE Model ? – When do you assign namespace – part of capability exchange? A: IANA assign. Q: What if two FEs have same capabilities? A: Send same info to CE – use the same namespace of FE types. Q: How does CE differentiate FEs? A: Via protocol connection ID (endpoint ID). Comment: FE has to know which namespace it belongs to. A: FE has to know values of names for its capabilities. Comment: How is range conveyed prior to protocols like RIP, etc. running? A: Range is used to say what acceptable values a FE can support for the value of some configured protocol. Mark Handley – Where do stage instances appear from? Some are inherent abilities of FE, some might be configured from CE – i.e. configure together these five things. A: FE exposes a fixed topology of stages. Comment: Should not rule out reconfiguration at the start. Manav Mishra – Intel – Q: Do stages or capabilities and stages get reported to CE? A: Both – first list supported stages, then their types, then the topology of their graft. Q: What about how things are restricted? A: Reported on a per-property basis. V. Sharma – Q: If you do reconfiguration, is traffic interrupted? A: Probably Consensus that due to the newness of this draft it should go through another iteration before acceptance as a WG document. General Comments Bill Fenner (AD) said that the WG has documents we want to get feedback soon. Open issues should be posted to the mailing list that people can comment on the unsolved or unresolved problems. There were also a number of comments made to include FE-to-FE communications.