Re: Draft ROLC minutes

[Carl Marcinik <[e-mail]>]

Andy,

A few comments on the draft ROLC minutes:

>Below are the Dallas minutes.  Sorry they took so long, but I wanted to try
>to make sure I got everything in.  Before reading them, I highly suggest
>you first grab everything you find in ftp://ftp.nexen.com/pub/rolc/.  All
>of the viewgraphs and talks mentioned below are now available there,
>including Hiroshi Suzuki's talk.  You'll notice that there are two
>postscript files for his talk, part1 and part2, but that I was able to
>combine them into one Acrobat (pdf) file.
>
>Please reply asap if you have any comments - they are supposed to become
>official a week from today.
>
>Thanks,
>Andy
>-------

. . .

>
>7.   Server redundancy: This is not addressed in the current
>  spec.  A strict reading suggests that if there is more than
>  one NHS in a LIS, then NHRP clients must register with all
>  of them.  The WG agreed that addressing server redundancy is
>  required before NHRP is "ready for prime time".  The WG
>  agreed that it would be a reasonable goal to leverage (and
>  interoperate with) the IPATM WG's synchronization method, if

My comment here concerns the contents of the parentheses above. As I 
recall, there was a desire to perhaps leverage the IPATM WG's redundancy/
synchronization scheme for NHRP. However, I do not believe that there
was general agreement or a specific discussion concerning interoperability
between the two "synchronization" schemes themselves. There was a discussion
in the context of ARP/NHRP coexistence and transition regarding client
address resolution and interoperability. It was this discussion that led
to the decision to remove any references to NHRP from the "Classical Update"
draft. I do not believe that, in any subsequent discussions, we agreed
that a NHRP server and an ATMARP server should directly interoperate from
the perspective of server synchronization (which is what the parenthetical
statement seems to imply). There are other implications to this statement,
some of which I address indirectly below.

>  possible.  This discussion will be continued on the mailing
>  list.
>
>8.   Autoconfiguration:  The issue of how to configure
>  clients and servers came up during the redundancy
>  discussion.  There was strong consensus for
>  autoconfiguration capabilities, supported either from
>  network management via the NHRP MIB, or via a configuration
>  server.  The point was made that while ATM anycasts are
>  useful to find configuration servers, they should not be
>  used to find NHRP servers.  

A few minor clarifications here. There was a view expressed that ATM
anycasts should not be used to find NHRP servers directly. However, there
was no consensus that this view reflected the WG's position on this topic. 

>  There was consensus to use NBMA-
>  level configuration services if possible; this led to a
>  liaison to the ATM Forum regarding ROLC's interest in using
>  the ATM Forum's LAN Emulation Configuration Server (see
>  below).

I do not recall there being clear consensus reached during the first session 
with regard to the utilization of "NBMA-level configuration services." In fact,
it was pointed out that the discussion concerning *both* redundancy and 
autoconfiguration was very ATM-specific even though we had just gone to some 
lengths to ensure that the general NHRP (and MARS) packet formats reflected 
media-independent parameters. There was a specific question as to how the
WG planned to handle specifying the media-dependent instantiation of NHRP
vs. the media-independent aspects of the protocol. I do not recall a clear
answer being given to this question (although the issue was acknowledged by
Joel Halpern). 

The ATM Forum liaison was not discussed until the second 
session. It seems that, at best, any efforts resulting from the liaison could 
be leveraged against the ATM-specific instantiation of NHRP. Are you therefore
saying that we reached consensus that redundancy and autoconfiguration
should be handled on a case-by-case basis for each media type that could
possibly utilize NHRP? I don't think this was the case either. Therefore, I
do not think it would be fair to say we reached any consensus within the WG
on this matter other than to forward a liaison statement to the ATM Forum
with the *hope* that there *might* be an opportunity to leverage some of the
work being envisioned for a more general ATM configuration service that could
support the ATM-instantiation of NHRP. This still leaves open several issues
WRT support of a general (i.e., media-independent) redundancy and 
configuration scheme for NHRP, how the media-dependent instantiations will
be specified (from an IETF perspective), and whether the media-dependent
instantiations (e.g., ATM) of NHRP should (perhaps) be co-developed  with
the appropriate WGs where they exist (e.g., IP-ATM). 

>  The point was also made that ATM Forum anycasts
>  cannot be used in an IETF document until UNI 4.0 is publicly
>  available.  This discussion will also be continued on the
>  list.
>

. . .


Regards,

Carl Marcinik
FORE Systems