回复:ForCES meeting minutes (draft)

Hi,



******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or em
ail immediately and delete it!
 ****************************************************************************************

----- 原邮件 -----
发件人: Robert Haas <[email protected]>
日期: 星期四, 十一月 9日, 2006 上午0:56
主题: ForCES meeting minutes (draft)

> All,
> Please find below the meeting minutes for yesterday meeting in San 
> Diego.Let me know if you have comments/questions.
> Regards,
> -Robert
> 
> 
> Meeting Minutes:
> 
> 1) WG status & Agenda Bash, Robert Haas
> slides: http://www3.ietf.org/proceedings/06nov/slides/forces-0.ppt
> 
> - Protocol and MIB drafts under AD review. Ross Callon to complete
> reviews by year end. Avri to incorporate changes.
> - Model draft will have another LC once changes are incorporated.
> - TCP-based TML ready for LC.
> - TML Service Primitives draft ready LC once changes are incorporated.
> 
> 
> 2) A Framework Adapting Traditional Router to ForCES-based 
> Architecture.Huaiyuan, Ma (Michael)
> http://www.ietf.org/internet-drafts/draft-ma-forces-proxy-
> framework-00.txt
> slides: http://www3.ietf.org/proceedings/06nov/slides/forces-2.ppt
> 
> The draft addresses two main issues to allow the evolution from
> traditional routers towards ForCES-compatible routers:
> a) Ensuring interoperability between FEs with different forwarding
> models by introducing an FE Adapter. Comment from Joel: the fact that
> different forwarding models are used by the FEs is irrelevant: it 
> is the
> Fi interface that is out of scope of the standardization effort 
> and for
> which an FE Adapter could be needed. This would allows FEs from
> different vendors to interoperate by interpreting the metadata 
> that is
> passed along with the packet.
> b) Control of legacy FEs that do not support ForCES by using an FE
> Proxy. Comment from Joel: The FE Proxy is not distinguishable from 
> an FE
> from the ForCES-protocol perspective.
> Comment by Robert: the draft shows how FE Proxies can be used in a
> traditional router to make it ForCES compatible, while remaining
> transparent to the ForCES protocol. Moreover, as the Fi interface 
> is not
>  subject to standardization, the FE Adapter is out of the scope 
> of the
> standardization.

Anyway, we have to solve this problem sooner or later, without defining this meta-data properly,
FEs from different vendors cannot interoperate directly, only FEs from the same vendors can work together.
 
Now I recognized that many people including Joel, Robert and Avri etc identified this question already, 
Hopfully we can start working on this question soon.





> 
> 
> 3) ForCES Model, Joel Halpern
> http://www.ietf.org/internet-drafts/draft-ietf-forces-model-07.txt
> (no slides available)
> Credits also to Ellen for editing. The last call uncovered
> inconsistencies in the terminology: clash between XML attributes 
> and LFB
> attributes, clash between XML elements and LFB elements (encompasses
> capabilities, capacities, attributes). More comments are welcome.
> 
> 
> 4) TML Service Primitives (Weiming Wang) presented by Robert Haas.
> http://www.ietf.org/internet-drafts/draft-ietf-forces-tcptml-04.txt
> slides: http://www3.ietf.org/proceedings/06nov/slides/forces-1.ppt
> 
> Discussion of the open issues:
> a) TML errors and congestion alerts, and possibly stats.
> Comment by Joel: Should first determine if such information should be
> reflected in an LFB or if it is only useful locally (between the 
> TML and
> PL). For instance, taking the example of congestion notification, this
> can be done as follows:
> - the TML locally notifies the PL about congestion it observes on the
> communication channel, and that's all, or:
> - in addition, the TML changes an attribute in an LFB that in turn
> generates a ForCES event notification from FE to CE. But is it 
> wise to
> generate more traffic when congestion has been detected ? The TML 
> shouldpreferably deal with congestion itself directly.
> Comment by Robert: Authors of the draft should examine each of these
> information and determine if they are of local interest (hence no need
> to be reflected in an LFB) or have FE-CE interest (hence update 
> the LFBs).


I agree with Joel strongly. because it is kind of self-contradiction stuff. When this congestion happens,
there is no way to send this kind of message from the congested FE to CE, that is, this kind of notification
cannot be delivered to the CE until the congestion disappers, so trying to make this kind of notification work 
in this way does not make any sense.




> b) Statement from protocol draft that "PL must be portable across 
> TMLs".Comment by Joel: this statement is a mistake. This comes 
> from a
> confusion between definition vs implementation. Standardization of
> TML-to-PL-interface is out of scope. Avri seconds Joel's comment.

I agree with that, our definition should be very general.



> 
> 
> 
> -- 
> Dr. Robert R. Haas
> IBM Zurich Research Laboratory
> S?umerstrasse 4
> CH-8803 Rüschlikon/Switzerland
> phone +41-44-724-8698  fax +41-44-724-8578  
> http://www.zurich.ibm.com/~rha