The Routing Over Large Clouds Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Draft ROLC minutes from 12/5
These are the draft minutes from Monday's ROLC meeting. Please review and respond with comments and corrections. I would like to thank Rich Verjinski, Ken Hayward, and Dave Piscitello, without whom these minutes would not have been so detailed (or even possible). Thanks also go to Dave Katz and Dave Piscitello for their excellent work as the NHRP editors. Andy Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 ------- Routing Over Large Clouds (ROLC) Working Group Minutes IETF Meeting, December 5, 1994 San Jose, California Chair: Andrew Malis, Ascom Timeplex Chair: Andrew Malis, Ascom Timeplex Mailing lists: General Discussion:rolc@maelstrom.timeplex.com To Subscribe: rolc-request@maelstrom.timeplex.com Archive: ftp://cnri.reston.va.us/ietf-mail-archive/rolc/ Archive: ftp://cnri.reston.va.us/ietf-mail-archive/rolc/ There were 108 attendees, many of whom were newcomers. The chair announced that in order to get work done, the group would focus its discussion on the current draft and not rehash earlier decisions (especially the requirements and goals). He then presented the following overheads to start the meeting and provide some background to the first-timers: Agenda Agenda * Agenda bashing * Agenda bashing * ROLC introduction * ATM Forum update * ATM Forum update * NARP and NHRP implementation experience * NARP and NHRP implementation experience * NHRP specification discussion * Open technical issues (authentication, etc.) * Discussion of NHRP status and WG recommendation to the IESG (if any) * Planning for the NHRP Protocol Analysis document * Planning for the NHRP Protocol Analysis document * Updating the workplan Problem Statement * Analyze and propose enhancements to IP routing over * Analyze and propose enhancements to IP routing over large "shared media" link layer (with respect to IP) networks * ATM * ATM * Frame Relay * X.25 * SMDS * etc. * Avoid "extra hops" when routing IP * Avoid "extra hops" when routing IP * Defined as IP datagrams leaving and re-entering the same link-layer cloud as a result of an IP routing decision, such as when routing between different IP subnets overlaid on the same cloud ROLC Requirements * Enable communications between two entities in different IP subnets on the same cloud. * Support policy restrictions (cannot subvert filtering, etc.). * Be compatible with existing routing protocols. * No new infrastructure deployed. * Must apply to multiple media and routing technologies. * Must be loop free. * Support for complex cases should not unduly burden simple cases. * Support routing hierarchies and aggregation. * Operate in the presence of multiple layers of routing aggregation, including aggregates which cross the cloud boundary. ROLC Goals * Should be effective and cheap in terms of network resources. * Be extensible to handle QoS (and other new features) in the future. * Be able to determine the path before having sent any data packets over it. * Should be diagnosable. * Should be deterministic. * Should work on a cloud where not all attached routers are NHRP-capable. * Reasonable robustness in the face of misconfiguration. * As much autoconfiguration as possible. * As much autoconfiguration as possible. * Non-goal: the working group is not trying to couple this work to link layer routing (this would involve significantly more complexity). Introduction to Next Hop Resolution Protocol * Used by IP source station to determine "best" link layer address to use to reach a destination station * Result may be link layer address of: * The destination itself * Closest exit router to the destination * An intermediate router, if required by policy * An intermediate router, if required by policy restrictions * NHRP may be incrementally deployed * First in some routers - Server Mode * In all routers - Fabric Mode * Hosts are identical no matter which mode is in use * Host support may be incrementally deployed as well (existing hosts can benefit via NHRP-capable router) Protocol Overview * Participating hosts register with their Next Hop Server (NHS), exit routers may register entire IP subnets behind them * Source host sends NHRP request to NHS, host may also send data along routed path * NHSes forward the request to the destination's NHS * Destination's NHS returns proper link layer address, result cached on way back * Source opens direct connection to destination for subsequent datagrams Server Mode and Fabric Mode * In Server Mode, only a small number of routers also NHSes * Static configuration used for NHS-to-LIS associations and NHS adjacencies * This produces NHRP request/reply route * In Fabric Mode, all ingress/egress routers are also NHSes * IP Routing used to produce NHRP request/reply route * No static configuration required * Host configuration is identical for both modes NHRP Supports ... * Network-layer policy restrictions * If a router on the path has filtering enabled, it can provide its own address in the response * Quality of Service * Desired QoS of the final path can be included in NHRP Requests * Supportability * Includes forward and reverse route recording and full error indications * Other network layer protocols * Protocol ID field allows use of IPng and other network layer address formats in NHRP requests and replies Current Workplan Dec 94 Meet at San Jose, put finishing touches on NHRP, plan implementations and analysis document. Dec 94 Submit NHRP document to IESG as a Proposed Standard. Apr 95 Submit companion analysis document to IESG. Apr 95 Submit companion analysis document to IESG. During the presentation, Curtis Villamiza reminded the group that at the Seattle meeting, a goals and requirements document was discussed. While they have been documented in both the Seattle and Toronto minutes and proceedings, The chair invited him to write such a document. He may do so if he has the time. ATM Forum Update ATM Forum Update The WG received an ATM Forum update from Drew Perkins and The WG received an ATM Forum update from Drew Perkins and Joel Halpern, direct from the previous week's ATM Forum Joel Halpern, direct from the previous week's ATM Forum meeting in Kyoto. The primary news was from the Multiprotocol over ATM group. The primary news was from the Multiprotocol over ATM group. Most of the discussion there was concerning requirements, along with some discussion of reference models. The main agreement from the meeting was there will be one host behavior, query-response (based upon Classical IP over ATM, behavior, query-response (based upon Classical IP over ATM, NHRP, and ATM Forum LAN Emulation). NHRP, and ATM Forum LAN Emulation). Implementation Experience Reports The one detailed report was from Kanan Shah of NRL. She has been finishing her code is almost at the testing stage. Testing will take place on the ATDnet (a large-scale OC-48 Testing will take place on the ATDnet (a large-scale OC-48 ATM testbed that rings the Washington DC area). She plans ATM testbed that rings the Washington DC area). She plans on testing with Rob Coltun's PNNI routing code. Dave Katz said that Cisco also has an implementation under way (being developed by Bruce Cole), but was not at liberty to further discuss its status. Current NHRP Draft Review Dave Katz, along with Dave Piscitello, the NHRP editors, led a detailed review of the current draft, draft-ietf-rolc- nhrp-03.txt, which had been distributed on the mailing list the previous week. Among the major issues discussed were: previous week. Among the major issues discussed were: * There has been a change in the packet format. The MBMA * There has been a change in the packet format. The MBMA family identifier is now a 16 bit number, and can be found in "Assigned Numbers". in "Assigned Numbers". * The Authentication option has also been changed. An * The Authentication option has also been changed. An option has been added for MD5. * Curtis Villamizar brought up a question as to the semantics of the S bit, which will be better clarified in the text. There will be further investigation of the usefulness of the "S" bit, which is used to identify whether a potential looping scenario exists. * The WG needs to further investigate the usefulness of a "C" bit to distinguish destinations attached directly to NBMA bit to distinguish destinations attached directly to NBMA fabric from those that are not, and a "J" bit to say "I assert that the destination I'm informing you of is directly reachable via me (no intervening routers)". * Curtis was recognized for his contribution in section 8.1. * The WG needs to improve the description of destination masks (guidelines for constructing the mask, means by which requester distinguishes the appropriate mask length). * There was discussion on "hole punching" in cached aggregated destinations. * A discussion on options was made referencing non- * A discussion on options was made referencing non- optional and optional options. For clarification, there is an option bit that tells the implementation what to do if it does not support particular options. The terminology has been changed to "discretionary" and "non-discretionary" options. Three of the options have been made discretionary: destination mask option (Section 5.6.1); QoS option (Section 5.6.6); vendor-private (Section 5.6.8). * The discussion on page 2 that suggests that NHRP obviates the need for LISs will be revised. * A discussion of routing loops was led by Curtis. The * A discussion of routing loops was led by Curtis. The solution when a routing loop is detected is to break the VC. We concluded that routing loops only occur in the router-to- router case, and then only if routers use NHRP information to take precedence over information learned by routing protocols. Curtis is going to send mail to the list on the subject. * The question of when you use Classical ARP and when you * The question of when you use Classical ARP and when you use NHRP was raised. The sequence of events will be: 1. Only ARP servers are used as per RFC 1577. 1. Only ARP servers are used as per RFC 1577. 2. NHRP is phased in: * Hosts continue to register with the ARP server (until * Hosts continue to register with the ARP server (until ARP servers go away, for the benefit of non-NHRP hosts). ARP servers go away, for the benefit of non-NHRP hosts). ARP servers will leak registrations to NHRP servers, so NHRP ARP servers will leak registrations to NHRP servers, so NHRP hosts don't have to register twice if they don't wish to (but then they must agree to certain defaults, such as the registration timeout period). If NHRP hosts wish to set these values, then they must also register with the NHRP server. Explicit registrations always take precedence over leaked registrations. * NHRP source hosts send all address resolution requests to the NHRP server (without regard to the "mask and match" operation). * NHRP source hosts may send ARP requests to their ARP * NHRP source hosts may send ARP requests to their ARP server if they get a NHRP NAK and the destination is in the server if they get a NHRP NAK and the destination is in the same LIS. 3. NHRP servers completely replace ARP servers. All hosts 3. NHRP servers completely replace ARP servers. All hosts are NHRP-capable. * Intermediate router operation: If the IR is willing to set up a direct VC to the destination, it must be willing to cache the fact it has generated and/or forwarded the NHRP request for that address (so that it won't generate another). If it is not willing to set up a VC, then it will not need to cache the fact that the request was forwarded. * On a related issue, the document should adequately cover how to restrict generation of NHRP requests (will every packet generate one if one is already in flight, will every NHS generate a request along the routed path, etc.). * Note that when a router returns an NHRP reply for its own IP address, it should mark the S bit as originating from a host. * A request to the group was made for someone to help * A request to the group was made for someone to help with authentication, and Sandra Murphy of TIS volunteered to provide assistance. * It was agreed that more text should be added to the document discussing the aging of information. * The suggestion was made for a host implementation cookbook. * There was a request for volunteers who are willing to explore other protocols in the context of NHRP. Other protocols of interest are IPv6 and IPX. There were no volunteers in the room. Please send mail to the chair if you are interested. Dave and Dave will be producing a new revision reflecting the discussion. New Work Items: The Routing Area Director told the WG that a protocol analysis The Routing Area Director told the WG that a protocol analysis document, while required for protocol standardization, was probably premature at this point. However, Kanan Shah has volunteered to begin its preparation. Two other documents were assigned to volunteers: * Protocol Applicability: Derya Cansever. * Protocol Applicability: Derya Cansever. * The NHRP MIB: Mike Patrick. Mike will begin by compiling an initial list of objects of "interest" for debugging, operational support, tuning knobs, and so on, and sending them to the list for review and suggestions. Anyone interested in helping out with these documents should Anyone interested in helping out with these documents should contact either the authors or the chair. Work Plan Update: * It was decided that the NHRP document should be submitted to the IESG as a proposed standard following at least one more revision. The WG has a goal of Feb. 95 submission. * The WG should submit the companion applicability document to the IESG in April 95. to the IESG in April 95. * The WG should have a draft of the MIB document by April 95. * The WG should have a draft of the MIB document by April 95. An updated charter will be forthcoming. An updated charter will be forthcoming. |
|