Re: Meeting Report of IDPR-WG

Scott_Brim@cornell.edu Sat, 12 December 1992 00:59 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13389; 11 Dec 92 19:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13385; 11 Dec 92 19:59 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa00899; 11 Dec 92 20:01 EST
Received: by PIZZA.BBN.COM id aa01570; 11 Dec 92 20:00 EST
Received: from pizza by PIZZA.BBN.COM id aa01382; 11 Dec 92 19:30 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa01376; 11 Dec 92 19:28 EST
Received: from MITCHELL.CIT.CORNELL.EDU by BBN.COM id aa29811; 11 Dec 92 19:29 EST
Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB19465; Fri, 11 Dec 92 19:28:53 EST
Message-Id: <9212120028.AB19465@mitchell.cit.cornell.edu>
Date: Fri, 11 Dec 1992 19:27:22 -0500
To: Martha Steenstrup <msteenst@bbn.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Scott_Brim@cornell.edu
X-Orig-Sender: swb@132.236.200.25
Subject: Re: Meeting Report of IDPR-WG
Cc: idpr-wg@bbn.com

Martha, some comments on IDPR multicast.  I suspect you have thought of all
this already.

At 16:17 11/24/92 -0500, Martha Steenstrup wrote:
   >- Intra-domain multicast, when available, will be used in conjunction
   >  with IDPR multicast.

I believe you have the same problem with intra-domain multicast that you
have with intra-domain unicast -- that unless a domain's internal routers
understand (and are capable of understanding) the inter-domain routing,
then they cannot satisfy the requirements of inter-domain routing.  This is
what led to encapsulation of IDPR packets to get them across domains, as I
recall.  

In the multicast case, a domain either has to learn how a particular source
is reaching it or it has to make a wild guess.  If a domain's routers make
the wrong guess then the multicast packets might not be delivered correctly
(if at all).  Not only might they not be delivered to (all) group
participants inside the domain, they won't necessarily be delivered to
other domains correctly either.

Suppose we try to inject knowledge into the domain.  The minimum we need to
tell the internal routers is which PG a particular source/group is supposed
to arrive on (I'm assuming the inter-domain tree setup informs a domain's
PGs which one will be the entry point for a source/group's packets).  I
don't know how you would do this.

If we do not inject knowledge of inter-domain routing into the domain, then
the domain's routers will have to assume, say, Reverse Path Forwarding in
the outer world (in theory this is what MOSPF does).  In that case
multicast packets must *appear* to arrive at the PG which would be correct
if RPF *was* in force outside.  This is most easily done by encapsulating
and sending the packets from the entry PG to the "correct" PG, which can
inject it into the domain.  (This idea was originally from John Moy.)

For packets which are going to transit the domain, you might as well
encapsulate (a copy of) them to send to the far PG.

I don't know the status of aggregation/abstraction in IDPR, but this will
have a serious effect on multicast routing, especially if a particular
multicast source hears about different levels of aggregate via different
paths.  

Clearly you need teardown messages to be sent in both directions if a link
between domains which is part of a multicast tree is lost.

                                                        Thanks ... Scott