The Routing Over Large Clouds Mailing List Archive by date

[Dave Katz <dkatz@cisco.com>]

   1. Terminology: You use "logical NBMA network" and "link layer
   1. Terminology: You use "logical NBMA network" and "link layer
   network" interchangably.  While this is technically correct, it might
   be less confusing to the reader to always use the former.

Noted.

   2. P. 2: I would like to suggest a couple of wording changes:

      An NBMA network may, in general, consist of multiple logically
      An NBMA network may, in general, consist of multiple logically
      independent IP subnets (LISs), defined in [3] and [4] as having the
      following properties:

	 1)  All members of a LIS have the same IP network/subnet number
	 1)  All members of a LIS have the same IP network/subnet number
	     and address mask.

	 2)  All members within a LIS are directly connected to the same
	 2)  All members within a LIS are directly connected to the same
			 ^^^^^^ change to "of"
	     NBMA network.
	     NBMA network.

	 3)  All members outside of the LIS are accessed via a router.
	 3)  All members outside of the LIS are accessed via a router.
		 ^^^^^^^ change to "stations"

      IP routing described in [3] and [4] only resolves the next hop
			   change to "destination's NBMA"   ^^^^^^^^ 
			   change to "destination's NBMA"   ^^^^^^^^ 
      address if the destination station is a member of the same LIS as the
      source station; otherwise, the source station must forward packets to

Noted.

   3. P. 4: In the following text:

      If the NHRP request is triggered by a data packet, station S may
      choose to dispose of the data packet While awaiting an NHRP reply in
      one of the following ways:

	(a)  Drop the packet
	(b)  Retain the packet until the reply arrives and a more optimal
	     path is available
	(c)  Forward the packet along the routed path toward D

      The choice of which of the above to perform is a local policy matter,
      though option (c) is an attractive default.

   I think it is best to drop options a and b completely.  One criticism
   I've seen of NHRP is that it requires an end-to-end round trip time
   before you can start sending data.  That is obviously wrong (even
   ignoring caching), and dropping options a and b make it clearer that
   you should be sending datagrams on the network layer path while
   waiting to get information on the more optimal path (after all, there
   may not be one).

The reason that option (c) may not be chosen is that the customer, er,
network administrator may choose to provision the "nailed up" infrastructure
with the expectation that only routing traffic will traverse it (putting some
semi-predictable upper bound on load) and that all data traffic will
traverse short-cut paths.  This is especially likely to be true in
networks with per-VC bandwidth reservation.  Personally, I think this is
an implementor choice, since from a protocol correctness standpoint it
doesn't really matter.

   4. Address types:  We should decide how to characterize link layer
   4. Address types:  We should decide how to characterize link layer
   addresses.  We have, at the very least:

   E.164 (ATM, SMDS, FR, ISDN, ...)
   E.164 (ATM, SMDS, FR, ISDN, ...)
   NSAP  (ATM)
   NSAP  (ATM)
   E.164 with NSAP subaddress (ATM)
   E.164 with NSAP subaddress (ATM)
   X.121 (X.25)
   802 ???
   others?

   Should we just enumerate this list and start a new IANA numbering
   Should we just enumerate this list and start a new IANA numbering
   category?  Go with ARP numbers?  I'm open to suggestions, but we
   category?  Go with ARP numbers?  I'm open to suggestions, but we
   should close the issue.

I've already started the ball rolling with Jon Postel to create a new
address type registry.  The ARP hardware type codes are fatally flawed
address type registry.  The ARP hardware type codes are fatally flawed
because they refer to hardware types, sort of (note the separation
between Ethernet and 802, which burned multimedia bridge vendors
seriously) and they don't account for media allowing multiple address
types (ATM, SVC frame relay, etc.)  Fundamentally we're talking about
types (ATM, SVC frame relay, etc.)  Fundamentally we're talking about
address formats rather than hardware types (for instance, if somebody
really came up with a "seamless" (hah!) interworking between ATM and
really came up with a "seamless" (hah!) interworking between ATM and
SVC frame, using the same addresses, NHRP should arguably not stand
in the way.  Yuck, I know...)

   5. Security considerations

   Section 6 should, at a minimum, discuss how NRHP can (and should) be
   configured to prevent link-layer tunneling beneath network-layer
   filtering on the "normal" path between the source and destination
   stations.

There are some pretty broad security/authentication issues around this
protocol, particularly in a public carrier environment.  Dave has been
looking into some of these, and we definitely need to flesh this out.

   6. Other "for further studies" and TBDs

   These need to be resolved, of course, especially the pseudo-code,
   before the document can go to Proposed.  This is a working group, and
   contributions and suggestions are always welcome.

Kanan Shah is planning to contribute pseudocode very soon.

   7. Evaluation of NHRP vs. WG requirements and goals

   Would anyone on the list be willing to generate a comparison of this
   NHRP draft vs. the goals and requirements stated in the Toronto
   minutes?  Volunteers are solicited.  This comparison could also be a
   convenient starting point for the NHRP protocol analysis document.


   Again, thanks for the great work, and getting it out so quickly, so
   Again, thanks for the great work, and getting it out so quickly, so
   that we can work on at least one or two more refinement drafts between
   now and San Jose!

   Cheers,
   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