Draft Minutes of the UDLR WG meeting.

[Walid Dabbous <Walid.Dabbous@sophia.inria.fr>]

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
With some others.