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. Hope that works. Thanks, Yizhou -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Brian E Carpenter Sent: Thursday, October 28, 2021 11:08 AM To: Liyizhou <[email protected]>; [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 > 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_YQHtJLe9Xv > 8/ > > 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
