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 :).
- draft rolc minutes Andy Malis
- Re: draft rolc minutes Werner Almesberger
- Re: draft rolc minutes dhc2
- Re: draft rolc minutes Yakov Rekhter
- Re: draft rolc minutes dhc2
- Re: draft rolc minutes Curtis Villamizar
- Re: draft rolc minutes Dan Romascanu
- Re: draft rolc minutes Jim Jackson
- Re: draft rolc minutes Jim Jackson
- Re: draft rolc minutes Mark Laubach