On 29-Oct-21 14:19, Liyizhou wrote:
Hi Brian,
I gave a second thoughts on using the unsolicited sync.
I agree with your TCP/UDP comments. So I think the conveying message of
mapping info can be changed to rapid mode of discovery instead.
That's efficient and simple. And also removes the requirement of state
maintenance.
I am also thinking to add a "role" parameter to distinguish the info provider
and consumer.
Good idea. I like Toerless's idea of using a JSON-like dictionary for complicated objectives, since
it makes it very easy to add features like "role". I used that idea in
draft-carpenter-anima-grasp-config-00 and when you understand it, it is quite powerful. (It's very
natural to use in "modern" programming languages, but a bit tricky in plain C.)
Brian
Hope that works.
Thanks,
Yizhou
-----Original Message-----
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Thursday, October 28, 2021 11:08 AM
To: Liyizhou <liyiz...@huawei.com>; duzongp...@foxmail.com; anima@ietf.org
Cc: Xun Xiao <xun.x...@huawei.com>
Subject: Re: [Anima] unsolicited synchronizaiton in
draft-yizhou-anima-ip-to-access-control-groups-01.txt
unicast unsolicited sync would be still useful in distributing the mapping info.
I understand the requirement, my comment is simply that this is undefined.
GRASP synch is a discover/request/response/close sequence. As I understand
unsolicited synch, it is discover/request/response...response...response...
That means keeping a TCP connection open indefinitely, and keeping
corresponding connection state at each end indefinitely.
Alternatively, it would mean designing a way to use UDP unicast for this, but
there must still be state at both ends, indefinitely.
I never wanted to make GRASP synch or negotiation use UDP, because each
time I tried to design an implementation, I found that I had to create state at
both ends to make the UDP session work properly - in effect, much of the work
that TCP does anyway. So I think the way to implement unsolicited synch is
probably to use TCP.
Regards
Brian
On 27-Oct-21 15:27, Liyizhou wrote:
Hi Brian,
I do not really intended to use a generic pub/sub mechanism, though it
would work if it is there.
I explained a little bit more in the email to Zongpeng that how it works with
unsolicited synchronization without pub/sub objectives.
If I understand your previous email correctly, you talked about
pub/sub
functionalities to be implemented with (unsolicited synchronization msg
+ pub/sub objectives) are not ready to be used right now.
I kind of think the co-authors of that draft will be keeping working
on
pub/sub functions.
But at the same time, even without a full functional pub/sub, a
unicast
unsolicited sync would be still useful in distributing the mapping info.
The number of PEP is very limited and the purpose is not to
disseminate
the policies themselves but to inform the group mapping information. PEP can
selectively use those mapping information based on the group based policies
provisioned upfront.
Or did I misunderstand the relationship of pub/sub and unsolicited
sync
proposed in another draft?
Thanks,
Yizhou
-----Original Message-----
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: Wednesday, October 27, 2021 4:55 AM
To: duzongp...@foxmail.com; Liyizhou <liyiz...@huawei.com>;
anima@ietf.org
Cc: Xun Xiao <xun.x...@huawei.com>
Subject: Re: [Anima] unsolicited synchronizaiton in
draft-yizhou-anima-ip-to-access-control-groups-01.txt
I want to be very clear that we do not currently have a design for "unsolicited
synchronization" in GRASP that works.
https://mailarchive.ietf.org/arch/msg/anima/31UnJbFe45FZF7u_YQHtJLe9Xv
8/
Regards
Brian
On 27-Oct-21 03:04, duzongp...@foxmail.com wrote:
Hi, Yizhou
I have read the draft, and I think it is good to have a convince way to
update the policies in the network.
Also, I want to share some personal understandings here. If any
misunderstandings, please correct me. Thanks.
The AAPs need to inform the PEPs of the policies of the users by using
the GRASP. It can happen when the user logs in, logs out, or triggers some
policy changes.
Maybe the first step is that the PEPs subscribe to the policy changing
even that they are interested in. Do they send some GRASP messages to AAPs
here?
And then, if the user logs in, logs out, or triggers some policy
changes, the AAP informs the PEPs that have subscribed. GRASP is used here. Is
it a multicast?
Best Regards
Zongpeng Du
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
---------- duzongp...@foxmail.com <mailto:duzongp...@foxmail.com> &
duzongp...@chinamobile.com
*From:* Liyizhou <mailto:liyiz...@huawei.com>
*Date:* 2021-10-25 17:04
*To:* Anima@ietf.org <mailto:Anima@ietf.org>
*CC:* Xun Xiao <mailto:xun.x...@huawei.com>
*Subject:* [Anima] unsolicited synchronizaiton in
draft-yizhou-anima-ip-to-access-control-groups-01.txt
Hi all,
The Unsolicited Synchronization message (as defined in section
5.1 in draft-ietf-anima-grasp-distribution) is greatly leveraged in
this document to allow the access authentication point to pass IP to
Group mapping
info to policy enforcement point.
That would make the information retrieval more efficient
compared
to request and reply (sync) mode.
I guess a missing part is to a flag to be added to objective-flag, i.e.
objective-flag = &(
F_DISC: 0 ; valid for discovery
F_NEG: 1 ; valid for negotiation
F_SYNCH: 2
; valid for synchronization
F_NEG_DRY: 3 ; negotiation is a dry run
F_UNSLC_SYNCH: 4 ; this
is a missing line to indicate valid for unsolicited synchronization
)
Looks like the future grasp objectives would require to consider
if
they are valid for unsolicited synchronization or not.
Rgds,
Yizhou
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
