Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt

Brian E Carpenter <> Mon, 16 December 2019 04:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 329F01200C5 for <>; Sun, 15 Dec 2019 20:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uTLzHNulxB0E for <>; Sun, 15 Dec 2019 20:20:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 932841200B4 for <>; Sun, 15 Dec 2019 20:20:48 -0800 (PST)
Received: by with SMTP id b9so2883944pgk.12 for <>; Sun, 15 Dec 2019 20:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RjnfPQMiz2/EoE91ABQgBFIrQ06oJ2TipLl2+Phcl0g=; b=mYUKQkPJq0ycWQLOCxC/KTLe4vyGvKXkzzpDIzbk+zFKdFzt7am6Hm7pjRrOsdR9+0 sED0CK7vE5Bg+1Lb3lTxH2SyYJ50zXK3zZ3b6xaKPkOnoqIYzyIAyacSkYqodeb48N0G KXSRpyoGjgh5ZAOriZ1zQl8bip2GAlchXx3+xJNHpcaylQx7q8pS5ZW9+F3xDo6tOzyg My+H2zVjYCEyHCzK2szyVS2jix76pt9p+Bsgzlmz5FAYNqg4lmpoCkjbnUrhplXm/kyJ 27nudfYuXk0gp/kWKt2Rn5YRf3c2JPM/exLpBVEJeDdP8ET7bjUmh0RgVbZlGWSw+Sb5 VdAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RjnfPQMiz2/EoE91ABQgBFIrQ06oJ2TipLl2+Phcl0g=; b=byyACTFFUPYGNYCdz9gIoUThWT1J9Ll/HeF1Yu+qH6SpO2vYsa3iveXO7k/PEijHxX 1AGVUeEDL1rkIYbbnrNBZ9Zd3uOI1ex0EoAMHM0c74XcS1+4BDNswmm7yfCGiH2+s4ZB xSHXTeCDq+cfORQWxD1eyGBgmpin2E1YnThemNtevxiAWptDhgVnuBL3NpNZT7f96lfe cbwi/7AqC8M1F5nCNF2tI9fO1IkSH9CxMIfDDM4Zy7qY5rwmqlJ26Awo6Ketfji9+Lq9 Hi5M93yawfo6P0S1D3pFwtxniXMDW0tbL9sWh6TbZzfsLcFxSXI7aSWqNdU4Q6SFed4z wXBA==
X-Gm-Message-State: APjAAAUWXJSnrdah/KNnrTtpXGBegI9oRXcKydrHvOVwFLTIehk1nT1g ZmnOAPlJG0wJTBSxmqNU2ZGGh9El
X-Google-Smtp-Source: APXvYqwtWRlWZcrtETcUZ9Nu2+FjWEwquxtL6Ekx57/iw9X2zI0UpElQ6+8Q4LO1vCh5zxCyUUQ+FQ==
X-Received: by 2002:a63:6fca:: with SMTP id k193mr16289048pgc.416.1576470047680; Sun, 15 Dec 2019 20:20:47 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ev11sm17639579pjb.1.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Dec 2019 20:20:47 -0800 (PST)
References: <>
From: Brian E Carpenter <>
To: Anima WG <>
Message-ID: <>
Date: Mon, 16 Dec 2019 17:20:45 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Dec 2019 04:20:50 -0000


I think this is a useful extension of the basic autonomic infrastructure. Here are some comments and questions on the GRASP part of the draft. I'd be interested in the authors' comments.

> 5.1 Realizing Instant P2P Transmission
>    This could be a new message in GRASP. In fragmentary CDDL, an Un-
>    solicited Synchronization message follows the pattern:
>       unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id,
>       objective]

I suggest simply calling this M_PUSH (but see later comments).

>    A node MAY actively send a unicast Un-solicited Synchronization
>    message with the Synchronization data, to another node. This MAY be
>    sent to port GRASP_LISTEN_PORT at the destination address, 

That port is normally tied up with multicast reception. But since we have a SUBSCRIBE mechanism below, the question of the port can be resolved at SUBSCRIBE time. There must be a listener process for this port, of course.

>    which
>    might be obtained by GRASP Discovery or other possible ways. The
>    synchronization data are in the form of GRASP Option(s) for specific
>    synchronization objective(s).

One objective per message is much simpler to implement. If not, this becomes more like a "unicast Flood". If you want that, we could define the syntax precisely like M_FLOOD.

> 5.2 Realizing Instant Selective Flooding
>    Since normal flooding is already supported by GRASP, this section
>    only defines the selective flooding extension.
>    The action means, when the match rule applies, the current device
>    just continues flood or discontinues.

Please remember that a normal M_FLOOD has two aspects for a node that receives it. First, the node stores the objectives delivered in its own flood cache. Second, *if* it is a relay node (with interfaces to more than one link within the AN, such as a router) it relays a copy of the M_FLOOD to its AN neighbors, subject to anti-looping rules.

1) If the result of the match is "continue" I assume that the node does exactly what it does with a normal flood, i.e. caches the received objectives and if it is a relay, it relays the flood to its neighbors.

2) If result of the match is "discontinue" I assume the node does not cache the flooded objectives.

2) If result of the match is "discontinue" and the node is also a GRASP relay, what does the node do? Discard or relay? It cannot know the result of the match in its neighbors.

I really don't understand the meaning of the matching rules, especially "match-object = NEIGHBOR / SELF". I think this needs a lot more explanation and some more detailed examples.

> 5.3 Realizing Subscription as An Event
>    In fragmentary CDDL, a Subscription Objective Option follows the
>    pattern:
>          subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj]
>          objective-name = SUBSCRIPTION
>          objective-flags = 2
>          loop-count = 2
>          subobj = text
>    This option MAY be included in GRASP M_Synchronization, when
>    included, it means this message is for a subscription to a specific
>    object.

The M_SYNCH message is the reply from a data source to a data destination, so I think that's wrong. I think that SUBSCRIPTION should  be used in M_REQ_SYN, when a node first wants to get the value of a given objective but also wants to subscribe to future push updates. So the reply to a M_REQ_SYN with a SUBSCRIPTION option would be M_SYNCH with an initial value for the objective, but the session could stay open with M_PUSH to follow at any time. (So that solves the question of the port: whatever port is used for sending the M_REQ_SYN listens for the M_PUSH messages.)

A new M_REQ_SYN would also be used to carry UNSUBSCRIBE. Alternatively, the node could simply close the port and the next M_PUSH would fail. If we did that, UNSUBSCRIBE would not be needed.

Finally do we actually need M_PUSH, rather than just sending M_SYNCH again whenever needed?

> 5.5 Publishing Objective Option
>    In fragmentary CDDL, a Publish Objective Option follows the pattern:
>       publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name
>       = PUBLISH
>       objective-flags = 2
>       loop-count = 2
>       pubobj = text
>    This option MAY be included in GRASP M_Synchronization, when
>    included, it means this message is for a publish of a specific object
>    data.

I don't understand this. An M_SYNCH by definition delivers the current value of an objective. Why do we need to say that we're publishing it?

   Brian Carpenter