Minutes ForCES WG, IETF68, Prague, Czeck Republic ================================================= Attendees 28, (Bill and Ross included) Agenda: Tuesday, March 20, 2007, 15:20-17:20 ==================================== CHAIRS: David Putzolu Patrick Droz ADs: Ross Callon Bill Fenner AGENDA: 10 min - WG status & Agenda Bash - chairs 15 min - ForCES Protocol Specification Jamal Hadi Salim draft-ietf-forces-protocol-09.txt 15 min - ForCES MIB Robert Haas draft-ietf-forces-mib-05 5 min - ForCES TML Service Primitives Weiming Wang draft-ietf-forces-tmlsp-01.txt 5 min - ForCES Protocol TML over IP networks Weiming Wang draft-wang-forces-imtml-02.txt 5 min - A LFB Library for ForCES Weiming Wang draft-dong-forces-lfblib-00.txt (to be submitted) Minutes: WG Status by the chairs: Chair is asking for volunteers to take minutes as usual nobody was to be found. Therefore, the chair recorded the meeting in order to produce some reasonable minutes. The first item on the agenda is an update on the protocol draft. Meanwhile an external review took place by Alia Atlas. She raised 61 issues in the draft. Jamal invested a significant amount of time to address all the issues. At the moment we are waiting for feedback from Alia. The next presentation will be on the MIB. After the last IETF there was MIB doctor review by John Flick. All the issues have been addressed. Robert will present a short update of the changes. Afterward Weiming will present two drafts on TML, one on TML service primitives and one on TML over IP networks. During the status update no other issues were raised and the group moved on to the presentations. -------------------------------------------------- ForCES Protocol Draft by Jamal Hadi Salim: Alia did a review for the IESG about 2 months ago. She did an excellent job and she went into a high level of details. She raised 61 issues. The readability was the main issue. There were also things talked about before being defined. She also found some bugs e.g. that the main TLV was not really a TLV. Also the many dependencies on the model draft left the reader confused. Many of the things were defined by the model draft and it was assumed that the model draft is known by the reader. Jamal hopes that Alia will also go to review the model draft. Due to having many different editors the writing style was not consistent. Also the 2PC mechanism was not well defined. Meanwhile all 61 issues have been addressed and a response has been sent to Alia. Unfortunately Alia was not present at the meeting. A lot of text has been moved around not necessarily new text. Also a lot of clarifications have been added. This improved the readability significantly. The bugs she found were fixed. Many more references to the model draft have been added. Due to the comments from Alia actually we had 115 issues to address. All these issues are now closed on the tracker and the new version 9 draft is out. Please read the draft again and comment on it. Please use the tools web site where you can find a tool that produces a diff between 2 drafts. Certain things have been removed especially in the FE protocol object and the HA section. The dependency on the model draft is very important. The model draft is currently the bottleneck. We must complete the model draft first before shooting for an RFC on the protocol. Jamal offered help to speed things up. Joel is going to hand over certain things to Jamal. Joel himself will also contribute. One of the bigger issues is the confusion about XML attributes and XML elements. As soon as the issues of Alia are resolved Jamal will start writing an implementation report. Ross would like to have an implementation report according to the new draft that obsoletes RFC464. As the ForCES protocol is fairly complex such a document would be very helpful. Jamal would like that people who have an implementation contact him. In that way we can make one draft that includes all implementations. Ross also asks for some sort of interoperations as it is quite likely that somebody only implements the FE side whereas somebody else implements the CE side. In the implementation around Jamal two different teams implemented the FE and CE part. Ross is the opinion that it is a grey area whether different FE and CE implementations need to interoperate with each other. But some sort of interoperation would be helpful. It is basically up to the ADs to decide how much interoperation needs to be there. Also Ross raised a couple of things in an e-Mail but he needs to go over it nearly soon to decide whether all issues have been addressed. Weiming is the opinion that usualy both sides (FE and CE) come from the same group and therefore interoperability is not so important. Ross is still asking for some interoperability. Jamal and Weiming will look at the issue and see if some interoperability test would be possible. First the scope of such an interop needs to be defined. Ross wants to know whether the model will be an informational draft or not. It is clear that due to the dependencies on the protocol it also needs to be proposed standard. Somebody in the audience also believes that FE und CE side may come from different groups / companies. Therefore interoperability is important. Presentation continues. Jamal raises the question whether the EMPTY_BIT flag could be removed. The initial intention of that flag was to allow FE to select table indices on a row creation. But his current thinking is that the CE knows everything on the state of the FE. The Chair asks if somebody objects to removing it. No objections. The chair then suggests removing it. ---------------------------------------------------- ForCES MIB draft by Robert Haas: This is the 5th update of the MIB draft. It has gone through MIB doctor review. John Flick has done the review and he was present in the room. There were various modifications necessary. In the Appendix of the draft there is a list with all the changes so that you don?t need to re-read the whole document again. Two new optional notifications have been added that contain statistics information. They are used when associations go up and down. It is not allowed to define a mandatory notification that would include optional objects. A mandatory notification must contain only mandatory objects. The workaround for this problem was to define 2 new optional notifications that would include these optional objects. This is reflected in the conformance statement that can be read at the end of the MIB. The other issue was that somebody on the mailing list asked for throttling down the notifications when the CE is under DOS attack. Robert?s opinion so far is that an association must be accepted before a notification can be sent and if the CE is under DOS attack it will itself throttle down the associations it can accept hence there will be only an acceptable number of notifications coming out for those associations that the CE decided to accept. So the conclusion is we don?t need to throttle the MIB notifications because we expect that the CE always can throttle the acceptance of new associations. Robert concludes the presentation with a summary slide of the MIB layout. It is a compact MIB as we only put things that we really need. The draft is now in very good shape. There were no additional questions from the floor. ---------------------------------------------------- ForCES TML Service Primitive by Weiming Wang: Weiming starts with the progress since the last meeting. There is now a new version 01 out. The content had been introduced in the IETF67. The key changes are: first removed all the XML descriptions for the TML, now a more general description is used; second rewrote most of the TML events part, this was the biggest change; and third, he modified the SP format and the parameters from an API to a semantic description. This was based on discussions that took place. There are some smaller issues that need to be solved. At the moment the sentence ?It is feasible that the implementers of TML and PL may be from different organizations? is still kept in the document. It is not yet decided if the sentence should be kept or not. Also the following sentence: ? ? one PL portable to various TMLs actually means the PL must provide various interface drivers for different TMLs, while keeping the PL kernel the same?? is still in because the related sentence ??PL portable to various TMLs? is still kept in the protocol document. This must still be resolved. Another discussion is about TML events. The question is how TML event should be notified to PL? If we should specify a specific way or should we just specify the requirements. But this issue has been resolved. The decision is the document should not specify how, and it should depend upon implementations. Definitions in the document should also not limit various implementations. The second issue on TML event is what kind of TML event are needed. We have agreed on TML error event, but more discussion is needed for events like TML congestion alert, TML message arrive event, and other events. Another discussion is on what TML status or attributes in FE should be accessed by CE PL. We have almost approved TML error status. To debate are still TML congestion alert and TML type to indicate what kind of TML is being used. Also part of the discussion is how will the TML status or TML attributes in the FE be accessed by CE PL then. It could be represented as status or attributes of FEPO LFB. Or it could be represented as status or attributes of FEO LFB. A third alternative is to have a specific TML LFB. This issue has not been solved yet and needs further discussions. Q Robert: this is an issue that was already discussed. If an attribute about the congestion state of the TML is stored in FEO or FEPO. When the CE then wants to access it the link between the CE and FE might already be congested. So the additional traffic would congest even more. Maybe this is just specific for the congestion event. Did we come to a resolution on this? A Weiming: yes we had some arguments about this. In my opinion this kind of notification should be a kind of an alert. It should be possible that the CE knows before that the TML is congested. Such mechanisms have already been used in many systems. It is also not so much data that needs to be exchanged there. I do not think it adds to congestion. We should solve this issue as soon as possible. Q chair: Are you still in discussion on these issues? A Weiming: yes Weiming ends his presentation by asking for feedback and discussions on the open issues. He also would like to hear about implementations. Comment chair: we should avoid of adding things into new drafts that require again changes to the model and protocol draft. We had all agreed that both drafts are already rather complicated specs and adding even more does not make much sense. ---------------------------------------------------- ForCES Protocol TML over IP network by Weiming Wang: This is an individual draft which addresses ForCES over IP networks. This is the third version of the draft. The key arguments for the draft are: - A TML that adopts the most general transport protocols: TCP and UDP. - TML that can provide true multicast transportation. - TML that does not have to take TML level messaging. TCP is used for PL control messages, which require strict reliability in the form of unicast and multiple unicast for PL multicast. UDP is used for PL redirect messages, unicast and multicast, and PL heartbeats in form of unicast and multicast. The multicast used is exactly the IP multicast, rather than multiple unicast connections. Why should we use UDP for this TML? It offers the generic feature for raw data transmission and minimizes its side effects on other protocols shipped over it. It does not have the burden of flow control. It is also very efficient for multicast which is needed for redirect messages multicast. It can be used for multicast for CE->FE redirected data will be a very common case for use, e.g. for routing protocol messages or for multicast protocol messages. It also efficiently meets the requirements for heartbeat broadcast in case a very large number of FEs are connected to the CE. It is well-known and widely deployed which is an important point which may affect the deployment of ForCES greatly. The key arguments against this draft are the UDP does not have congestion control and protection against DoS attacks for a ForCES TML usage. That also raises the discussions on whether TCP+UDP are ok enough or not as a ForCES TML. The authors are currently looking at means to provide such protection. Maybe whatever TML we are using we my face DoS attack problems. Weiming shows an example where a UDP stream blocks any ForCES TML. In the example the FE and CE are interconnected over a multi-hop network. Comment chair: according to the ForCES charter we had the close proximity principle. It was not the intention to run ForCES over multiple hops. A Weiming: but it is possible. A chair: yes you can do this but it is not in the scope of the ForCES WG. The most important thing is that there are more applications running on these connections that the CE and FE are using. If other applications are sharing these connections you have congestion problems. And these problems are not solved by any protocol. That is why we can not have an absolute solution for congestion control in the Internet. Especially for DoS problems we need to have more general considerations. Whereas, on the other hand, experiences from traditional routers have shown that we may have to more rely on the whole NE resources, like the forwarding plane elements, the control plane policies, etc, rather than just on the TML layer transport resource for congestion and DoS attack avoidance inside a NE. Things like rate limit, packet recognizing and filtering, etc. Comment Jamal: I see you are hand waving around CC but TCP would back off. I understand there are all sorts of methods to address it. Implementations start to get problems under congestion. Jamal himself had a draft some time back on TCP/UDP. A Weiming: how about DCCP A Jamal: but I am not so sure if DCCP is the right thing. If you want to use methods to cope CC and DoS you need to specify this to much higher details in your draft. A Weiming: I don?t think we need to specify the schemas in the draft. But we have some schemas. Comment chair: before we were talking about interoperability. If the stuff in not specified that somebody else can implement the exact behavior we will never get any interoperability. Either specify the things in details or leave it away. Comment Jamal: if you specify it in more details I would be happy but I rather see just TCP or SCTP. Weiming continues with a summery of why he thinks that the TCP+UDP TML is an efficient, feasible, and cost-effective TML for ForCES. And ForCES does need such a TML. There are TCP+UDP TML implementations out there. In the end Weiming asks to make this document a WG document as soon as possible. Q Robert: why not using these rate limiting factors as a TML specific LFB. A Weiming: I have this but I object to this very much. Comment chair: whether to make this a WG document or not we have to bring it to the list. Jamal what are you using as TML. A Jamal: It is TCP but I agree with Weiming that TCP may not be the best protocol. But DCCP implementations are too unstable for a production environment. But I may put out a draft on SCTP which can offer what TCP and UDP can do. Discussion on whether we should have one or more TML. And in case of multiple one which one would be mandatory. The presented draft could be an optional TML rather then the mandatory and default TML. Comment chair: the mandatory and default TML should probably be a rather simple one in order to guarantee interoperability. With the current state of this draft interoperability is probably not possible. Whether to make this document a WG document we can bring to the list and at the same time we can also poll the list what people think as a mandatory TML. ---------------------------------------------------- A LFB Library for ForCES by Weiming Wang: This is a new draft that will be submitted after the meeting. But it is a continuation of work that was presented more than a year ago. The draft proposes a LFB Library for ForCES. We defined 22 LFBs by use of XML schema proposed in FE Model which is compliant with ForCES FE model specifications. It contains attributes, capabilities, events, etc. We also defined relative frame types, data types, and metadata types used in proposed LFBs. Weiming shows the document that was posted to the list a day before the meeting. Comment chari: Probably nobody in the room has read the document as it was only posted yesterday. Weiming shows some of the LFBs in the library. Some of the attributes are still under construction. The authors would like to get feedback on their draft. Comment Jamal: we have implemented these LFBs. So when you go back to the IPv4 LPM LFB. In our implementation it looks different. I assume there will be many collisions. The naming is also different. We mainly stuck to the SNMP MIB naming. The comment by Jamal triggered quite some discussion and Weiming agreed to discuss it off-line with Jamal. ---------------------------------------------------- Chair asks for additional issues: Avri gives an update on the applicability statement. She apologies that the draft had expired back in January. It is actually stated that we put together all the document like protocol and model and then decide on a default TML. But there will be a new version within the next month or so. At the point in time we have a decision on the default TML we will put it in there. It will eventually become an informational draft. Comment chair: the WG had common consensus to have an applicability statement and therefore I am glad that there will be a new version. The chair askes for other open issues but there were non raised and the meeting closed.