Hi Brian,
I am very grateful for the GRASP tutorial that you gave me. It solved a
lot of my misunderstandings.
According your suggestion, I think a GRASP flood is sufficient. The
object data we design in the draft is not very large. I think 2kB is enough and
it will not be sent very frequently. I will add this part in the new version.
I have some confusion about GRASP and hope you help me. RFC8990 defined
GRASP does not currently support selective distribution when they use GRASP
flooding message. But in my draft, SI and APE are kind of ASA, when the
negotiation process are succeed, APE should send message to other ASAs in the
network not include SI. How can we deal this situation?
Furthermore, If the negotiated ASA belong to different domain, will the
GRASP flooding message of one ASA be sent to the other ASA which is not in a
same domain? Do we need to make some mechanisms to prevent flooding message
spreading to other domains?
Best Regards
Yujing Zhou
-----Original Message-----
From: Brian E Carpenter <[email protected]>
Sent: 2021年10月28日 10:54
To: zhouyujing (A) <[email protected]>; [email protected];
[email protected]
Subject: Re: [Anima] Discussion regarding
draft-dang-anima-network-service-auto-deployment
How big is the data likely to be, and what is the approximate rate of refreshes?
If these values are low (e.g. 2 kB data once per minute), a GRASP flood would
be sufficient.
If you want an acknowledgment, a flood is not suitable. GRASP synch is
acknowledged implicitly by TCP. If you want any information beyond "I got it"
you need GRASP negotiation (only one step of negotiation in each direction).
I put some logic flows in the GRASP tutorial that should explain this.
https://tinyurl.com/Gtut2021
Regards
Brian
On 28-Oct-21 15:01, zhouyujing (A) wrote:
> Hi, Zongpeng
>
> I prefer the second method, because I think distributed is a
> feature of ASA. So an ASA should synchronize the information it receives to
> other ASAs. But I'm not sure that it is necessary for other ASAs need
> response this synchronization message. Whether to send a flooding message is
> OK?
>
> In my think, this draft pay attention to the negotiation
> between SI to APE. And how to reservate resource hop-by-hop is not we discuss
> in this draft.
>
> Best Regards
>
> Yujing Zhou
>
> *From:* [email protected] <[email protected]>
> *Sent:* 2021年10月26日 23:31
> *To:* zhouyujing (A) <[email protected]>; [email protected]
> *Subject:* Re: [Anima] Discussion regarding
> draft-dang-anima-network-service-auto-deployment
>
> Hi, Yujing
>
> Some personal understandings are listed here. If any misunderstandings,
> please correct me. Thanks.
>
>
> Just like the two mechanisms existed, we can use a hop-by-hop method or
> a centralized method.
>
>
> The first method looks like the RSVP-TE. The APE can send a "PATH"
> message including the whole path. Whenever an intermediate node can not
> provide the resource, the auto deployment is failed and some errors are
> reported.
> The DPE needs to respond a "RESV" message.
>
>
> The second method looks like the PCE-CC. The APE sends a request message
> to each node on the path. Only if all the responses are ok, the auto
> deployment succeeds.
>
>
>
> Best Regards
>
> Zongpeng Du
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> [email protected] <mailto:[email protected]> &
> [email protected] <mailto:[email protected]>
>
> *From:*zhouyujing (A) <mailto:[email protected]>
>
> *Date:* 2021-10-21 14:31
>
> *To:*[email protected] <mailto:[email protected]>
>
> *Subject:* [Anima] Discussion regarding
> draft-dang-anima-network-service-auto-deployment
>
> Hi,
>
> Our discussion in the previous mailing list basically focused on the
> definition of GRASP and we modified the objective based on the feedback. The
> related draft is listed in
> https://datatracker.ietf.org/doc/draft-dang-anima-network-service-auto-deployment/
>
> <https://datatracker.ietf.org/doc/draft-dang-anima-network-service-auto-deployment/>
>
> The draft want to build a general solution for resource-based network
> services auto-deployment. So I think is a useful work for ANIMA. But in the
> draft, I'm not sure some questions about process part and hope to get your
> help.
>
> * If the SI accepting the negotiation, APE will receive this message. How
> can APE tell other ASAs to remove the acceptable resource from there resource
> pool? It is enough to re-use GRASP Flooding message.
>
> * When the SI and APE is negotiating the resource, should APE need to
> tell other ASAs reserve this resource? If two SIs request resources at
the same time, this may cause a conflict.
>
> * Is it necessary to establish an auto-deployment mechanism to release or
> increase resources when the SI change its need?
>
> For the above question, I want to start a discussion to help the draft
> more clarified about this part. So I specially write this email.
>
> I hope to listen your opinions, and am looking forward to your reply.
>
> Best wishes,
>
> Yujing
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
