The Routing Over Large Clouds Mailing List Archive by date

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

Please let me know if you have any additions or corrections.

MANY, MANY thanks to Caralyn Brown for recording these minutes.
MANY, MANY thanks to Caralyn Brown for recording these minutes.

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) - Toronto IETF meeting

Monday, July 25, 1994, 13:30-15:30 and 16:00-18:00.

Chair: 
   Andrew Malis <malis@maelstrom.timeplex.com>
   Andrew Malis <malis@maelstrom.timeplex.com>

Routing Area Director:
Routing Area Director:
   Joel Halpern <jhalpern@newbridge.com>

Mailing lists:
   General Discussion:rolc@maelstrom.timeplex.com
   To Subscribe:      rolc-request@maelstrom.timeplex.com
   Archive:           ietf.cnri.reston.va.us:/ietf-mail-archive/rolc/*
   Archive:           ietf.cnri.reston.va.us:/ietf-mail-archive/rolc/*


Agenda
Agenda
------

- Bash the agenda
- Discuss overall WG goals
- Discuss technical problem statement requirements, and goals
	review from the previous meeting
- Discuss NHRP draft (Dave Katz)
- discuss future direction, assign work items


Working Group Goals and and Technical Problem Statement
-------------------------------------------------------

The chair presented overheads (reproduced in the proceedings) which
are paraphrased below.

Problem statement:

Analyze and propose enhancements to IP [and IPng] routing over large
Analyze and propose enhancements to IP [and IPng] 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.  Extra hops are defined as points
Avoid "extra hops" when routing IP.  Extra hops are defined as points
where an IP datagram leaves and re-enters 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.

Configurations to be considered include (see the proceedings for the
illustrations):

	- Hops through a router from a terminal (synonymous with
	  endstation or host) in one LIS (IP subnet) to another
          terminal in a different LIS, where all three are connected
          to the cloud, and the router is a member of both subnets.

	- Hops from a terminal on the cloud to the "optimal" next hop,
	  for off-network destinations.  The example used was a
	  terminal-router-router-Ethernet path, where the first router
	  joins two LISes, and the second router connects the second
	  LIS to an external Ethernet.  We would like to eliminate the
	  hop through the first router and go directly to the optimal
	  exit router from the cloud.

	- Transit traffic through the cloud between routers on the
	  cloud "edge".

The work is being done under the assumption that IP routing is not
meshed with the cloud routing.  This means that IP is layered above
the link layer routing to keep as much of the IP layer assumptions as
possible.

One would like to make as few hops in and out of the cloud as possible
for a number of reasons, such as if the link-layer service is metered,
or to conserve link-layer resources.

At this point the discussion turned to the idea of merging the IP
At this point the discussion turned to the idea of merging the IP
routing and the link layer routing.  Because this is considered an
explicit non-goal (in Seattle and before), the chair suggested that
perhaps this discussion would best be moved to a BOF at the next IETF
meeting.

There were also several questions about whether we would entertain
different solutions for connection-less and connection-oriented link
layers.  Because we have a specific charter goal to be independent of
the link layer, the group should attempt to find a single solution.



Review of Requirements and Goals
--------------------------------

These are the criteria against which proposed solutions will be
compared.

Requirements (from Seattle)

- 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 (with OSPF, BGP
  etc.).

- No new infrastructure deployed in order to support this (no new
  hardware involved).

- Must apply to multiple media and routing technologies (ATM, FR,
- Must apply to multiple media and routing technologies (ATM, FR,
  X.25, and futures).

- Must be loop free. 

- Support for complex cases should not unduly burden simple cases. 

- This SHOULD be applicable to other internetworking protocols (and
  not just IP or IPng).

- Support routing hierarchies and aggregation.  

- Operate in the presence of multiple layers of routing aggregation,
  including aggregates which cross the cloud boundary (a portion of
  the aggregate is not in the cloud itself).

Goals (from Seattle)
  
- Do not hold up the simple case to solve the complex case (time to
  market).

- The address resolution should be effective and cheap in terms of
  network resources.

- Be decoupled from specific infrastructure, both media and routing,
  as much as possible (don't assume ATM).
  as much as possible (don't assume ATM).

- The solution should converge to desirable routes.  (We don't want to
  make route longer than it would have been without this work).  This
  is really a goal for set-up time, not the life-time of the
  connection.  Route caches time out over a configurable time,
  allowing new, perhaps better, routes to be periodically discovered.

- 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.  This is a
  difficult (perhaps to the point of unobtainable) goal.

- Non-goal: the working group is not trying to couple this work to
  link layer routing (this would involve significantly more
  complexity).

One new goal was added in this meeting:

- As much auto-configuration as possible.
- As much auto-configuration as possible.

In order for us to be successful in this work, the rule that IP must
use a router to send datagrams to subnets other than the one to which
it is attached must be relaxed.  Joel Halpern agrees that this "rule"
must be modified and feels that he is in a position to help move this
along (given a sufficiently strong technical proposal to back it up).

Also implicit in this work is the assumption that link layer
Also implicit in this work is the assumption that link layer
processing will either keep the connection up or kill the connection
entirely.  We won't have to worry about a connection that is only
partially complete.

Caution must be taken to ensure that if there is a "fire wall" router
in the long (extra hop) path, the final path must traverse this router
so as not to avert the filtering.  It is the fire wall router's job to
assure that it is traversed.


Review of NBMA Next Hop Resolution Protocol (NHRP)
Review of NBMA Next Hop Resolution Protocol (NHRP)
--------------------------------------------------

The review of the NHRP specification (draft-ietf-rolc-nhrp-01.txt) was
led by Dave Katz, the editor (and current primary author) of the
document.

This work is the follow on to the NARP (NBMA ARP) document,
This work is the follow on to the NARP (NBMA ARP) document,
draft-ietf-rolc-nbma-arp-00.txt.  Work on NARP continues to progress
draft-ietf-rolc-nbma-arp-00.txt.  Work on NARP continues to progress
in order to get at least a partial ROLC solution out now (see the end
for more details).

Both NARP and NHRP use a server that provides the best possible
Both NARP and NHRP use a server that provides the best possible
link-layer address to use to reach a particular IP terminal address.
NARP only covers the case when both terminals are connected to the
NARP only covers the case when both terminals are connected to the
same link-layer cloud, while NHRP is designed to be the more general
solution.

While the documents don't require it, NARP and NHRP servers are
While the documents don't require it, NARP and NHRP servers are
expected to be implemented in routers.  Only some routers in a cloud
are required to be servers, and, in the case of NHRP, not all of the
routers in the cloud require NHRP to be implemented.

When two terminals x and y learn of each other through messages passed
from their NHRP servers, the finished path is not advertised to others
so that others do not just use this path blindly.  Each terminal must
find its own way through the cloud.  The document does not point this
out specifically, but it will in the next revision.

Two basic assumptions prevail at this point:
1. If a terminal answers, it is assumed to be available to make a
   connection. 
2. All information about destinations have timers associated.
2. All information about destinations have timers associated.

If two terminals that are trying to communicate are directly connected
to the network, should the request go all the way to the terminal?
No.  The serving routers will already know about terminals because of
prior registration or configuration and there is no need to pass the
request further than the serving router.

Presently there is no language in the document talking about
authentication.  This will be added in subsequent drafts.

NHRP is not intended to build on top of Classical ARP described in RFC
NHRP is not intended to build on top of Classical ARP described in RFC
1577.  It is a separate document.

Terminals not on the cloud do not have to register with a server,
since the router/server on the edge implicitly serves all on the
subnets behind it.

The network ID option is to detect if you are going from one cloud
to another.

The route record option addresses diagnosability.  It helps keep track
of how things were propagated.  In the case of link layer filtering,
NHRP sends the request to the end, and then may not be able to
complete the call.  Adding an identity to the record list indicates
complete the call.  Adding an identity to the record list indicates
that the adding entity will "sink" the call.  This provides the
ability to short cut part of the way.

Multipath problems: If a duplicate packet is sent in different
directions to establish different paths to same end, there may be
problems with explosion of data in replication and looping. Turning on
the report path option may help avoid this situation.

There was a request for the addition of a request identifier to avoid
the problem of opening simplex connections.

The draft specifies a protocol identifier for IP as CC.  There are
those that wonder if this should be an ethertype value instead
(0x0800).  Dave believes that getting NLPIDs for IPX etc is not
that difficult and so prefers this method.

How do you describe the various link layer addresses?  This is a
current hole that must be filled.  We could use the types defined in
the ARP fields now.  Assume that we should use address families, not
the ARP fields now.  Assume that we should use address families, not
media types.

If, when forming a NHRP reply, there are multiple valid answers, there
is no way to indicate the relative value of the various answers.
There should be a very specific way to indicate relative precedence
rather than relying on the order in which the answers are included in
the response packet.

If there is a NHRP register then there should probably be an
unregister, but then this might add some authentication problems.

The question arose that there might be a need for a source route
option.  Dave wishes to delay the addition of a source route option
until is is demonstrated that this option is truly useful.


Future Direction and Work Items
-------------------------------

NARP:
NARP:

There are currently two NARP implementations in progress, by Telecom
There are currently two NARP implementations in progress, by Telecom
Finland and NRL.  The WG agreed that the NARP spec should be published
Finland and NRL.  The WG agreed that the NARP spec should be published
as an experimental RFC while work continues on NHRP.

NHRP:

The group is encouraged to provide additional comments and send them
to the authors and/or the working group.  Another draft will be posted
to the authors and/or the working group.  Another draft will be posted
which will include some of the items discussed above, and hopefully
some additional authentication text.  The next draft is expected to be
posted well before the meeting, so that it can be discussed over the
net.  The WG's goal is to complete work on the draft at the San Jose
meeting.

Volunteers are solicited to help work on the open issues, especially
authentication.