[Anima] Minor nits in ACP examples (draft-ietf-anima-autonomic-control-plane-27)

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 10 July 2020 03:07 UTC

From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
To: Anima WG <anima@ietf.org>, draft-ietf-anima-autonomic-control-plane.all@ietf.org
Message-ID: <48c611ca-ded6-ea5a-732d-4940022f717f@gmail.com>
Date: Fri, 10 Jul 2020 15:07:16 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/C91ZVcnC1ji60W-Prp2aWyWDb1k>
Subject: [Anima] Minor nits in ACP examples (draft-ietf-anima-autonomic-control-plane-27)
Precedence: list

Following a request from Toerless, I've carefully checked the example GRASP
messages in draft-ietf-anima-autonomic-control-plane-27.

Firstly Figure 3: GRASP SRV.est example. There are two nits:

(1) The ULA address is short by one hex digit.
(2) The GRASP objective lacks a value; for correct message syntax, we need a null value.
(This is 'any' in the CDDL syntax, which effectively makes it an extension point).

OLD:

        [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
            [["SRV.est", 4, 255 ],
            [O_IPv6_LOCATOR,
                 h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]]
        ]

NEW:

        [M_FLOOD, 12340815, h'fd89b714f3db00002000000640000001', 210000,
            [["SRV.est", 4, 255, null ],
            [O_IPv6_LOCATOR,
                 h'fd89b714f3db00002000000640000001', IPPROTO_TCP, 443]]
        ]

Once serialized and CBORed, the actual message payload would be
0x85091a00bc4e4f50fd89b714f3db000020000006400000011a000334508284675352562e6573740418fff684186750fd89b714f3db00002000000640000001061901bb

Second, Figure 5: GRASP AN_ACP example. There is one nit and one quibble.

1) There's a missing comma between two elements
2) It's against the GRASP spec to have the same session ID in two different flood messages.
So I believe we should change the session ID for this example.

OLD:

       [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000,
         [["AN_ACP", 4, 1, "IKEv2" ],
          [O_IPv6_LOCATOR,
               h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]]
         [["AN_ACP", 4, 1, "DTLS" ],
          [O_IPv6_LOCATOR,
               h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]]
       ]

NEW:

       [M_FLOOD, 43215108, h'fe80000000000000c0011001feef0000', 210000,
         [["AN_ACP", 4, 1, "IKEv2" ],
          [O_IPv6_LOCATOR,
               h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]],
         [["AN_ACP", 4, 1, "DTLS" ],
          [O_IPv6_LOCATOR,
               h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]]
       ]

Once serialized and CBORed, the actual message payload would be
0x86091a0293690450fe80000000000000c0011001feef00001a00033450828466414e5f414350040165494b45763284186750fe80000000000000c0011001feef000011193a98828466414e5f41435004016444544c5384186750fe80000000000000c0011001feef000011194268

Running code:

At https://github.com/becarpenter/graspy, you can find ACPcontainer-v27-examples.py, which generates GRASP floods for these two precise examples, but of course with new pseudo-random Session IDs each time, and genuine IPv6 addresses. ACPnewby.py demonstrates how a new ACP node will receive and decode the examples. Incidentally, the ACPnewby code hasn't changed since October 2017.

Regards
   Brian Carpenter

[Anima] Minor nits in ACP examples (draft-ietf-an… Brian E Carpenter