Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/idmr/idmr-minutes-97aug.txt

Text File | 1997-10-10 | 6KB | 124 lines

IDMR met during one session in Munich. There were 4 presentations
in all: GUM/MASC, Multicast BGP, IGMP Layer 2 Issues, Multicast
DHCP Address Allocation.

GUM (presented by Dave Thaler) builds a shared tree of domains,
the shared tree comprising bi-directional branches. This proposal
is dependent on the allocation of multicast address blocks/prefixes
to each domain,which is achieved via a separate protocol, the name
of which is currently MASC. Allocating address blocks to domains is
thought to improve multicast address utilization, and provide potential
to aggregate group addresses, if only small numbers of groups.
A short presentation of MASC was given (Deborah Estrin), but it is
only in the early stages of development, with several issues/mechanisms
still to be resolved.

Whilst GUM has the capability to build shortest-path (inter-domain)
branches, the motivations for doing so are different than for
PIM, the primary reason being to avoid data packet encapsulation
when data enters a domain; if the multicast IGP is based on RPF,
the inter-domain multicast paths can result in data being injected
at a point which would result in the internal RPF check failing.
Hence the need to encapsulate and deliver to the "correct RPF" BR.

It was questioned whether a domain could inject data via multiple
border routers, and have the multicast IGP ensure no duplicates
are distributed internally. The point was made that, if Multicast
BGP is assumed to operate between domains, it would provide only
one data injection point, and therefore multiple injection points
are irrelevant. It turns out that GUM does not necessarily assume
multicast BGP, and therefore either method could be adopted.

A review/update of Multicast BGP was presented by Tony Ballardie.
Multicast BGP is about establishing "come from" AS-paths for the
purpose of multicast routing, enabling ASs to specify multicast-specific
policy that can be independent of unicast policy. One of the goals
of this work is to reach consensus about what is needed in BGP
for the purpose of multicast, then pass on any proposal(s) to IDR
for eventual inclusion in BGP-4.

The presentation made clear the need to distinguish multicast
path information from unicast path information in BGP. Where
topologies and policy are congruent there should also be the
capability to advertise this congruence. This functionality
has recently been provided for within the BGP-4 multiprotocol framework
proposed by Bates et al. (draft-bates-bgp4-multiprotocol-03.txt).

One possible strategy for evolving the Mbone to support multicast
BGP was also presented, whereby tunnel (unicast) paths could be
enumerated for assisting in the multicast path decision process.
However, several wg members thought that no special case for
this should be made, and that such information should not be
propogated as part of the path information. Other virtual
networks (e.g. the 6bone) also use tunnels, but do not "expand"
them.

Shantam Biswas presented a proposal for extending to IGMP,
whereby multicast routers use a generic message which is
periodically advertised to the all-routers group address.
Such a message is potentially useful to LANs comprising
layer 2 switches, which are becoming more prominent.
Currently, layer 2 switches have to "snoop" on the control
messages of each multicast routing protocol, which are
sent to the corresponding protocol's reserved locally scoped
multicast address.

The point was made that the use of a generic IGMP message,
periodically advertised by multicast routers to the all-routers
group address would make the job of a layer 2 switch considerably
easier; switches have to forward all multicast data traffic to all
multicast routers on the LAN. It was also proposed that such a
message could contain "other useful information".

Several wg members were opposed to IGMP being used for this
purpose, and no wg members expressed their support for such
use of IGMP. However, it was acknowledged this problem exists
for switches, and it was suggested that the problem be solved
in the context of another protocol, perhaps Router Discovery.

Baiju Patel presented a multicast address allocation scheme
based on extensions to DHCP. The proposed scheme is hierarchical,
in that address blocks are allocated to domains (ASs) from the
top level servers, then a domain's AS allocates sub-blocks to
DHCP servers within the domain. It was suggested that the scheme
could be used in conjunction with MASC, presented earlier.
A protocol is required under the scheme which is responsible
for communicating the allocations between the servers at each
level. This is not defined at the current time.

Several wg group members were opposed to this scheme. The point
was made that hierarchical address allocation uses up the address
space really fast, and evidence exists to prove this.
It was also pointed out that DHCP would perhaps be better used for
multicast service discovery rather than address allocation, but
in general DHCP already seems to be too overloaded with uses.
It was also questioned as to how long DHCP will survive.

Finally, the wg was reminded that there are several IDMR documents
in their last call. The message I sent out 6th August follows:

Subject: IDMR wg Last Calls
Date: Wed, 06 Aug 1997 16:32:32 -0700
From: Tony Ballardie <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]

This is a wg last call for the following documents:

   draft-ietf-idmr-igmp-v2-06.txt (to Proposed Standard)
   draft-ietf-idmr-multicast-routmib-05.txt (to Proposed Standard)
   draft-ietf-idmr-igmp-mib-05.txt (to Proposed Standard)
   draft-ietf-idmr-pim-mib-03.txt (to Experimental)

The MIBs will be subject to review by a designated Net Mgmt Advisory
Board person before any final advancement.

Since this last call encompasses 4 separate documents, this
last call expires end of August.

Tony