Re: draft rolc minutes

Curtis Villamizar <curtis@ans.net> Mon, 24 July 1995 18:51 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11196; 24 Jul 95 14:51 EDT
Received: from nexen.nexen.com by IETF.CNRI.Reston.VA.US id aa11192; 24 Jul 95 14:51 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id OAA07196; Mon, 24 Jul 1995 14:31:51 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id OAA12473 for rolc-out; Mon, 24 Jul 1995 14:31:31 -0400
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id OAA12464 for <rolc@nexen.com>; Mon, 24 Jul 1995 14:31:27 -0400
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id OAA07188 for <rolc@nexen.com>; Mon, 24 Jul 1995 14:31:26 -0400
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.9) with ESMTP id OAA15810; Mon, 24 Jul 1995 14:29:23 -0400
Message-Id: <199507241829.OAA15810@brookfield.ans.net>
To: dhc2@gte.com
cc: yakov@cisco.com, rolc@nexen.com
Reply-To: curtis@ans.net
Subject: Re: draft rolc minutes
In-reply-to: Your message of "Mon, 24 Jul 1995 14:00:41 EDT." <9507241800.AA05464@minuteman.gte.com>
Date: Mon, 24 Jul 1995 14:29:22 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

In message <9507241800.AA05464@minuteman.gte.com>om>, dhc2@gte.com writes:
> <<> I agree with the idea of removing IP Encapsulation. The benefits
> <<> of removing IP encapsulation e.g., simplifying the operation,
> <<> protocol independence, better support for MPOA and providing
> <<> a better working ground for the router-router case outweight
> <<> the benefit of retaining IP encapsulation, ie Server Mode.
> <<
> <<I'd like to understand how removing IP Encapsulation provides
> <<"a better working ground for the router-router" case.
> <<
> <<Yakov.
> 
> Removing IP encapsulation virtually implies that all the routers
> in the NBMA cloud be NHRP speakers. Otherwise, the use of NHRP 
> would be limited , in that as soon as your NHRP request hits a non-NHRP
> speaker, it is dropped. Then, in a "homogeneous" NHRP environment,
> your proposals number 1 and number 2, which require that routers
> in the short cut path propagate topology changes information
> can be implemented more easily. As you pointed out, when there are
> non-NHRP speaking routers in the short-cut path, additional measures
> should be taken. I used the term "better working ground" to mean that
> fabric mode provides a more flexible environment towards the implementation
> of some of your proposals. 
> 
> Having said that, among the proposals by you and Bruce, I like the 3rd 
> one the most. Conceptually, it is simple. Also, it is more general in 
> that it will detect a loop regardless of its cause.
> 
> Derya


The problem with the router-router case is routing loops which fabric
mode addesses no better with the removal of IP encapsulation.  It does
allow the routing loops become multiprotocol.

Curtis