Subject: [Anima] New Version Notification for draft-dang-anima-network-service-auto-deployment-00.txt

From: Dangjuanna <[email-masked]>
Date: Wed, 7 Jul 2021 15:41:24 +0000

Hi All,

A new version of I-D, draft-dang-anima-network-service-auto-deployment-00.txt
has been successfully submitted.

Name:		draft-dang-anima-network-service-auto-deployment
Revision:	00
Title:		An Auto-deployment Mechanism for Resource-based Network Services
Document date:	2021-07-07
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/archive/id/draft-dang-anima-network-service-auto-deployment-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dang-anima-network-service-auto-deployment/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dang-anima-network-service-auto-deployment

Abstract:
   This document specifies an auto-deployment mechanism that deploys
   resource-based network services through the Autonomic Control Plane
   (ACP) in an Autonomic Network.  This mechanism uses the GRASP in
   [RFC8990] to exchange the information among the autonomic nodes so
   that the resource among the service path can be coordinated.

 Welcome to comment, review or contribute it.

Best wishes,
Joanna

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jul 2021 14:19:51 -0400

> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dang-anima-network-service-auto-deployment

An interesting read, and a really useful ACP application.

Comments/nits: can you expand ASBR, UPE and PE the first time they are used,
Move the digram from section 4 to section 3.

section 4 questions:

1) do the ANS message flow over the ACP?  I assume so.

2) "The specific configuration command lines are
    not in the scope of this document."

section 5:
   objective-name = EX10

I think you want to do an IANA Action here to define your own?
EX10 is just... an example.

service-identification-type --- 3-bits. I don't think you need to be so
frugal in your use of bits.  That could just be a CBOR Int.
path-identification-value, resource-type, same comment.

8.  Security Considerations
   It complies with GRASP security consideration.

You probably mean to say that it uses the security provided by the ACP.

I think that I'm missing some parts of the flow here.
I think that things would start with a NOC device ("SDN Controller")
sending out an M_DISCOVERY or M_FLOOD to discover the SPE node.
(Maybe it already knows, and if so, then how?)

This would have some kind of filter to say, "Answer if you are the resource
that is on edge of the AS and has a route to Network-Service-Initiator"
(which probably needs a label).
well, that might not be exactly the right thing, but the point being is that
these node*s* need to be found. There may be more than one!

Then the ANS communication would occur with that discovered node.
It would, as you say, negotiate the path.

I don't know [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls] that well,
but I didn't think that they included on-path (RSVP-like) discovery of route.
Probably, I've missed something.

Or do the P and PE node also need to respond and also be configured?

    > _______________________________________________
    > Anima mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/anima

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

---

From: Dangjuanna <[email-masked]>
Date: Thu, 8 Jul 2021 03:20:01 +0000

Hi Micheal,

Please see below.

Best,
Joanna

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 2021年7月8日 2:20
To: Dangjuanna <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] New Version Notification for draft-dang-anima-network-service-auto-deployment-00.txt

Comments/nits: can you expand ASBR, UPE and PE the first time they are used, Move the digram from section 4 to section 3.
[JD] I agree with you and it will be updated. 

section 4 questions:

1) do the ANS message flow over the ACP?  I assume so.
[JD] Correct. ACP of the autonomic node send or receive the ANS message. I was a little hesitant to use the SPE and UPE names when writing, so the text was a little confusing. I suggest that the SPE and UPE be unified as an SPE in the future because it is a single device on the network. Do you think it is OK?

section 5:
   objective-name = EX10

>[JD]Yes, the new objective-name for network service deployment need to be defined and added. EX10 is only one example :) 

service-identification-type --- 3-bits. I don't think you need to be so frugal in your use of bits.  That could just be a CBOR Int.
path-identification-value, resource-type, same comment.
>[JD] Could you help me modify them according to your understanding? 

> [JD]Yes, do you think whether it is enough?

I think that I'm missing some parts of the flow here.
I think that things would start with a NOC device ("SDN Controller") sending out an M_DISCOVERY or M_FLOOD to discover the SPE node.
(Maybe it already knows, and if so, then how?)

This would have some kind of filter to say, "Answer if you are the resource that is on edge of the AS and has a route to Network-Service-Initiator"
(which probably needs a label).
well, that might not be exactly the right thing, but the point being is that these node*s* need to be found. There may be more than one!

> [JD] Correct, this process is necessary in the entire program. But in the network service auto-deployment scenario, this discovery mechanism has not been changed, so I did not emphasize it in the text. Where do you think it is more appropriate to add it?

I don't know [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls] that well, but I didn't think that they included on-path (RSVP-like) discovery of route.
Probably, I've missed something.
> [JD] The routing protocol can advertise routes and calculate the optimal route, which I understand should be regarded as a route discovery process. I also would like to hear more of your thoughts on this point.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jul 2021 12:36:27 -0400

Dangjuanna <[email-masked]> wrote:
    mcr> 1) do the ANS message flow over the ACP?  I assume so.
    JD> Correct. ACP of the autonomic node send or receive the ANS message. I
    JD> was a little hesitant to use the SPE and UPE names when writing, so
    JD> the text was a little confusing. I suggest that the SPE and UPE be
    JD> unified as an SPE in the future because it is a single device on the
    JD> network. Do you think it is OK?

I don't know if you should combine SPE/UPE/PE.  I don't know enough about
this area of traffic engineering.

    mcr> I think you want to do an IANA Action here to define your own?
    mcr> EX10 is just... an example.
    JD> Yes, the new objective-name for network service deployment need to be
    JD> defined and added. EX10 is only one example :)

I suggest you pick a name, and put it into the IANA considerations.

    > path-identification-value, resource-type, same comment.

    JD> Could you help me modify them according to your understanding?

Probably, just don't be so specific about the values.
I think that "object-value" can be any amount of CDDL that want to write.
You could use a map for "service-identification"

Since it's all encoded in CBOR, you can't have a 3-bit value, only a 1-byte value.

    > You probably mean to say that it uses the security provided by the ACP.
    JD> Yes, do you think whether it is enough?

Yes, I think it is, but you need to say so, and explain what threads there
are, and why the ACP provides an acceptable solution.

    > It would, as you say, negotiate the path.

    JD> Correct, this process is necessary in the entire program. But in the
    JD> network service auto-deployment scenario, this discovery mechanism
    JD> has not been changed, so I did not emphasize it in the text. Where do
    JD> you think it is more appropriate to add it?

I think that you need to explain more of it.

    > I don't know [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls] that
    > well, but I didn't think that they included on-path (RSVP-like)
    > discovery of route.

    JD> The routing protocol can advertise routes and calculate the optimal
    JD> route, which I understand should be regarded as a route discovery
    JD> process. I also would like to hear more of your thoughts on this
    JD> point.

I don't have the background in traffic engineering to know.

---

From: Dangjuanna <[email-masked]>
Date: Mon, 12 Jul 2021 14:54:12 +0000

Hi Michael,

Please see the below.

Best wishes,
Joanna
-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: Friday, July 9, 2021 12:36 AM
To: Dangjuanna <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Anima] New Version Notification for draft-dang-anima-network-service-auto-deployment-00.txt

I don't know if you should combine SPE/UPE/PE.  I don't know enough about this area of traffic engineering.

I suggest you pick a name, and put it into the IANA considerations.
[JD] I fully agree with you.

[JD] I need to learn this definition. Hopefully, I'll understand in a few days.

Yes, I think it is, but you need to say so, and explain what threads there are, and why the ACP provides an acceptable solution.
[JD] I thought it was relatively simple. This scenario requires the GRASP protocol.  The security risks are mainly in the channels between autonomic nodes.

I think that you need to explain more of it.
[JD] I try to write more about it.

---

From: Dangjuanna <[email-masked]>
Date: Fri, 23 Jul 2021 03:39:08 +0000

Hi Micheal,

>Since it's all encoded in CBOR, you can't have a 3-bit value, only a 1-byte value.

A New GRASP Objective Option as an example is defined as follows, according to draft-ietf-anima-asa-guidelines-01.
- name: s-deployment-value, which is need to be assigned by IANA registration
- objective-flag: F_DISC and F_SYNCH
- objective-value: a data structure as follows
  -- s-identification, which is used to distinguish different network services
  -- s-deployment-type, which indicates that it is new, or updated, or deleted
  -- s-resource-information, which are the assured resources of the network service.
    -- resource-type, which indicate bandwidth, or latency, etc.
    -- resource-value, which indicate the value.
  -- s-deployment-status, which indicate deployment success or failure, and the reason for the failure

Do you think it is available?

Best wishes,
Joanna

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Dangjuanna
Sent: 2021年7月12日 22:54
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Anima] New Version Notification for draft-dang-anima-network-service-auto-deployment-00.txt

Hi Michael,

Please see the below.

Best wishes,
Joanna

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Jul 2021 08:46:22 -0400

Dangjuanna <[email-masked]> wrote:
    > A New GRASP Objective Option as an example is defined as follows,

...
    > Do you think it is available?

You just need to put this kind of thing (with answers) into your IANA
Considerations section, and when your document advances it will be allocated.
You can also ask for early allocation if you are trying to do interop.

RFC8994 and RFC8994 do GRASP Objective allocations, you could use that as
your template.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dangjuanna <[email-masked]>
Date: Tue, 27 Jul 2021 09:19:54 +0000

Hi,

Thanks for your kind reminder and suggestion. 

I have studied GRASP Objective allocations in RFC8994 which is very helpful for me.

The GRASP objective between Network Initiator and SPE is an example as follows.

The formal definition of the objective in CDDL (see "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures" [RFC8610]) is as follows:
discovery-message = [M_DISCOVERY, session-id, initiator, objective]
response-message = [M_RESPONSE, session-id, initiator, ttl,
                         (+locator-option // divert-option), ?objective]
request-negotiation-message = [M_REQ_NEG, session-id, initiator, objective]
negotiation-message = [M_NEGOTIATE, session-id, objective]

objective = ["xxxx-s", objective-flags, loop-count, objective-value]
objective-name = "xxxx-s"           ; Assigned by IANA registration
objective-flags = (F_DISC and F_NEG)  ; As in [RFC8990].
loop-count = ?                    ; TBD
objective-value = [s-identification, s-deployment-type, s-resource-information]
s-identification       ; Distinguish different network services
s-deployment-type    ; Indicating that it is new, or updated, or deleted
s-resource-information ; Assured resources of the network service.

s-resource-information = [[resource-type, resource-value], [resource-type, resource-value], ...] ; One message may include one or multiple resource information
resource-type        ; Indicating bandwidth type, or latency type, etc.
resource-value       ; Indicating the value

About IANA Considerations, I will try to apply it.

Best wishes,
Joanna

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: 2021年7月23日 20:46
To: Dangjuanna <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] New Version Notification for draft-dang-anima-network-service-auto-deployment-00.txt

...
    > Do you think it is available?

You just need to put this kind of thing (with answers) into your IANA Considerations section, and when your document advances it will be allocated.
You can also ask for early allocation if you are trying to do interop.

RFC8994 and RFC8994 do GRASP Objective allocations, you could use that as your template.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-