Re: draft rolc minutes

dhc2@gte.com Mon, 24 July 1995 17:19 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10384; 24 Jul 95 13:19 EDT
Received: from nexen.nexen.com by IETF.CNRI.Reston.VA.US id aa10380; 24 Jul 95 13:19 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 NAA04749; Mon, 24 Jul 1995 13:04:48 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id MAA09834 for rolc-out; Mon, 24 Jul 1995 12:53:01 -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 MAA09825; Mon, 24 Jul 1995 12:52:58 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: dhc2@gte.com
Received: from ns.gte.com ([132.197.8.9]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id MAA04467; Mon, 24 Jul 1995 12:52:56 -0400
Received: from minuteman.gte.com by ns.gte.com (8.6.10/8.6.10) id MAA24107; Mon, 24 Jul 1995 12:07:45 -0400
Received: by minuteman.gte.com (5.0/SMI-SVR4) id AA05395; Mon, 24 Jul 1995 12:11:37 -0400
Date: Mon, 24 Jul 1995 12:11:37 -0400
Message-Id: <9507241611.AA05395@minuteman.gte.com>
To: rolc@nexen.com
Cc: malis@nexen.com
Subject: Re: draft rolc minutes
Content-Length: 2894
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/

Andy wrote:

>>Removing IP Encapsulation and Server Mode
>>
>>During open discussion, Rob Coltun requested that the WG simplify NHRP,
>>and allow it to be directly adopted by the ATM Forum MPOA group, by
>>removing server mode and its IP encapsulation.  During the discussion,
>>Joel Halpern described how NHRP can be transition into a network
>>without server mode.  As NHRP is deployed, requests will begin to be
>>sent to directly attached neighbors, along the routed path. If the next
>>hop is also NHRP-capable, the request will be properly handled; if not,
>>it will be dropped on the floor because the receiver doesn't recognize
>>the protocol type.  In that case, datagrams will simply follow the
>>routed path as before, so nothing breaks.  Configuration is much easier
>>than it had been for server mode.
>>
>>The chair listed the necessary changes to the spec:
>>
>>* All server mode references must be removed from the text
>>
>>* The IP encapsulation must be removed from the packet formats.
>>
>>* An LLC/SNAP encapsulation is required.  The chair will sent a request
>>to the IANA for  a PID codepoint in the IANA's OUI space.
>>
>>Given the scope of these changes, the chair asked for clear consensus
>>for this change, and it was provided by the WG.  There were no
>>objections, including those with existing or in- progress
>>implementations.  There was no support for retaining server mode.

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 gave some further thought to the need for Server Mode
after the meeting. While retaining the standard mode of operation as
without IP encapsulation, I think that maybe we do not have to drop
the Server Mode altogether. Fabric mode requires that all the next hop
routers be NHRP speakers. Otherwise, NHRP will not be applicable and
even if one of the routers in the path does not understand NHRP,  the
packet will go back to hop by hop mode. Server Mode was initially
introduced to ease the transition to NHRP, and I believe its use is
still valid. 

Perhaps the spec can say" Here is the standard mode of operation (Fabric
Mode). If you want to use NHRP before you make all your routers NHRP
speakers, encapsulate your NHRP request with IP with the destination
address being the one of your NHRP Server." This, together with all the 
necessary cautions on interoperability and the scope of applicability
of this approach would be very useful, IMHO.
Perhaps such a text can be added to the Applicability Statement,
instead of the spec, per se.
Please comment.

Derya

Note: I know I was at the meeting and I did not raise this issue
at that time. My apologies to Andy :).