The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1994-Aug> msg00016



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Initial comments on NHRP -02

  • From: Andy Malis <malis@maelstrom.timeplex.com>
  • From: Andy Malis <malis@maelstrom.timeplex.com>
  • Date: Tue, 30 Aug 1994 13:53:24 -0400
  • Date: Tue, 30 Aug 1994 13:53:24 -0400
  • Cc: malis@maelstrom.timeplex.com, rolc@maelstrom.timeplex.com

Dave and Dave,

Thanks for a great job!  Overall, I think it's an easier read, and
overall a tighter document (both technically and otherwise) than the
previous draft.  That said, I would like to get the comment ball
rolling ...

These comments are from my first pass through the document.  More will
probably occur to me as I re-read it again. :-)

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.

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

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).

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.

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.

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.

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