Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/idmr/idmr-minutes-96dec.txt

Text File | 1997-01-30 | 15KB | 258 lines

Editor's note:  These minutes have not been edited.


IDMR met in two sessions at the San Jose IETF; December 11 and 12.
These minutes were compiled by Tony Ballardie and Bill Fenner.

First session: Wednesday, December 11.

Ahmed Helmy presented the PIM Deployment Guidelines.  It's not clear
whether this document belongs in IDMR or in MBONED, but it was
presented at IDMR.  There are three requirements in the PIM Deployment
Guidelines:  Contiguity (all routers in a domain must be running the
same version of PIM-SM), Convexity (shortest paths between any two
hosts in the domain must stay within the domain) and Administrative
Scope Boundaries must coincide with the borders of the domain.  When
incrementally deploying PIM-SM, entire LANs must be converted at a time
(no multi-protocol LANs allowed), and convexity must be retained
(meaning that multiple LANs may have to be converted at a time).  The
recommended setting for the switch to a shortest path tree is when the
register rate (for RP's) or data rate (for DR's) exceeds 8kbps for 5
seconds.  A suggestion was made to have routers warn if a non-convex
domain is detected, but it's not clear that such a thing can be
detected.

The group then received implementation status from several
implementors.

Rusty Eddy from USC/ISI talked about his PIM-SM implementation in gated
3.6-alpha2.  His implementation is progressing well, but does not yet
implement the whole PIM-SM spec.  He talked about the requirement for
UNIX kernel modifications to decapsulate PIM Register packets, and
Steve Deering raised a concern about putting protocol-specific
modifications into the UNIX kernel.  It was clear that a general
mechanism for specifying encapsulation and decapsulation is the only
way around putting protocol-specific mechanisms into the kernel, since
each protocol has its own encapsulation mechanism.

Liming Wei from Cisco talked about Cisco's PIM-SMv2 implementation, and
how it interoperates with their PIM-SMv1 implementation which is
already widely deployed.  Cisco wants to require as little as possible
to allow incremental deployment.  To this end, they are releasing new
versions of their PIM-SMv1 implementation called "PIM-SMv1+" which have
mechanisms that make them very similar to PIM-SMv2, and their PIM-SMv2
implementation will be able to handle both PIM-SMv1 and PIM-SMv2 RP's
and DR's.

Ahmed Helmy from USC/ISI gave pointers to his PIM-SMv2 implementation:
http://catarina.usc.edu/ahelmy/pimsm-implem/ , or simply
http://catarina.usc.edu/pim/ .  Ahmed's implementation runs over IRIX
6.2 or SunOS 4.1.3, and implements almost all of the PIM-SMv2 spec.

Michael Speer from Sun has ported Ahmed's implementation to Solaris
2.5.1, and is investigating both QoS routing and IPv6 in conjunction.


Deborah Estrin from USC/ISI then talked briefly about the PIM
Inter-Domain RP architecture.  The goals are to support inter-domain
PIM without any changes to intra-domain PIM, to keep a hierarchy of RP
information so that DR's don't need details about far-away domains, and
to maintain a single RP per tree to avoid multiple level overlap
problems.

David Thaler then gave a status on MIBs.  The IGMP MIB has been updated
to include variables to support IGMpv2.  The IP Multicast MIB has two
new variables: administrative boundaries (moved from the DVMRP MIB),
and packets forwarded per (S,G) per interface.  The latter variable is
optional as it requires much more state but can provide extremely
useful information.  The DVMRP MIB had its administrative boundaries
section moved to the IP Multicast MIB, and had minor changes made to
bring it into line with the DVMRPv3 specification.  The PIM MIB had the
PIM-SMv1 objects deprecated and PIM-SMv2 objects added.  The goal is to
resubmit the Internet Drafts with changes, and then issue Working Group
last call for all the documents.  The documents are expected to go to
the same status as the protocols they represent, e.g. all but IGMP will
go for Experimental, and the IGMP MIB will go for Proposed Standard.

David Thaler then talked about interoperability.  The goal is to move
from an O(N-squared) problem to an O(N) problem by defining a set of
interoperability specifications that each protocol can speak with each
other.  There are several organizational possibilities, including a
tree topology of domains with a single root or "backbone", a level 2
routing protocol and using encapsulation to transit across domains, and
"coherent" routing tables with full routing in certain areas and
subsets of full routing in areas that are not fully connected.  One
major problem is that unless a protocol provides group membership
information across a domain (e.g. using Domain Wide Reports, or
Regional Membership Reports as in MOSPF), packets must be broadcast and
pruned between domains; thus, David suggested adding Domain Wide
Reports to all protocols.  Another problem is that MOSPF does not have
source-specific prunes, just group prunes, so if an MOSPF domain is
used as transit all traffic must flow across it in order to receive
internal sources as well.  David's interoperability architecture has
the different protocols communicating inside a router, as opposed to on
a wire, and defines several messages for the protocols to communicate
with each other.  The architecture includes several different possible
implementation mechanisms, including monolithic design and
inter-process communication.

Bill Fenner then talked about IGMPv2.  The IGMPv2 specification has
been submitted to the IESG for Proposed Standard.  One question was
received, about group membership timers and the other querier present
timer; if the querier fails, as the spec is written, routers can lose
membership information for a few seconds, which can affect routing.
However, when a router fails, routing is expected to be affected
anyway, so this is not an undue extra burden.

Bill Fenner continued to talk about multicast traceroute and
experiences and problems with trying to get a wider implementation
base.  Problems experienced include that when routing protocols other
than DVMRP or MOSPF are in use, routers do not necessarily know which
router is the proper last hop for a given source,group,destination;
this is one of the requirements for mtrace.  CBT does not keep
source-specific state, just tree state, so there is no way to forward a
traceroute request towards a source.  And PIM-SM has two potential
trees, so which one should be traced?  This last problem is solved by
specifying that a traceroute request with a group included means to
either trace the existing state or towards the RP if there is no state,
and a request with the group field set to 0 means to trace the
source-specific tree, no matter what state might be set up.  There are
two potential solutions to the first problem, neither of which is all
that desirable.  All of the potential last-hop routers could reply, but
this is not useful since there is no way to tell from the responses
which of the potential paths would be the correct one.  Therefore one
could start diagnosing problems along the incorrect path.  The other
solution is to make the forwarders make the decision on who should be
the forwarder.  The problem with using existing protocol mechanisms for
this is that you might end up changing the state that you're trying to
debug.  To avoid that, it's possible to invent a new protocol mechanism
(e.g. a "Diagnostic Assert"), but that has the disadvantage of
requiring protocol changes.

Bill also talked about new forwarding codes that have been added or are
being considered for addition to the spec.  These include
clarifications of existing codes, and new codes based upon experience
gained from using multicast traceroute.  He also asked for help
determining if there is a way to distinguish certain states in PIM and
if there is a need for more forwarding codes to indicate these states.


Second session: Thursday, December 12.

Tony Ballardie began by explaining the reason for temporarily
withdrawing CBT's call to go Experimental; during the last call 2 sets
of comments were received, one to the IDMR mailing list, pointing out
relatively minor inconsistencies/ambiguities/flaws in the spec, which
were all subsequently fixed. The other set of comments were sent to
Tony privately, pointing out some concerns in the spec with respect to
looping. As it was then, CBT allowed loops to form in the distribution
tree, but subsequently detected them and explicitly tore them down.
Clay Shields (Univ. Santa Cruz) authored the private message and
pointed out that it may not be possible in all circumstances to detect
loops. He has completed a Masters thesis on the topic of potential loop
scenarios in CBT, and suggestions (with formal proofs) for eliminating
loops altogether, i.e. ensuring they do not form in the distribution
tree in the first place, irrespective of whether loops are present in
underlying unicast routing. Clay presented his work later in the
session.

Next, Tony presented the new LAN specific mechanisms recently
introduced to the CBT protocol. These include a new, more robust DR
election mechanism which overcomes the need to have all LAN CBT
routers' unicast routing tables aligned. The DR election mechanism is
now achieved by a simple CBT HELLO protocol.

On broadcast links CBT join-requests are now multicast to the
all-cbt-routers multicast address, TTL 1. [As yet there is no
officially assigned all-cbt-routers multicast address, but Tony will
pursue this]. A join that is multicast to the all-cbt-routers group may
only be forwarded by the LAN's designated router (DR).  It in turn
*may* find it has to send it back across the same link it arrived on
according to its unicast tables; the DR is the only LAN router
permitted to *unicast* a join across a broadcast link.

The CBT quit-request has been replaced by a CBT quit-notice, which is
no longer acknowledged. On broadcast links, a quit-notice is multicast
to the all-cbt-routers group, and processed by all cbt routers on the
link; if the arrival link is an active child interface, the DR sets a
CBT forwarding cache deletion timer, during which time if a
join-request arrives for the quit group, the deletion timer is
canceled. Any such join must be acknowledged in the usual way.
Join-requests sent in response to a multicast quit-notice are sent
after the expiry of a random response interval timer at the sender.
This timer is set at an interval less than the DR's cache deletion
timer. Routers discover the DR's cache deletion timer interval since it
is included in the DR's CBT HELLO messages, sent over broadcast links,
TTL 1. The purpose of the random response interval timer is to suppress
multiple joins being sent for a quit-notice.

The point was made that it should be investigated to see if the CBT and
PIM DR election mechanisms can be aligned, since their goal is the
same; to elect a single upstream LAN forwarder.

Next, Clay Shields presented the primary aspects of Ordered CBT (OCBT),
the subject of his masters thesis. These involve a logical ordering of
core routers to prevent loops forming in the shared tree, even if loops
happen to be present in underlying unicast routing.  Exactly how cores
are discovered as belonging to a particular level has yet to be
decided, though the CBT authors are investigating the HPIM approach
(with some optimizations). Whatever the outcome, the CBT authors will
not sacrifice CBT's simplicity for a core discovery solution.

Clay also demonstrated how non-member senders are treated in the CBT
case; a sender's local DR joins the distribution tree with a special
subtype of the join-request which sets up uni-directional forwarding
state between the sender and the rest of the tree.  The question was
raised as to how such state is removed when a sender stops sending.

The issue of asymmetric links arose, and it was questioned what CBT
would do in such a case.

The OCBT principles are currently being integrated into the CBT
protocol.

Radia Perlman was the next presenter. Radia had not taken a close
interest in IDMR previously, but found a cause to after attempting to
read some of the working group's latest specifications. Radia is a
strong advocate of protocol simplicity, and questioned why complex
protocols and core discovery is actually necessary, when simple core
discovery heuristics (manual placement, and advertisement via an "sd"
like protocol) may result in trees that are satisfactory enough for
most/many applications.  Many of Radia's suggestions meant that the wg
revisited many of the motivations that have been thrashed out over the
last couple of years for the current protocol designs. In revamping
many of the old questions and arguments the general consensus seemed to
be that the "old" motivation and reasoning holds, for the most part.
Whilst Radia's presentation caused quite a heated exchange, most felt
it was nevertheless a useful exercise to reflect once in a while just
to make sure we're on the right track.  We should also be constantly
aware of whether the complexity of our solutions is absolutely
necessary or desirable, when something simpler may do just as well.

The final presentation was made by Ken Carlberg (SAIC) on a new
multicast routing protocol proposal called YAM, which is in its early
stages of development. YAM can probably be best described as a variant
of CBT that takes advantage of QoS paths over the wide-area. YAM
subscribes to the intra/inter-domain concept, whereby a receiver joins
an advertised RP/Core inside a domain, then the domain border router
joins an inter-domain portion of the distribution tree, thus creating a
tree-of-trees. The inter-domain join is multicast out from the
receiver's boundary router (a join can be scoped, e.g. by limiting the
IP TTL), and presumably this join hits one or more candidate RP/Cores.
One or more of these cores may respond with a join-ack. One or more
join-acks thus are received by the originating boundary router, which
can then decide which to accept (assuming each ack corresponds to a
different QoS path).

The comment was made that an underlying "bootstrap" multicast protocol
(of type broadcast & prune) is assumed present in the wide-area to
distribute the multicast join-requests, giving rise to the infamous
"chicken in the egg" problem.

There was also a request to have QoS defined in this context, and this
appeared to be addressed satisfactorily.

In summing up, Tony Ballardie solicited vendor support for a CBT
implementation, as well as for any other contributors to the CBT
effort.