The Routing Over Large Clouds Mailing List Archive by date

[Bryan Gleeson <bryang@eng.adaptec.com>]

Andrew,

>> We should allow clients to use _one_ address
>> resolution protocol, namely NHRP. We should require that NHRP servers
>> also implement ATMARP server functionality, so that a client can use
>> either ATMARP or NHRP. 
>
>I still don't understand the need for a son-of-1577 spec to *mandate* that a
>server implement both ATMARP and NHRP: isn't it sufficient to state
>that there exist two protocols and that servers may come across clients
>implementing both. This is the approach that IETF specs have always taken in 
>the past and implementors decide what makes sense in their products. I don't 
>believe this approach would lead to many "wrong" choices in this case.
>

I guess it is basically a requirements issue, which is certainly a discussion
worth having. There are at least three possibilities

1) upgrade a LIS (or more probably a collection of LISs) to NHRP by 
upgrading the ATMARP servers to NHSs and all the clients to NHRP
clients.

2) allow upgrading of some clients to NHRP, while still supporting 
old ATMARP clients. The ATMARP servers are replaced with NHSs that also
support ATMARP. In this case all the clients are single protocol (either
ATMARP or NHRP) but the servers are dual protocol.

3) create an environment where dual protocol clients are needed, by 
not coupling the ATMARP and NHRP servers together, but still attempt
to support the aim of (2).


My main argument is against (3). 1577+ currently discusses how clients
manage ATMARP and NHRP in parallel. I don't think there is any need
to come up with solutions that require anything other than single
protocol clients. This leaves (1) and (2). (1) is probably fine for many 
cases - it is only a software upgrade after all and it is not as if
there are massive well established 1577 networks all over the place yet.
(2) will be useful in some cases. ATMARP and NHRP clients are already 
compatible on the data plane, so that mixing ATMARP and NHRP clients in 
a single LIS is feasible, if the server side of things supports both.

Should (2) be manadatory ? Perhaps not, given that (1) will cover a
lot of cases. If the goals of (2) are needed then (2) is the way to
go and not (3). We should specify the procedures needed if you want to 
support a mix of ATMARP and NHRP clients in a LIS, but not require
support for this feature.

Having said that there are a couple of provisos. We need to be careful
to avoid the ISO syndrome of "conformant but not interoperable"
by allowing too many options. In general if you allow dumb and intelligent
clients, and dumb and intelligent servers, you run into problems when
you put the dumb client and the dumb server together. I now don't think 
it is necessary to mandate (2) to avoid this pitfall though.

Also things get a bit muddier if NHRP isn't a superset of ATMARP. In
particular if ATMARP supports features such as autoconfiguration and
redundant servers, and NHRP doesn't, then approach (1) will leave
you worse off in these areas. You will then need full client and
server deployment of both ATMARP and NHRP in order to preserve
all existing functionality. This is probably a good argument for
accelerating these issues in the ROLC group.


[...]
>It is also interesting to note that this issue becomes much simpler because
>of the fact that ATMARP requests do not get relayed to clients for
>answering.

In thinking about the multiple ATM cards for one IP address issue this
seemed a promising approach - sort of like the way in LANE a LES
forwards LE-ARPs to proxy LECs, rather than caching and answering 
the queries itself. It does complicate other things though.


Bryan