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
- Meeting Report of IDPR-WG Martha Steenstrup
- Meeting Report of IDPR-WG Martha Steenstrup
- Meeting Report of IDPR-WG Martha Steenstrup
- Meeting Report of IDPR-WG Robert Woody Woodburn
- Re: Meeting Report of IDPR-WG Scott_Brim
- Re: Meeting Report of IDPR-WG Scott_Brim