NHRP & Re: Walter Milliken ATM Multicast service drafts

Andrew Smith <asmith@baynetworks.com> Mon, 17 July 1995 22:35 UTC

Message-Id: <9507172212.AA16943@milliways-le0>
Date: Mon, 17 Jul 95 15:12:35 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
To: bryang@eng.adaptec.com
Subject: NHRP & Re: Walter Milliken ATM Multicast service drafts
Cc: ip-atm@matmos.hpl.hp.com, rolc@nexen.com
Precedence: bulk

> Date: Mon, 17 Jul 95 10:30:33 PDT
> From: bryang@eng.adaptec.com (Bryan Gleeson)
> To: milliken@bbn.com
> Subject: Re: Walter Milliken ATM Multicast service drafts
> Cc: ip-atm@matmos.hpl.hp.com

Bryan,

> Walter,
> 
> 	Is there an assumption in the int-serv IPMC draft that all
> hosts are NHRP capable ? I was wondering if there was a need for
> an extra category of host to distinguish between NHRP-capable
> and NHRP-incapable hosts. If a multicast router is going to
> do short-cut routing and forward the RSVP Resv messages 
> off-subnet it needs to know that a host which receives such
> a short-cut Resv can ARP for off-subnet addresses. How does
> the multicast router know this ?

I think Yakov has identified some very ugly problems if you 
start forwarding your "signaling" messages (e.g. NHRP or RSVP)
by the shortcut path. I think it is probably safer to assume
that the paths used for these signaling messages pass through
all nodes which need to know about them in order to avoid ugliness.

Besides, who wants to shortcut Best Effort paths anyway? ;^)

> Bryan

Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************

NHRP & Re: Walter Milliken ATM Multicast service … Andrew Smith