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:[email protected]] On Behalf Of Brian E Carpenter
Sent: Wednesday, October 27, 2021 4:55 AM
To: [email protected]; Liyizhou <[email protected]>; [email protected]
Cc: Xun Xiao <[email protected]>
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_YQHtJLe9Xv8/
Regards
Brian
On 27-Oct-21 03:04, [email protected] 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
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
---------- [email protected] <mailto:[email protected]> &
[email protected]
*From:* Liyizhou <mailto:[email protected]>
*Date:* 2021-10-25 17:04
*To:* [email protected] <mailto:[email protected]>
*CC:* Xun Xiao <mailto:[email protected]>
*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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
