Last Modified: 2005-01-18
| Done | Submit requirements document to IESG | |
| Done | Submit framework document to IESG | |
| Nov 04 | Submit forwarding element functional model document to IESG | |
| Mar 05 | Submit formal definition of controlled objects in functional model | |
| Mar 05 | Submit protocol selection/definition document to IESG | |
| Mar 05 | Submit applicability statement to IESG |
| RFC | Status | Title |
|---|---|---|
| RFC3549 | I | Linux Netlink as an IP Services Protocol |
| RFC3654 | I | Requirements for Separation of IP Control and Forwarding |
| RFC3746 | I | Forwarding and Control Element Separation (ForCES) Framework |
|
Minutes ForCES WG at the IETF62 in Minneapolis St. Paul, USA
------------------------------------------------------------ Agenda, IETF 62 Monday, March 7, 2005, 9:00-11:30 ================================= CHAIRS: David Putzolu <David.Putzolu@intel.com> Patrick Droz <dro@zurich.ibm.com> ADs: Alex Zinin <zinin@psg.com> Bill Fenner <fenner@research.att.com> AGENDA: 10 min - WG status & Agenda Bash - chairs 10 min ForCES Intra-NE Topology Discovery Furquan Ansari draft-ansari-forces-discovery-01.txt 15 min - ForCES Forwarding Element Model Joel Halpern draft-ietf-forces-model-04.txt 30 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Shuchi Chawla draft-khosravi-forces-tcptml-01.txt 30 min - ForCES Protocol Draft Status & Changes Avri Doria or Jamal Salim draft-forces-protocol-02.txt Minutes ------- Attendees: 35 Unfortunately there was no volunteer to take minutes therefore, I recorded the meeting. The chairs began the meeting by reviewing the agenda and then going over the status of the group. It was stated the the protocol was expected to go through 1 or 2 more drafts before going to WG Last Call. ---------- Presentation 1: Furquan Ansari draft-ansari-forces-discovery-01.txt We then went into a discussion on the first agenda item on FE topology discovery. A first version of the draft had been presented in the last IETF meeting but at that time not many people had read the document. In the meantime quite some animated discussions took place on the mailing list. And the list came to the consensus that the draft does make sense and that is useful to have. There was no presentation of the draft. Main topic was to decide whether we should adopt the draft as a WG draft. Furquant repeats that the draft has been discussed on the list and that it seems we have reached consensus on making it a WG draft. Chair: proposes to make the draft a WG draft but wants to follow up first with the ADs. Q Avri: I am not against the draft but why do you have to check with the ADs first? A chair: Because the charter is too vague on that. It does not prevent us from doing but also does not say we must do it. After checking with the ADs the draft is now a WG document. ---------- Presentation 2 Joel Halpern draft-ietf-forces-model-04.txt There has been made significant progress on the model and the protocol draft and especially to line them up with each other. He presents the changes that have been made since the last version. Also the open issues were presented. Changes in brief: in the previous draft there was a thing that described the FE this was done by a separate schema and then the protocol team asked to make this an LFB. So the model has been changed that the FE information is now in an LFB class. There is now an ID for the class and an ID for the instance. But there is only one instance. So this is now much cleaner. There were several request to have the ability to address tables and arrays by value. So there are now methods put in place to say that this table can be referenced by value. People also wanted to have methods to share information among multiple LFBs, this is now achieved by introducing the alias mechanism. The model also turned out to have some missing type definitions so one was added but a second one might be needed as well. Changes in more depth: - FE schema changed into an LFB class definition using the same schema that all LFB classes are using. This is now the only LFB class that is defined in the model document. The LFB class definition go now into a library document. This class is assigned class ID 1 and instance ID 1. It is important to note that it is always 1 since it is the bootstrapping of the protocol. It captures all the information that was in the FE schema. When the CE comes up it gets connection to the FE then it says give me LFB class ID 1, instance ID 1. Give me the whole thing. However, this is not mandatory. But this is the typical scenario. Assigning the instance ID like this is a bit unusual. Certainly more information need to ge into the LFB class, more capabilities and attributes are needed. The list is asked to come up with the missing pieces. Probably there will be a similar LFB class to represent the interaction with the ForCES protocol with the FE. That will probably be included in the protocol document because it has protocol relevant information rather then model relevant information. - Element identifiers - The protocol now references information through class ID, instance IF of an LFB and a sequence of attribute or element identifiers with array subscripts. So those numbers need to be defined. Each one is defined within a given scope. Within a given LFB class they have to be unique. But they do not have to be unique across classes. But it is much cleaner and simpler than what we had to do in SNMP. However there is an interesting point. The way the protocol and the model is structured we assume the LFB class ID are globally unique. How to make that work? Global uniqueness is always an interesting problem. Should we keep a global list of all the class IDs? We need to do something to make them easily globally unique. At the moment we do not know how to do it. LFB class, attributes, capabilities, and structure element have an ID. There is an ongoing stylistic debate on what belongs into attributes or nested tags. Many WGs that are using XML are having this debate when to use tags and when to use attributes. So we thought using attributes was an appropriate thing to do. If somebody has an issue with this please speak up now or raise it on the list. - Content keying - There was a major request for the ability to reference arrays and table elements by their content instead of just by their subscript. So we are supporting this. Get and set operations are supported. There was a big debate on the list what the scope of this should be. Joel thinks there was WG consensus but he knows what he has written on the foils. Key 'ContentKey' is only for predeclard keys and they must be unique within their tables. There is an example given in the presentation. You can declare to have multiple key fields and that declares that the combination of multiple key fields in a single key. That means the combination of the fields is the key and the combination must have a unique value on every entry in the array. You can also have multiple key declarations that declare each of these keys is unique in every entry of the array and you can use anyone for reference. That is the current compromise on content keying. How to call this keys is not completely settled yet. There was also some XML violations that had to be fixed. According to the XML folks introducing a container would solve the problem. This is almost an editorial change. It does not affect the protocol at all. - Alias - There are situation and this can be debated for ever where LFBs need to share information e.g. ARP LFB sharing MAC addresses. So a way is needed to describe sharing. There are multiple ways to achieve this e.g. an LFB owns the information and the other LFBs can point to it. That approach is being taken. This is basically a pointer. Now what are the properties of such pointers. The pointer needs to contain what class of LFB it points to, what instance of the LFB you are pointing to, what attribute within the LFB you are pointing to, and something that you can use to get the data. So you can declare within a LFB class definition or structure that something is an alias. An alias is used to point to something else. An alias has a type. All the way the protocol works everything is strictly typed. Therefore, the alias has to have a type. So per alias we need to have four related pieces of information. We wanted to have things simple. You create an alias, then give it a type and under the cover create a structure that can take all four pieces. They can be chained. The concept lets you easily reference information at other places. Q: if you make an alias and it points somewhere and then you remove that element. What happens to the alias? A: We do not want to require automatic cleanup. This is an important question and we have to solve this. In other cases you may also point to something that does not exist. So we would probably require that you get back Nil / Null as a result. We need to define this and what the behavior of dangling pointers is. - Open Issues - The list of the 5 open issues is: o Configured Adjacency Description - o Element Meta Information o Events o Optional Elements o Unlimited length strings In more detail: - Configured Adjacency Description - The FE object has in it a set of information about configured FE neighbors. This is what the WG decided. This includes information of the MAC and IP address of the neighbor. This seems to be the natural way of configuring neighbors. Jamal raised an interesting alternative. This kind of configured neighbors is really used by the CE that has multiple things that it controls who are neighbors to each others. A better way to discover this is the ansari draft on FE topology discovery but there was a request to have the configuration capability. So what when you just configured the neighbor FE ID and the port that he reaches you. This will tell you how to send a messages to the guy because this is enough information. So we basically have to methods of identifying neighbors. What is important is that we have to pick one method. It is important to note that this is for configured neighbors and not for real discovery. Q. What happens if you use both methods could you get a conflict. A: Yes, if you configure both you could indeed get a conflict. You could mix up some of the values. So you do not want to use both. We have to pick one or the other. That is why I brought it up. - Element Meta Information - We have LFB elements, structure elements, in the model and referenced by the protocol. These elements have properties. The simplest property is, does it exist, is it readable, is it writeabel. It may have other properties. We have foreseen for LFB level capabilities that are described in the model. And if you look at the FE object LFB it has a capability section. So this was captured but only at the LFB level. If you have an FE with a structure of option elements, how do you know whether they are supported. If you have a structure that is readable or read / writeabel how do you know what information there is. Just try it? Maybe we need to find a consistent way of talking about properties of elements. When you think about arrays, arrays have an additional set of properties. How many elements do you have currently, what is the highest subscript currently being used, maybe what is the first hole that might be useful for reusing the space. So arrays have more complicated properties. When you look at the aliases I was showing you earlier, you can easily talk about pointers that have properties of the actual pointer element. It makes the alias cleaner if you can talk separately about the properties and its values. Then the value would always be the pointer and the properties would be the LFB attributes. So it seems that if we could talk about the properties of any given piece of information in the LFB structures would be a useful generalization. And we could use the class that we put into the data path in the protocol to indicate that we are talk about the property instead of the data. But this implies that we are talking about how do we define what the property information is for each object we can have. We can define those as structures themselves. So there are structures for the array properties and so force. That would allow us to consistently talk about them. Joel thinks that we should add this feature. But it is a major increase in complexity. That is why he is reluctant in doing it. Joel asked the floor for comments. There are just some nodding heads but no comments. Joel will post additional information on the subject to the list. - Events - Thins can happen at the FE that the CE needs to know of. These are things that need to observed now and not a certain period afterwards. So we need to have a mechanism for the FE to send up reports or notifications to the CE called events. A different thing would be from the CE to the FE. We have to define a number of things about the events. For each LFB we have to somehow say what events can each LFB generate and we have to create some mechanism for the FE to say I want this event. But as the number of events is probably going to be large we do not want to mandate that each FE shall consider all events and each CE will be perceived by each event. So depending what the elements are doing they may not be interested in all the events. It might be reasonable to be able to subscribe to events. So we need a way to subscribe to events. We also have to create IDs for the events. I identified two ways of defining the events but there are probably more. One way of doing it is for each structure definition, for each array definition you could include in it the event definition with the structure definition and then create the appropriate identifiers with boolean pieces for the sign-up. At the LFB level you would ave another event declaration for the LFB level of events. This gives some simplicity to it but that is also its draw back. It means that when I have the same structure used in multiple places one needs to know at creation already who is interested in what. So this method is probably not feasible. The other alternative is to have in the LFB definition an event section in which you define all the events of interest for that LFB. But that means you have to reference all the top level things and any structures that are buried in arrays. So the whole thing ends up with a much more complex naming problem. Though it is much more powerful and more verbose. Which one to pick is currently not known. That is why I brought it up for discussion. But it is clear we need to have the events defined somehow. Q: Is correlation of events and root cause analysis within scope? A: What I believe is within scope is we have to define what is supported in the events whatever method we are going to use. I don't think that correlation and root cause analysis is our problem but we should have enough information such that is useful for the CE to find out what heck to do with this. If for example an Ethernet switch is failing that is certainly not a ForCES problem. It is however an important problem. Q: Can I turn on and off all events or can I turn on and off some events for a certain table? A: We probably have to allow some of these things but I hope we will not go overboard with this! This can become very complicated especially for the FE. I hope we can keep this simple to implement. Scope sign-up's on tables has not been put in yet but Jamal really would like to have it. For example I would like to have a status update for every port up or down on a certain table. And you do not need to sign up for every new port for that particular event. Side comment, event history is not the FE's job. This is definitely the CE's job. Q: Are events reliable. A: The ForCES protocol is reliable and so are the events. They run over TML and this is for example TCP which is reliable. There are 2 more changes to the model. One went in the other did not. The model had text strings that had a fixed length. This was always fixed. There were multiple places while I was doing the LFB FE object where I needed a binary string which was up to a certain length but was not always that length. So I added a type for that one. Strings are defined as variable length but they have a length limit. In some places we needed unlimited length. In some cases it was unclear whether we needed a length or not and if yes how long it should be. And I think it is not the model's job to say it must be length so and so. So we probably need an unlimited length string in the model. And a property of such a string would be how long it is. Q: But unlimited length strings do have security problems. A: No the security problem comes from buffer overflow. But in our case the CE or FE has to make sure the the unlimited length string is not going to exceed the size of the buffer. The security problem comes only if you do a bad job of implementing this. We can define a max length and maybe we should but I could not come up with a length limit that made any sense. So folks may look at the FE LFB definition and see if they can come up with a reasonable length limit for every place I had to put in a length limit. Or we can go with an unlimited length string. What was also added are derived classes to the model. How to implement this is part of the XML debate. Presentation 2: Shuchi Chawla draft-khosravi-forces-tcptml-01.txt I will go through the revisions that have been made to the draft since the last meeting. I will start with a brief overview of the TCP/IP based TML. Due to the ForCES requirements of reliability and flow control we have picked TCP. By picking TCP the TML does not have to do any additional things to meet those 2 requirements. Then ForCES also requires that security should be addressed so we propose to use TLS for security. As in the ForCES protocol the CE is the master and the FE is the slave, the CE would be setup as the TLS server and the FE as the TLS client. The TML draft allows for unicast, multicast and broadcast addressing. Unicast is supported by using standard TCP/IP channels and multicast would be simulated through multiple channels. Some more details will follow later. The TML draft supports prioritization in TML messages and it also prioritizes control messages over data messages. by using different data and control channels. At the moment the TML draft proposes a TML header to do encapsulation. This is currently under discussion. The reason for it was to have additional signaling messages for multicast support. So the goal is to investigate how to make things as lean as possible. The support of high availability (HA) has not been detailed yet what we have specified yet is that if the PL heart beat does not continue we would use the TML heart beat. There are methods in place to do fast switch over between the active and a standby FE or CE. DoS attacks are mitigated by the separation of control and data channels. When the data channels gets flooded with malicious traffic the control channel still remains operational. In addition, the control messages are prioritized over data packets. It is only recommended to use two TCP connections between the CE and FE, one for control the other for data. In case of a standby CE we would have additional 2 TCP channels between the backup CE and the FE. In terms of functions the CE is considered to be the server and the FE the clients. So the CE is the one that is listing on predefined ports and the FEs are going to connect to them. Channel shut down can be initiated by both sides. There is a diagram in the slides that shows how the setup / tear down looks. Q: Question on how the exact hand over between a failed active CE and a backup CE would work. - lengthy discussion including what the hardware can do or not - Editors comment and summarization: There was mainly some confusion what the exact definition of a backup CE is. Everything seemed to be clear by assuming that the backup CE just listens to everything and maintains all the states from the active CE without actively sending out messages. That is one of the HA Models. However, various HA models are possible where the backup CE may not be completely passive or there might be load sharing etc. The final conclusion (with Joel adding the final comment) was that the TML draft should not specify the HA Model or what can / cannot occur over the channels to the backup CE(s). It is outside the scope of TML. All that the TML draft should specify is that control and data channels must be established between the CE and FE, and in case of a switchover from the active to the standby CE, the FE should be able to communicate to the standby CE (or in other words, the new active) using the TCP TML channels. Unicast and multicast is supported over unicast links. The multicast is simulated over multiple unicast channels. This required the introduction of additional TML messages that are used for join and leave operation on multicast connections. The message are then replicated according to the FEs that are part of a certain multicast group. It is kind of the traditional multicast with the root at the CE and the leaves at the FEs. So it is assumed that the FE is configured with multicast group information. Q: why do you do that. This model already has been significantly modified in the SSM (Source Specific Multicast) model. In the ForCES case it is sender driven, the sender knows what to send where. An FE never knows what a particular CE wants to achieve. The sender knows exactly what to send to whom. Avri is not so sure about that. Joel is the opinion that we get a much simpler behavior if we do not try to mimic multicast. A: We were investigating 2 multicast models -- one which is FE initiated/configured mimicking traditional multicast, and one which is CE configured. We picked the one which is FE initiated under the assumption that since it mimics traditional multicast we wouldn't be reinventing the multicast model. But if the ForCES use of multicast is expected to be slightly different from what occurs in traditional multicast, we will revisit this. The proposed multicast schema is currently under investigation to find out whether it can me made leaner and simpler. The CE could for example tell to the FE in which multicast group they are which means we do not have to mimic join and leave messages. Another thing is that the same channel is used for unicast and multicast. The group / channel descriptor is going to distinguish if a message has to be sent to a single FE or needs to be replicated for a multicast group including multiple FEs. The TML supports to carry PL control and data messages and if we cannot do away with TML control messages also the TML control messages. In case we have TML control messages then there would be a TML shim header in order to support these messages. TML and PL control messages would be exchanged on the same control channel. The exact definition of the header can be found in the slides and the draft. A simplification of the header would be very welcome. The draft contains also an interface to the PL in the form of an API as a guideline of what functionality the TML can provide to the PL layer. Q: (Joel) a guideline is probably not sufficient. We need to mandate exactly what the TML can provide to the PL. We also should not provide this in the form of an API but rather in terms of a service interface. This service interface should be generic to all TML. He does not care whether the spec goes into one of the TML drafts or in the PL draft. A: I agree. We started off with an API definition. We just needed to start somewhere but we know we will have to evolve this into the exact service interface that the TML will provide. This service interface could also go into a separate draft. Then the functionality of the current API proposal is presented (see the foils). The services are: - tmlInit - tmlOpen - tmlClose - tmlWrite - tmlRead - tmlMulticastGroupJoin - tmlMulticastGroupLeave In the current model tmlOpen and the last 2 are FE initiated. Then the setup procedure is shown (see foils). Then the same thing is shown for multicast support (see foils). The presentation is given according to the currently proposed multicast model. If the multicast model would be changed into a more CE driven model then the join and leave messages would not be necessary anymore. - Open Issues - Broadcast has not been addressed so far. HA needs to be spelled out in much more detail. Message prioritization also needs further details. Finally message encapsulation and multicast model needs additional work. Shuchi concludes with a summary of the presentation. Finally Shuchi asks to make this draft a WG document. The chair asked the floor if there are any objections to make this draft a WG document. There was no opposition. The chairs and ADs had discussed this before and there was also no objections. Therefore, the draft became a WG document. But the chair raised again some points: - data channel using TCP from the TML even if it is a raw or UDP connection. Probably many routing protocol people will not at all like this as they are taking care themselves of flow control and retransmit. Also RDMA support should be thought of. A; we are considering tunneling like GRE or DCCP to address the issue. Comment from Joel: yes this should be a working group document but that does not mean we take the draft as is. Joel is also the opinion that DCCP might be a good alternative for the data channel. Take this draft as good start and progress on it. Chair comment: the service interface should either be a separate draft or part of the PL. Important is that the service interface is generic to the underlying TML as we want to have the option of swapping TMLs. Q Avri: by making this a WG draft does it mean we are considering the work on service interface and TML as WG issues. Can we split thing apart later or not? A chair: we basically have agreed on the list already that we need a generic service interface usable for multiple TMLs. We also need a TML to test different implementations against each other. Therefore, it makes absolutely sense to embrace both topics by the WG. So in the end we either have two WG documents or we attach the service interface to the PL draft. Joel is in support of adding it to the PL since there should only be one service interface for all TMLs. He suggest to move a service interface into the PL draft by the next meeting. Presentation 3: Avri Doria draft-forces-protocol-02.txt Avri gave an update of the PL draft. It is the third version of the draft. The focus is on the progress that has been made since version 02. An issue tracker has been setup and it is being used. Something still does not work with email responses going directly into the tracker. Avri will ask the tools folks about it. There was extensive discussion among the authors and some folks on the list and also with the model team (especially with Joel) to bring the protocol together with the model. Last time we had 2 separate documents (model and the protocol) that went into 2 different directions. the documents are are still not in complete harmony but significant progress has been made due to Joel's help. In the mean time a number of tracker issues have been closed, more details below. On the protocol BNF the PATH TLV is one of the bigger changes and one that impacts the whole PL draft. the presentation talks about Operations. In the document we talk about Type and not Operation. We are currently in the middle of a discussion on Types that are still called Operations. The operation type is really the T in the TLV and it needs to be expressed somehow properly in this BNF; sticking operation type in there is not the correct solution. Avri just wanted to bring it out on the slides because there still is an issue there. Comment Joel: I am not really sure whether it belongs into the TLV in this BNF. There is till a sort of inconsistency in the document when you read type we mean operation type. We have some language consistency to fix yet. So there is PATH data TLV which includes a path and optionally data. The path is flags, IDs, and selectors (optionally). Selectors are basically the key info TLV that Joel was talking about. How it is used is not fully understood yet. We have reached consensus on all the notations and how it is being used. Comment Joel: I think at the moment is is pretty clear how it is being used. But we do not know how to use it in an Addition. Comment Avri: there is still some work to be done there. Data can be DATARAW or it can be one more nested PATH Data TLV. The RESULT TLV is still to be defined. There are a couple of implications of this. There can be one or more class LFB + instance targeted in a message. There can be one or more operations on an address LFB, class ID plus instance ID combo. There can be one or more path targets per operation. It is assumed that the type of data can be inferred by the context in which data is used. Hence, data will not include its type information. There is some inconsistency between type and operation. The basis for the inference is typically the LFB ID and the path. Among the open issues we are discussing the efficiency of encoding versus the efficiency of parsing and decoding and packaging overhead. For example do we include block data and if we do, how does it work. Or can we live without it? For the ones who have read the draft you see still a lot of questions and editors notes and TBDs. Updates to all the messages had to be made because of the PATH-DATA. On the open issues. Issue one on association setup / response has been closed. There were originally 2 messages that have been merged into a single one. Issue 2 was mainly an editorial change to section 6.5.1. Issue 3 consisted of modifying the query and query response message to include the PATH DATA with the limitation that when you do a GET operation the PATH-DATA does not require DATARAW-TLV or RESULT-TLV. Issue 5 was about defining events in XML as attributes. This was made after discussions with the model team. So there will be a path that can be used by the config message for subscription. But there are a lot of open issues around this. So in the protocol we will use what comes up in the model. Issue 7 was on how paths are described in the protocol messages to target a specific attribute or set of attributes. This caused a major revision to the draft. Transactions: an important feature for transactions is the ACIDity which encompasses atomicity, consistency, isolation and Durability. There is still a lot of discussion going on on this. Abort message for doing rollback and the format of the response messages is still not defined. We are trying to say enough about these things in the PL draft but not restricting the implementation. Then Avri went through the example of a protocol message given in the slides where the structuring is illustrated. In the document there are several of these protocol visualizations depicted. Avri encouraged people to review them and report bugs and fixes. On the XML for the FE protocol LFB, the definition has been started in Appendix C but no further details are being presented at the meeting. The working group is asked to review this Appendix carefully! In Appendix D there are many examples and use cases given. The examples show how the protocol is supposed to be used. Please read through them and make sure that they are clear. At the moment we are using in all the examples type as command. As a next step to proceed with the draft all the TBDs, editor notes, and open issues note will be put in the tracker because we need to get them out of the document. Also some references need to be fixed. In addition, some consistency problems need to be fixed for example is it Type or Operation. We also need to decide if there are additional appendices required e.g. we definitely need one for types / commands. An IANA sections needs to be created. What is not on the list is a manageability sections that needs to be created. This is necessary because there was a proposal made in the routing area by Avri and others that every document in the routing area should have a manageability section. Avri, as an editor is supposed to add the section to the documents she is working on as part of a pilot. Additionally, a scrub for nits will be necessary since there are still a bunch of them in. An important goal is certainly to get the document closer to WGLC (WG last call). In order to advance the document to LC we need many more people to read and comment on the document, so please read! Probably it will not the the next revision that will make it to WGLC. Another thing we will have to do because it is the routing area, will be to have somebody from the routing directory or one of the ADs assigned to the document so that when it comes to the time for last call we got everything covered in terms of implementations and reviews Chair / AD Discussion --------------------- After the meeting I had some discussions with the ADs. They are fine with making the FE Topology Discovery draft and the TCP/IP base TML draft WG documents. In addition, we discussed the TML draft, especially the data channel. Both ADs were against enforcing the data channel to use TCP for any kind of transport. UDP or RAW packet should not go over TCP. TCP in TCP is super positioning 2 flow control methods which may lead to some unpredictable behavior. The WG has to find something more appropriate for it. Last but not least the ADs suggest to start with a simple MIB for ForCES. Things that might be included are the FE topology that can be discovered by the ansari draft. Other things of interest might be if the adjacency between FE and CE is up or down. We will need to identify information we want to export from ForCES. Most of this information is probably helpful to the operator of the box. |