Minutes ForCES WG, IETF65, Dallas, TX, USA ========================================== Attendees 36 Agenda, IETF 65: Tuesday, March 21, 2006, 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 15 min - ForCES Protocol Draft Status & Changes Avri Doria draft-ietf-forces-protocol-07.txt 10 min - Intra-NE discovery mechanism update Xiaoyi Guo draft-ietf-forces-discovery-02.txt 10 min Applicability statement Hormuzd M Khosravi draft-ietf-forces-applicability-03.txt 15 min TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Hormuzd M Khosravi draft-ietf-forces-tcptml-02.txt WG Status by the chairs: The protocol draft is in fairly good state very close to be forwarded to the IESG. Sue Hares has reviewed the draft in the function of the routing directorate. The changes from her were incorporated into the draft. Where we have a little bit more problems is with the model and the library drafts. No much progress had been made since the last meeting. This is a problem because before the protocol draft can be published as an RFC the model also needs to be forwarded to the IESG. This topic will be discussed further after the presentation of the changes and status of the protocol. There will be a presentation of the applicability statement a draft that is fairly old but has not been updated for a while. The chairs really ask to try making more progress on the model in order not to delay the overall progress of the working group. While Avri got ready for her presentation Joel raised the question of error codes. When to define them and how to define them and where they should be hosted. Currently, neither the protocol nor the model draft has addressed this. ------------------------------------------------- First presentation by Avri on the protocol: The protocol had a last call and a review by Sue Hares from the routing directorate. Sue provided a very good review of the draft. So the question is if the draft is ready to be sent to the IESG. Avri goes through the changes between draft version 6 and 7. Tracker issue 63 to 67: 63 was a bunch of editorial nits. 66 was the one that was basically a complaint on the normative dependency on the model. There was some text in the document that quoted things from the model. The text has been removed but the normative dependency remains since the model has to be there to define the LFBs. There was a fair amount of discussion on the subject inside the team. Some of the discussion took place on the list and some just inside the design team. The discussion is not closed to 100%. There was also a lower case should in the text of upper layer semantics of the TML. The discussion was if it should not be a must but definitely not a lower case should. So that was changed. There was some lack of clarity about the ACK flag when it was used in config. So the language had been clarified. 75 addressed mainly nits. 76 is almost a complete rewrite of the overview. Mainly the structure has completely changed but not the actual content. Some explanations also have been extended. 77 added a table to make certain things clearer. 78 were covered mainly by the rewrite in 76. It was basically asked for more clarifications. 79 addressed words with meaning and the appropriate reference to RFC2119. 82 addressed the author issue how many authors can be and in what sequence. This item was resolved by the chairs. A smaller set of editors is in the beginning and a larger set is in the authors. Both listings are according to the rules. 84 addressed the language in the result TLV that had to be reworded. Then all the comments from Sue had been put into the draft. There were both technical and editorial comments. After all the reviews and last call the group of authors and editors thinks that the draft is ready to be forwarded to the IESG. Since there were very limited technical changes it is believed that there is no other last call necessary. Nit checking has been done as well. But the only open issue now is if we need to add bunch of errors codes. This issue came up by Joel. This should be fairly quickly possible. The WG agreed on bringing the topic to the list and Joel already has volunteered to do so. It should be possible to bring out a new draft with the error codes within a week. Then there was a discussion about forwarding the protocol draft with added error codes alone to the IESG or wait for the model. Joel suggested sending the protocol as soon as it is done to the IESG to start the review. But the consensus was that the protocol cannot be published as an RFC before the model is done. Joel thinks that the delivery of the documents to the IESG can be serialized but the publications will be in parallel. Hormuzd is the same opinion. The chairs are also comfortable to forward the protocol at the time the issue with the error codes is solved. --------------------------------------------------- Intra-NE Discovery Draft Update by Xiaoyi: As an overview the drafts describes a way to discover the topology/layout in an NE. It operates in the Post-Association phase of the ForCES protocol and it can be implemented as a topology LFB on the FE. The discovery mechanism has two distinct operational components. In the first step the FE side component collects the FE neighbor information. It sends a Hello and gathers the one hop information. Afterwards it will send the information to the CE. The CE side component then computes the complete NE topology. In this version of the draft many updates were made to the TLV section. We added new TLVs but we think that we need even more including types and definitions. In the other sections only a few changes were made. As future work items, we want to look at the hello probe mechanism which is similar to the OSPF hello. But maybe the BFD is the better choice. We will need to do more work to study the details of the mechanism. There were not questions except for one by the chair: Q: What is the time line for the future work and the next release of the draft? A: We plan to have a new release for the next IETF. --------------------------------------------------- Applicability Statement Update by Hormuzd Hormuzd asked for feed back on both of his presentations. The intention of the draft is to describe the applicability of the ForCES protocol and model. As applicable services count: discovery of capability information, topology information, routing, QoS, security, filtering, NAT, and tunneling... The applicability statement also talks about things that are out-of-scope for the protocol and the model. As out-of-scope services count layer 2 witching and multimedia gateways. A further section addresses the locality. At the moment the scope is either a single box or at the most 1 network hop. The sections that were updated are the manageability and references section. In the manageability section there was mainly text from Avri added. The main purpose for Avri to add the section is because Avri is one of the 3 authors of the suggestion that all routing area specifications should have a manageability section. It is not mandatory so far but it makes a lot of sense to have one. It helps especially for things that are large and big. The reason for having it in the applicability statement as opposed to the protocol is because there are various other documents like the protocol the model the MIB and etc, so it is a package. So the right idea was to put it into the applicability statement that holds the other documents together. There is further work necessary on the section. The section currently includes: a NE as atomic element, a NE as being composed of managed elements, the ForCES MIB, the CEM and the FEM even though they are out of the scope of the ForCES working group. Avri also raised the question of CE to CE coordination since this is nowhere addressed. We only say there ought to be coordination in the presence of multiple CEs but nowhere how. It is unclear if we should include something on this topic. A: Hormuzd: the applicability statement says it is out of scope. R: Avri: yes, it is out of scope but we also say that if there are more then one, coordination is needed. A: chair: it is out of scope since there are so many ways how you can do it. In the beginning we had a lengthy discussion whether it should be out of scope or not. A: Avri: may be this is the write answer, to say explicitly because there are so many ways of doing it, it is out of scope. We should raise the attention to it without specifying how to do it. R: Hormuzd: this is a good idea to add it to the applicability statement. Other open issues in the draft is the manageability section that Avri presented. Q: who?: if we do not include CE to CE communication will we not have interoperability problems in the future? A: Avri: since it is out of scope the answer is no. If you do it then the equipment is from one vendor who knows what he is doing. It would need a charter rewrite to include it. This can always be added in the future if we think it is necessary. Are there other things we should add to the applicability statement? Alex wants to see more text on CE to CE reliability. A: chair: reliability issues concerning the CE to CE communication are out of scope. It is hard to imagine how the different CEs work together. There are already protocols that could address the issue. As an example routing protocols could be used to synchronize the routing tables. Due to the big solution space it has been excluded from the current charter. For the moment it is better to complete the protocol and model drafts and get some working experience. We can always come back if we see that we need to address the CE to CE communication including its reliability. Q: who?: on FE to FE communication A: Joel: there is for example the discovery draft. There are also information in the LFBs like the next hope information. But we only address FE to FE communication through IP and no other encapsulation. It would be interesting to look at this but it would open yet another can of worms. Let us first get ForCES done within the current scope. We still have a whole set of things that need to be done like the library draft first. Hormuzd asks for feedback on the draft as the intention is to forward the document soon to WG last call. But at highest priority are the protocol and the model draft. --------------------------------------------------- TCP/IP based TML for ForCES Update by Hormuzd Hormuzd first presents the areas that were updated. The data channel protocol is no longer TCP. The decision was made after some discussions at the last IETF. DCCP will be used as data channel with a default CCID 2 which is similar as TCP CC. At the last IETF rough consensus on this was reached. In addition the necessary IANA requirements have been added. The TML Service Interface section has been moved to the Appendix. But the question is still whether this should be eliminated given there is a separate draft on this. So we would have a synchronization problem but this particular document is not even a WG document and it has not been updated for quite some time. But as the TCP/IP TML document is close to last call this is kind of a problem. So an alternative could be to keep the TML service interface usage model maintained as a section in the draft. Q: Hormuzd: So what does the WG think should we leave it in the document or completely remove it? R: chair: This depends on the plan for the other draft. R: Hormuzd: it is not clear to me right now, it is not even a WG document. R: Joel: the text needs to be published somewhere maybe in another draft. It should not hold back the protocol draft. Then in this draft should be put text that shows how this specific instantiation use the service primitives defined in this other draft. R: Hormuzd: this is actually what has been done in the current version. In the Appendix it is shown how we would use that service interface. The only issues are on synchronizations now. This is one of the open issues we have. The other thing we have done is we added IPSec usage model for TML security which can be used to secure both control and data channel. We also limited the TLS usage model to the control channel since it is limited to TCP. In addition, we added a no security mode for a single box or for another secured environment. Under High Availability we have put a TBD which addressees the liveliness of the data channel options. We have several options for this. The PL heartbeat can be carried on both the control and the data channel but this requires some sort of multicast and collection at the end. As alternative we can use TML generated heartbeats for the data channel but this will re-introduce TML messaging which we have tried to avoid. Or we could not support data channel liveliness at all. Q: Hormuzd: are there any recommendations? R: Joel: I think there is a way out of it. I believe DCCP had some validation going on at the moment you send some data. So you are not getting in the situation where you lost the TCP connection. If the PL heartbeats just go over the TCP control connection then we know whether we loose communication or not. And when we have to send date we know when the connections go down. So either DCCP tells us for data or the heartbeats for control over TCP. It might introduce some delay but this should be enough for our space. So we do not need to multicast or use extras messaging. R: Hormuzd: that is good feed back. Current open issues are the high availability (for data channel liveliness) which should now be solvable with the comments from Joel. So text will be added to reflect that. On the removal of the TML service interface we probably leave it in the appendix for the first last call if there is no strong opposition against this. Another question that was around is on a manageability section. Q: Hormuzd: do we need one for this draft Avri? If so what should go in? A: I think so but I am not sure what should go in there since I am not very familiar with the draft. But I look at it and make some recommendations. I tend to believe all drafts need one similar to the fact that all drafts need to have a security section. R: Joel: As a comment I have a problem putting a manageability section into the model draft. But for this draft what would be possible is to have something like what are the ports or what is the status of the TML connections are things that could go in. R: Avri: we could put something in the applicability statement that says what is expected from the manageability sections in the ForCES drafts. Finaly a summary is given and Hormuzd repeats the intention to go for last call soon with the draft. The chair agreed that the draft is getting ready for LC as soon as the open issues / TBS are closed. The chair also asked the WG to emphasize its engagement again on the model draft as it is a central document for the ForCES WG. Without it we cannot really make progress. ---------------------------------------------------