The Routing Over Large Clouds Mailing List Archive by date

[Andy Malis <malis@maelstrom.timeplex.com>]

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
       <malis@maelstrom.timeplex.com>

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 Villamizar 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