Subject: [Anima] 答复: Request for presentation

From: Chenshuanglong <[email-masked]>
Date: Tue, 3 Nov 2020 02:55:49 +0000

Hi Toerless,
    Because this draft is related to ANIMA, I would like to discuss it in the ANIMA session.
  
Regards
Shuanglong

发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2020年11月2日 23:55
收件人: Chenshuanglong <[email-masked]>
抄送: Lizhenbin <[email-masked]>; Guyunan <[email-masked]>
主题: Re: Request for presentation

Shuanglong:

You did not indicate which session you want to present in 

Cheers
    Toerless

On Mon, Nov 02, 2020 at 01:36:35PM +0000, Chenshuanglong wrote:
> Hi Toerless,
> 
> I apply for timeslot for presentation.  The information of the presentation is as follows:
> 
> Name of time slot:  draft-li-rtgwg-protocol-assisted-protocol-03
> 
> Name of draft(s) (if any, NOT REQUIRED, but usually desired ;-): draft-li-rtgwg-protocol-assisted-protocol-03
>                                  https://tools.ietf.org/html/draft-li-rtgwg-protocol-assisted-protocol-03
> Amount of time requested: 10 minutes
> 
> Presenter name(s): Shuanglong Chen
> 
> Best Regards,
> Shuanglong

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2020 16:27:53 +1300

Hi,

I don't really understand why you might need a new protocol for this. It sounds like a very good application for the ANIMA model, and everything you describe could easily be expressed in GRASP objectives (synchronization or negotiation are both covered). You discuss this in Section 7.

On one specific point:

>    PAP uses UDP as its transport protocol, which is connectionless.  The
>    reason that UDP is selected over TCP is because PAP is intended for
>    on-demand communications.

I don't understand that argument. In either case you need a listener, whether it's listening for a new TCP connection or a new UDP session. Actually it's a lot more work, in my experience, to write a UDP server because it has to do a lot of housekeeping that TCP does for you. I started designing a GRASP implementation over UDP but decided that it would not in reality be more efficient than TCP, because it would need extra logic at the upper layer to manage session state.

Also of course TCP gives you TLS, which I suspect is a lot easier in practice than DTLS. However, if you use the ANIMA infrastructure you get a full security solution without any extra work.

Regards
   Brian Carpenter

On 03-Nov-20 15:55, Chenshuanglong wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Chenshuanglong <[email-masked]>
Date: Tue, 3 Nov 2020 11:22:33 +0000

Hi
    Thanks for your feedback. This is the design before PAP Draft 02. I didn't notice that there was a GRASP protocol.
Therefore, we submitted draft 03 and wanted to get the comments from ANIMA. Whether the use cases and ideas mentioned in the PAP can be extended on the GRASP.

Regards
Shuanglong

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, November 3, 2020 11:28 AM
To: Chenshuanglong <[email-masked]>; [email-masked]; [email-masked]
Cc: Lizhenbin <[email-masked]>; [email-masked]; Guyunan <[email-masked]>
Subject: Re: [Anima] 答复: Request for presentation

Hi,

Regards
   Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2020 11:24:21 -0500

I've only very briefly scanned
   https://tools.ietf.org/html/draft-li-rtgwg-protocol-assisted-protocol-03

Brian E Carpenter <[email-masked]> wrote:
    > I don't really understand why you might need a new protocol for
    > this. It sounds like a very good application for the ANIMA model, and
    > everything you describe could easily be expressed in GRASP objectives
    > (synchronization or negotiation are both covered). You discuss this in
    > Section 7.

I'd split this up in three points:

1) It seems like a very good use for the ACP.
   If you are debugging a protocol problem, then you likely have some part of
   the network that has reachability issues.

2) I think that the ACP eliminates the need for PAP to be peer to peer, or
   for it to be UDP.
   It should be between the NOC and the router, not between routers.

3) GRASP CLEARLY has a place in discovering the routers which speak this
   protocol, and/or in having the routers discover the PAP collector in the NOC.

Whether or not GRASP is the right way to transfer the data itself, I'm not
sure.  I'm unclear if access to the raw routing protocol frames (OSPF, BGP,
etc.) is desired, or if some higher-level debug is envisioned.

If raw protocol, then it seems like a span/mirror/ functionality using IPFIX
or PCAPNG [over ACP] would be appropriate.

If you want higher-level diagnostics, then I would use RESTCONF and YANG.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Nov 2020 08:58:42 +1300

> etc.) is desired, or if some higher-level debug is envisioned.

Yes. GRASP could be used for the discovery and to set up communication,
even if the actual communication uses something else. In any case, using the
ACP for secure transport seems obvious.

(By the way, I did experimentally add a raw send() recv() pair to GRASP,
so that it could be used as a clear channel after discovery. That isn't
in the GRASP spec but it is in my code.)