On 18-Dec-21 10:42, Michael Richardson wrote:
Toerless Eckert <t...@cs.fau.de> wrote:
> On Tue, Dec 14, 2021 at 03:28:52PM -0500, Michael Richardson wrote:
>> But, no point in advertising in GRASP (over an ACP) an objective that
>> only be satisfied by going to the dataplane to do IPv4.
> ASA would use the ACP (IPv6) to coordinate amongst each other for some
> autonomic function, BUT: The objective data/parameters they exchange
> would often be about their nodes data-plane addresses, which will often
> be IPv4. For example i create an "Auto-IP-Multicast AF", then the ASA
> would announce their data-plane IPv4 addresses for e.g.: RP election or
> the like.
yes, but that would be in the negotiation about that ASA (which is new work
at this point), and in which one could use RFC9164.
What I understand is Brian suggesting that we change RFC8992, section 5.1,
5.2, so that instead of:
prefval /= pref6val
pref6val = [version6, length, ?prefix]
version6 = 6
length = 0..128 ; requested or offered prefix length
prefix = bytes .size 16 ; offered prefix in binary format
prefval /= pref4val
pref4val = [version4, length4, ?prefix4]
version4 = 4
length4 = 0..32 ; requested or offered prefix length
prefix4 = bytes .size 4 ; offered prefix in binary format
we'd plug in RFC9164.
(Section 6.1 could also be revised)
As far as I can see, we could trivially augment prefval with a tagged item
there. Is it worth doing? I don't think so.
The only argument I have is that once the new tags are supported in the
popular CBOR libraries, we'd very slightly reduce the work involved
in implementing RFC8992. But looking at my demo code, it's a negligible
change. I agree that it isn't worth updating the RFC for this. Unless
anyone disagrees, I think the discussion's over.
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
