The IP Over NBMA (ION) Archive

[Joel Halpern <jhalpern@us.Newbridge.com>]

Yakov and I have been discussing his questions about the use3 of anycast
in NHRP, in order to determine what the actual problem is.  What follows
is a note that he and I have worked up.  I may have still managed to get
some of his concerns wrong, but it should at least help people understand
what the problem is and how it might be addressed.  Thank you.


1. Abstract.

The current Internet Drafts ( draft-ietf-rolc-nhrp-12.txt) defines the
use of NBMA group, anycast, or multicast addresses as follows:

   If an NBMA technology offers a group, an anycast, or a multicast
   addressing feature then the NHC may be configured with such an
   address which would be assigned to the appropriate NHSs.  The NHC
   might then submit NHRP Resolution Requests to such an address,
   eliciting a response from one or more NHSs, depending on the
   response strategy selected.

The following outlines cases where the above behavior could lead to
incorrect operations.  At the end we will propose a replacement section.

2. Clarification of Applicability

Although the paragraph quoted above is quite clear, it is in fact too
general.  As it says later in the same section:

   With the exception of NHRP Registration Requests (see Section 5.2.3
   and 5.2.4 for details of the NHRP Registration Request case), an NHC
   MUST send NHRP messages over a direct NBMA level connection between
   the serving NHS and the served NHC.

Therefore, the first of the two pargraphs ought to be clarified to
indicate that it applies to Registration packets, not requests and
responses.  It also needs to distinguish between "appropriate" for
receiving an initial registration request, and "appropriate" for
receiving requests from NHCs.

3. Multiple Routing Realms

Consider an NBMA network that is used by several routing realms (e.g.,
several VPNs). In this case use of group/anycast/multicast NBMA
addresses by NHRP could result in crossing routing realm's boundaries. This
may cause establishment of L3 paths that cross such boundaries, which
in turn may result in incorrect operations.

Thus unless there is either (a) a way to guarantee that the whole NBMA
network is used just by a single routing realm, or (b) a way to
guarantee that NHRP messages wouldn't be allowed to cross routing
realm's boundaries, anycast/group/multicast addresses of NHSs on such a
network have to be on a per routing realm basis.  Procedures by which
either (a) or (b) are satisfied are outside the scope of this document.
Thus, currently anycast/group mechanisms can not be used for NHRP 
registration on NBMAs which are shared by multiple domains.  To avoid
customer misconfiguration, it may be appropriate that such (anycast)
behavior default to off, rather than on, with the concomitant loss of
ease of installation.

Note that using anycast/group/multicast addresses on a per routing
realm basis (rather than on a per NBMA network basis) has negative
impact on NBMA routing, as such addresses are not aggregatable for the
purpose of NBMA routing procedures.  This situation is still
more scalable than the use of an anycast address per LAG.

4. Multiple egress NHSs

When a destination could be reachable through more than one egress NHS
(e.g., a path to destination includes more than one segment through an NBMA
network)
use of anycast/group/multicast address may result in a situation where
an NHC that sends a Resolution Request for the destination would
receive a Resolution Reply from an NHS that is not along the path from
the NHC to the destination, even if the NHS is along a path to the
destination (e.g., this could happen when the NHC is in the path from
the NHS to the destination). Use of the information contained in the
Reply by the NHC may result in incorrect operations (e.g., persistent
forwarding loop).

To avoid the above problem one need to guarantee that either (a) a
destination is always reachable though at most one NHS, or (b) the set
of NHSs to which an NHC could submit a Resolution Request are in the
same LIS/LAG as the NHC. Procedures for satisfying (a) are outside the
scope of this document.  Use of anycast/group/multicast addresses on a
per LIS/LAG basis allows to satisfy (b). However, note that using
group/anycast/multicast addresses on a per LIS/LAG basis (rather than
on a per NBMA network basis) has negative impact on NBMA routing, as
such addresses are not aggregatable for the purpose of NBMA routing
procedures.  As an alternative technique for achieving (b), one could
note that the anycast registration procedure results in connectivity
between an NHC and an NHS serving its LIS/LAG.  The current behavior
should be tightened to require that that connection be used for sending
request.

5. Partition

There is one additional case where the use of anycast even for registration
may be problematic.  Registration requests are forwarded, according to 
routing, from a receving NHS towards the home LIS/LAG.  This is designed to
deliver the registration request to an appropriate NHS.  Normally, this
will work.  However, it is possible due to failures of routers or 
conenctions, or just due to oddities of routing, that the routed path from
the first NHS towards the home LIS/LAG may actually exit the NBMA.  If
that occurs, the Registration will be undeliverable.  No response will be
received.  The specification should note this, and indicate that the client
MUST NOT send NHRP resolution requests until the registration succeeds, 
and SHOULD retry the registration request periodically.

6. Replacement Paragraph

For issues 2, 3, and 4, the paragraph described in 1 clearly needs to be
clarified.

   If an NBMA technology offers a group, an anycast, or a multicast
   addressing feature then the NHC may be configured with such an
   address (appropriate to the routing realm it participates in) which
   would be assigned to all NHS serving that routing realm.  This address
   can then be used for establishing an initial connection to an NHS to
   transmit a registration request.  This address may not be used for
   sending NHRP requests.  The resulting VC may be used for NHRP requests
   if and only if the registration response is received over that VC,
   thereby indicating that one happens to have anycast connected to an
   NHS serving the LIS/LAG.  In the case of non-connection oriented
   networks, or of multicast (rather than anycast) addresses, the addres
   MUST NOT be used for sending NHRP resolution requests.

We will also need to examine the remaining text to determine if there are
other places that need to be clarified.



Yours,
Joel M. Halpern                         jhalpern@newbridge.com
Newbridge Networks Inc.