Re: Agenda of next UDLR meeting

[Tim Gleeson <tgleeson@cisco.com>]

Just a few topics for possible future work, in no particular order.

Some of these are simple tweaks, others are much harder. We really need to 
reexamine the charter. 

* How do new values get assigned for "tunnel types"? Define an
  interpretation for tunnel type numbers.

* Allow several distinct (overlapping) subnets to exist on the same
  UDL. This may involve changing the HELLOs to maybe include a subnet
  mask.

* Easing some restrictions:
  - We emulate a "broadcast" network, because this is useful for most
  higher layer protocols. But many higher layer (routing) protocols
  work well over NBMA networks. Can we support NBMA style as well?
  - We provide a L2 network. One of the reasons for this is so that
  ARP will work. Can we provide protocol discrimination, so we can
  support multiple protocols more directly?

* I'm not sure we finished our discussions on having different MAC
  encoding on the UDL and in the tunnel.

* SO-feed support is compulsory. How common are SO-feeds? Can we make
  them optional, while still maintining compatibility?

* I heard some people want to use DTCP independent of
  LL-tunneling. This is a little easier now that it's in a separate
  section. But other people might want to use LL-tunneling without
  DTCP - e.g. static definition of feeds. At the moment, DTCP is
  compulsory, but the new wording we have "Initially, the list of
  active feeds is empty" can be replaced with "An initial list of
  active feeds can be set by the administrator" or something similar
  for static entries. There are security reasons for wanting to do
  this, as well. Liveness detection is still needed, but there
  are perhaps other L2/L3 ways of doing this.

About the current security... The interaction of broad/multicast, and 
potentially very large numbers of receivers makes this very hard. We 
certainly have to put up very large warning signs around this black pit, 
but in some environments, e.g. corporate (non-public) networks, and where 
LL-encryption is used on the UDL (so feed addresses are not generally 
exposed) the threat is perhaps less dire.

Tim