Reported by Patrick Cipiere. UDLR WG - IETF-45 OSLO Chairs: Walid Dabbous, Yongguang Zhang Agenda Status of the Draft (Walid) 5mn Interoperability tests INRIA-WIDE (Emmanuel Duros) 20mn Presentation of BGP Direction Attributes (Dave Thaler) 15mn Discussion (All) Status of the draft IESG comments be more precise about the security considerations firewall is not an enough defined term identify the possible threats in the tunnel clarify problem description AD's comments precise implications of the MAC level (ie MPE vs Ethernet) These comments will be taken in account and a new version of the draft will be issued as soon as possible. We ask for a volonteer who has English as first language, to help in mofifying the draft. Thanks to Tim Gleeson who is volonteer. Questions: AD's raise an issue about GRE (RFC1701) which is informational. draft relies on GRE, so we have to wait for RFC1701 to become a proposed standard. How long will it take? Dave Oran and Rob Coltun answer is: should not be a long time. They just have to find the person to do the job. They will manage that very soon. Interoperability tests between Sony (WIDE) and INRIA (Emmanuel Duros) Sony people at INRIA: because of satellite coverage UDL MAC layer: MultiProtocol Encapsulation (MPE) INRIA satellite network Interoperabily tests The slides describing the interoperability tests can be found under: http://www-sop.inria.fr/rodeo/personnel/eduros/various/interoperability.ps.gz During the presentation, there was (again) a discussion about the solution based on broadcast link emulation. Harri Hakulinen says he preferes a solution which is not based on broadcast emulation at the link level. Patrick Cipiere answers that this is the goal of the draft: a solution for the UniDirectional Link Routing problem based emulation of a bidirectional broadcast link. It does not rpeclude other solutions but the Working group converged to this solution. Harri Hakulinen complains about scalibilty of the solution: if we have 10k or 1M of receivers it will not work. Yongguang Zhang replied it is the same pb on any broadcast capable links (e.g. Ethernet) and this is not specific to the LLTM mechanism Gorry Fairhurst complains about the fact that the draft mention MAC layer encapsulation in the GRE tunnel. Patrick Cipiere answers that the back channel encapsulate the same MAC layer that the one used on the UDL link. Dave Oran explains that is simple enough to handle all the scenarios. He also mentions that it is broadcast emulation therefore if we want to be coherent we must sent back through the back-channel MAC layer packets. Sending layer 3 paquets would lead to unexpected behaviour. Jun Takei says that a feed should at least understand a common MAC layer (Ethernet) on the back channel. Hitoshi Asaeda agrees. Harri Hakulinen disagrees. There is a rough consensus on using MAC layer on the back channel. The implications will be detailed in the new version of the draft. BGP direction attributes for multicast (Dave Thaler) bidirectional routes go-to routes come-from routes should a router having one go-to route and one come-from route advertize a bidirectional route. NO, because of DUP's. http://www.ietf.org/internet-drafts/draft-ietf-idmr-bgp-mcast-attr-00.txt People who participated in the discussions: Walid Dabbous Walid.Dabbous@sophia.inria.fr Yongguang Zhang ygz@hrl.com Emmanuel Duros Emmanuel.Duros@sophia.inria.fr Dave Thaler dthaler@microsoft.com Tim Gleeson tgleeson@cisco.com Dave Oran oran@cisco.com Rob Coltun rcoltun@siara.com Harri Hakulinen Harri.Hakulinen@research.nokia.com Gorry Fairhurst gorry@erg.abdn.ac.uk Patrick Cipiere Patrick.Cipiere@sophia.inria.fr Jun Takei takei@csm.jcsat.co.jp Hitoshi Asaeda asaeda@yamato.ibm.co.jp