Subject: Re: AAP draft quick comments

From: Steve Hanna <[email-masked]>
Date: Wed, 06 Oct 1999 14:20:56 -0400

Some months ago, you commented on aap-01:

> 2) The ASA (Address-Set-Announce) message should have entry with
> total number of sets in the message

and

> 4) All other messages (ACLM, AITU, AIU, ASRP) do not have mask
> field. A 'Mask' field and 'Number of Entries' field should be added
> to each of those messages.

Why do you think that a Number of Entries field should be added? It
should be easy to determine the number of entries in any of these
messages, using the message length.

With respect to the Mask field, I think that this field should only be
used in the ASA and ASRP messages. In the ACLM, AITU, and AIU messages,
I would like to use a first address-last address format like MZAP and
MADCAP use. The latter format can represent any address range, while the
former can only represent certain ranges. For instance, the range
239.192.17.27-239.192.17.35 is easy to represent in the first-last
format, but hard to represent in the first/mask format. The first/mask
format can represent discontiguous address sets more efficiently than
the first-last format, but I don't expect that this feature will be used
very often in the ACLM, AITU, and AIU messages. I do expect that MAAS's
may frequently want to claim ranges that can't be easily represented
with the address/mask format.

In fact, I think that we might want to consider using the first-last
format for the ASA messages, too. There's a conflict between scopes that
use MASC, where a discontiguous mask is useful, and scopes where the set
of addresses available is configured by an administrator. In the latter
case, the address set may not be easily representable using an
address/mask representation. For the former, the address/mask
representation representation will be more efficient.

For instance, a MASC router might want to announce that the addresses
starting at a base address of 224.2.0.0 with a mask of 0xfffeff00 are
available. That is, addresses 224.2.0.0-224.2.0.255 and
224.3.0.0-224.3.0.255 are available. This is the example from section
4.2.1 of the AAP spec with your suggested modification to use 1 bits in
the mask to indicate invariant bits.

In another example, a "small" scope may be defined to contain addresses
239.192.17.27-239.192.18.255. This range is a legal admin scope (as far
as I can tell) and it can be represented easily in MZAP's first
address-last address representation, but it cannot be easily represented
using address/mask representation. The address/mask representation would
be 239.192.17.27/32, 239.192.17.28/30, 239.192.17.32/27,
239.192.17.64/26, 239.192.17.128/25, 239.192.18.0/24.

Now, there may be an unwritten rule that all admin scopes must be
representable using a single address/mask pair. But this doesn't
completely solve the problem, as you might have a "large" scope of
239.192.16.0-239.192.31.255 that is divided up by a foolish
administrator using manual configuration into several allocation
domains, which he gives addresses 239.192.16.0-239.192.17.26 and
239.192.17.27-239.192.18.255. Perhaps the best solution is to tell
people not to do that. And use address/mask for ASA and first-last for
the other messages.

-Steve

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Wed, 06 Oct 1999 13:22:46 -0700

> messages, using the message length.

You are right. I just thought that if for some reason the format is
changed in the future such that there is something after the the set
of addresses, then the above technique cannot be used.

> former can only represent certain ranges. For instance, the range

I agree that the first address-last address format allows more
flexibility. However, I didn't see any start/end address fields in
any of the messages, just "IPv4 Multicast Address". Am I looking in
the wrong version of the draft (the one I have is from the I-D
directory in ftp.isi.edu)?

> representation representation will be more efficient.

Agree.

Pavlin

---

From: Steve Hanna <[email-masked]>
Date: Thu, 07 Oct 1999 10:40:07 -0400

> of addresses, then the above technique cannot be used.

That's true. But I'm not sure we want to encourage adding fields to the
end of existing messages. It would probably be better to just define new
packet types.

> directory in ftp.isi.edu)?

Nope. You're looking at the right version. I'm working on a new version
now and I'll be changing the packet format to use first-last format.

> > representation representation will be more efficient.

OK.

Thanks,

Steve