[Anima] Re: draft-ietf-anima-network-service-auto-deployment-06 comments

[Sheng JIANG <[e-mail]>]

Hi, Toerless,

Thanks for your further suggestion. It is fair to have a specific resource
deployment as a proof example alongside the framework document. Storage
could be one. Actually, I am thinking computing resource may be even more
straight forward as the newly merged resource have not been explored a lot.
I will talk around to my friends in carriers and vendors to find some people
who are interested to work on this with me. Meanwhile, I will try to
modified the current document towards an informational framework/guidance
document. By the way, I guess our prefix management could also be an example
if we take prefix availability as a type of network resource.

Cheers,

Sheng

> -----Original Message-----
> From: [e-mail] <[e-mail]> On
> Behalf Of 'Toerless Eckert'
> Sent: Wednesday, May 15, 2024 12:05 AM
> To: Sheng JIANG <[e-mail]>
> Cc: [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Anima] draft-ietf-anima-network-service-auto-deployment-06
> comments
> 
> Sheng,
> 
> I think it would be good to create a well received proof point for one
type of
> resource first - for example RAM or storage. These two are also services
where
> we might approach COINRG and/or NFSv4 WG to get feedback,
> e.g.: ask for a slot to ask what they think.
> 
> Ultimetely, in the IETF, the hard job is always to find the lowest hanging
> practical fruit that someone actually would want to implement. Finding,
> selecting and aquiring/releasing some resources like this might be one
such low
> hanging fruit - but we will only know if/when we talk to folks who are
closer to
> those use-cases than i think we are right now.
> 
> The path based stuff would IMHO require for someone with a lot more TEAS
> involvement to help/be-interested. Otherwise i fear we'd be faced with the
> challenge of explaining how the work relates to TEAS, and we likely
wouldn't
> have a good answer withou doing such an engagement.
> 
> Cheers
>     Toerless
> 
> On Sat, May 04, 2024 at 08:31:20AM +0800, Sheng JIANG wrote:
> > Hi, Toerless,
> >
> > Thanks so much for this great comments. It is very valuable and
> > constructive. This draft was initiated by end-to-end deterministic
> > forwarding service. I was too ambitious to make it generic, even I
> > knew generic was very difficult. Later, we got lost between the
> > specific use case and a generic mechanism. We got further lost when it
came
> to path-oriented.
> > It is a lot more complicated using node-by-node negotiation mechanism
> > to make up a multiple-node path-oriented mechanism than a single-round
> > path-through mechanism.
> >
> > Actually, like we mentioned, there is a lot network resources that can
> > make up various services. Therefore, these seems to be worth a series
> > of documents. And beyond the potential documents each focuses on a
> > specific solution, there should be an informational framework
> > document. It could be the direction to modify this document, if
> > agreed. This would be feasible with minimum modification in an
> > acceptable timeline, I think. Another specific-resource document,
> > which had better not be path-oriented, should be also started as an use
case
> of such framework.
> >
> > How do you think?
> >
> > Best regards,
> >
> > Sheng
> >
> > > -----Original Message-----
> > > From: Anima <[e-mail]> On Behalf Of Toerless Eckert
> > > Sent: Thursday, May 2, 2024 11:21 PM
> > > To: [e-mail];
> > > [e-mail]
> > > Cc: [e-mail]
> > > Subject: [Anima] draft-ietf-anima-network-service-auto-deployment-06
> > > comments
> > >
> > > Dear Authors
> > >
> > > Thank you for this work. The document sounds and currently intends
> > > to
> > target
> > > a full standard specification for arbitrary services management via
GRASP.
> > I
> > > think this is an unattainable goal. What i think is attainable is to
> > outline how to
> > > build such GRASP based signaling specifications, and for that the
> > > document
> > has
> > > good starting text, but it does not really well focus on that in
> > comparison to e.g.:
> > > pre-existing methods.
> > >
> > > If the resource is located on a single GRASP speaking node, such as
> > > maybe storage, compute or memory, this is easy to imagine:
> > >
> > > - One needs to figure out what the type of resource and the specific
> > >   resource attributes are.
> > >
> > > - One needs to figure out how to define objectives to find server
nodes
> > >   that meet those resource attirbute needs - aka: memory of a
> > > certain minimum
> > >   size, and for example minimum speed, with or without persistance,
etc.
> > pp
> > >
> > > - One then needs to define the GRASP objectives to request/negotiate
and
> > >   re-negotiate such a service consumption request.
> > >
> > > - Finally, one has to define the GRASP objectives to consume such a
> > resource,
> > >   e.g. read/write actual memory. I guess this part is not necessarily
part
> > >   of the intended scope of this draft, but could use other
pre-existing
> > >   protocols, but it would help a lot of listing all thise bullet
> > > points
> > and
> > >   pointing this out explicitly.
> > >
> > > The draft has some of these aspects covered, but it seems very
> > > incomplete
> > and
> > > in parts confusing. Primarily also because it simply enumerates a
> > > long
> > list of
> > > possible resources in section 8.2, but does not provide enough
> > specification to
> > > actually implement in GRASP any single such resource management
> > > solution, because there are no mentioning of relevant attributes to
> > > show where GRASP could be better than existing mechanisms.
> > >
> > > More problematic though is the implication that this draft can
> > > support
> > resource
> > > management like RSVP, aka: services for path properties. But then it
> > > does
> > not
> > > explain how the resource management would work when like for a path,
> > > it requires allocation of resources from multiple nodes together. Is
> > > there
> > some
> > > on-path signaling like in RSVP, NSIS ? Is there a central controller ?
> > Does it
> > > require some fixed path ? What happens when the path changes ? etc.
pp.
> > >
> > > And unlike compute, storage, memory resources, path resource
> > > management has a tremendous number of RFCs specifying thousands of
> > > details - around
> > TE,
> > > RSVP, RSVP-TE, PCE, Netconf/YANG and so on. And there is no
> > > comparison or even specific claims of why this GRASP approach would
> > > be beneficial for
> > any
> > > scenario in which these existing solutions work or where it is
> > > understood
> > that
> > > they could be adopted to.
> > >
> > > So, i think it would be very useful to discuss primarily the
> > > intended
> > scope of the
> > > document before going into further details of the text.
> > >
> > > For example, i think it would be very helpful to constrain the scope
> > single-node
> > > resource management and discuss the path resource
> > > issues/complexities only in an appendix like section, pointing to
> > > the variety of existing protocols
> > from
> > > IETF and suggesting if any, some of the benefits the GRASP approach
> > > could have.
> > >
> > > If this makes sense, then i would also suggest to select some
> > > example
> > service
> > > and on each step of the document discuss example details of that
service.
> > >
> > > Ideally, the service in question would already have one or more
> > > existing consumption protocols and the GRASP solution could be
> > > presented as a unifying single protocol to do discovery, negotiation,
> selection.
> > Specifically
> > > highlighting, that GRASP has network-based discovery, so it can
> > > operate without the need of prior discovery servers (e.g.; no need
> > > to set up a
> > DNS-SD
> > > server or CORE-SD server for example)
> > >
> > > I am not sure what the lowest-hanging fruit for such a service would
> > > be,
> > e.g.:
> > > the type of service for which this management aspect is least well
> > supported
> > > today.
> > > I do not know a lot of details of remote memory access, but i can
> > > well
> > imagine
> > > how this mechanism could be nice for storage. On the other hand, for
> > storage,
> > > i can easily imagine a serious long list of service parameters
> > > ranging
> > from the
> > > consumption protocol (NFSv3, NFSv4, SMBv1, SMBv2, SMBv3, WebDAV,
> and
> > > a lot more), connection parameters (TCP, UDP, credentials),
> > > resilience of
> > storage,
> > > performance parameters, maximum size, cost, number of files, maximum
> > > file size, etc. pp). And storage of course would have the nice
> > > aspect that it
> > would
> > > easily allow negotiation of several of those parameters (such as
> > > maximum storage allowed, maximum through given to client, session
> > > credentials,
> > sharing
> > > of the storage across multiple clients.
> > >
> > > Aka: I think that as soon as we think of any specific service, it
> > > becomes
> > clear
> > > that this document can not be normative for even a small part of
> > > relevant
> > spec
> > > details, but can only point out how "easy" it is to use GRASP to
> > > define
> > them.
> > > Aka:
> > > include text about formal specification of the data model via CDDL,
> > > and
> > easy
> > > extensibility, etc. pp.
> > >
> > > In the end it would be good to evolve this document into one that
> > > has
> > enough
> > > details of one service so that a minium interoperable implementation
> > > could
> > be
> > > built from it. Not because this should be seen as a complete
> > specification, but
> > > only to have a prac tical enough explanation that coders can make
> > > sense of
> > it.
> > > And then highlight the benefits of GRASP, e.g.: why not use other
> > protocols:
> > >
> > > - lightweight, binary encoded, appropriate for LLN up to SP core
networks.
> > > - In-network discovery - no need to have third-party (services
> > > server) dependencies
> > > - Ability to find "closest" resource (network distance).
> > > - separated security and transport substrate - can deploy GRASP on
> > > various such substrates
> > > - CDDL formal specifications of data model
> > > - easily extensible service properties (as compared to DNS-SD TXT
> > > record limits).
> > > - negotation of consumption (not in DNS-SD, CORE-LF/CORE-SD).
> > > ...
> > >
> > > And with this scope it would make a lot more sense to make this
> > > draft
> > target
> > > informational.
> > > If this makes sense then i can provide further detail feednback
> > > after
> > you've
> > > tried to come up with a version that attempts to re-scope the
> > > document
> > this
> > > way.
> > >
> > > If you want to keep the path-properties a core goal of the document
> > > than
> > i'd
> > > have to provide more feedback for that, but i think it would be a
> > > lot more
> > work,
> > > and much less likely to get through IETF.
> > >
> > > Cheers
> > >     Toerless
> > >
> > >
> > >
> > > 2	ANIMA
> > > S. Jiang, Ed.
> > > 3	Internet-Draft
> > > BUPT
> > > 4	Intended status: Standards Track
> J.
> > > Dang
> > > 5	Expires: 4 October 2024
> > > Huawei
> > > 6
> > > Z. Du
> > > 7
> > > China Mobile
> > > 8
> > > 2 April 2024
> > >
> > > 10	 A Generic Autonomic Deployment and Management Mechanism for
> > > Resource-
> > > 11	                         based Network Services
> > > 12
draft-ietf-anima-network-service-auto-deployment-06
> > >
> > > 14	Abstract
> > >
> > > 16	   This document specifies an autonomic mechanism for
> resource-based
> > > 17	   network services deployment and management, using the
> GeneRic
> > > 18	   Autonomic Signaling Protocol (GRASP) to dynamically
exchange
> the
> > > 19	   information among the autonomic nodes.  It supports the
> > > coordination
> > > 20	   and consistently operations within an autonomic network
> domain.
> > > This
> > > 21	   mechanism is generic for most, if not all, of kinds of
network
> > > 22	   resources, although this document only defines the
process of
> > quality
> > > 23	   transmission service deployment and management.  It can
be
> easily
> > > 24	   extended to support network services deployment and
> management
> > > that
> > > 25	   is based on other types of network resources.
> > >
> > > 27	Status of This Memo
> > >
> > > 29	   This Internet-Draft is submitted in full conformance with
the
> > > 30	   provisions of BCP 78 and BCP 79.
> > >
> > > 32	   Internet-Drafts are working documents of the Internet
> Engineering
> > > 33	   Task Force (IETF).  Note that other groups may also
distribute
> > > 34	   working documents as Internet-Drafts.  The list of
current
> > Internet-
> > > 35	   Drafts is at
https://datatracker.ietf.org/drafts/current/.
> > >
> > > 37	   Internet-Drafts are draft documents valid for a maximum
of six
> > months
> > > 38	   and may be updated, replaced, or obsoleted by other
documents
> at
> > > any
> > > 39	   time.  It is inappropriate to use Internet-Drafts as
reference
> > > 40	   material or to cite them other than as "work in
progress."
> > >
> > > 42	   This Internet-Draft will expire on 4 October 2024.
> > >
> > > 44	Copyright Notice
> > >
> > > 46	   Copyright (c) 2024 IETF Trust and the persons identified
as the
> > > 47	   document authors.  All rights reserved.
> > >
> > > 49	   This document is subject to BCP 78 and the IETF Trust's
Legal
> > > 50	   Provisions Relating to IETF Documents
(https://trustee.ietf.org/
> > > 51	   license-info) in effect on the date of publication of
this
> > document.
> > > 52	   Please review these documents carefully, as they describe
your
> > rights
> > > 53	   and restrictions with respect to this document.  Code
> Components
> > > 54	   extracted from this document must include Revised BSD
License
> > text
> > > as
> > > 55	   described in Section 4.e of the Trust Legal Provisions
and are
> > > 56	   provided without warranty as described in the Revised BSD
> > License.
> > >
> > > 58	Table of Contents
> > >
> > > 60	   1.  Introduction  . . . . . . . . . . . . . . . . . . . .
. . . .
> > 2
> > > 61	   2.  Requirements Language . . . . . . . . . . . . . . . .
. . . .
> > 4
> > > 62	   3.  Terminology & Abbreviations . . . . . . . . . . . . .
. . . .
> > 4
> > > 63	   4.  A Generic Auto-deployment Mechanism of Resource-based
> > > Network
> > > 64	           Services  . . . . . . . . . . . . . . . . . . . .
. . . .
> > 5
> > > 65	     4.1.  Discover RM ASA on Proper Service Responsers  . .
. . . .
> > 6
> > > 66	     4.2.  Authentication and Authorization  . . . . . . . .
. . . .
> > 6
> > > 67	     4.3.  Negotiate Resource with Service Responser . . . .
. . . .
> > 6
> > > 68	     4.4.  Change Reserved Resources . . . . . . . . . . . .
. . . .
> > 7
> > > 69	     4.5.  Releasing Resources during Service Ending . . . .
. . . .
> > 8
> > > 70	   5.  Autonomic Resource Management Objectives  . . . . . .
. . . .
> > 8
> > > 71	   6.  Process of the Quality Network Transmission Service
> > > 72	           Auto-deployment . . . . . . . . . . . . . . . . .
. . . .
> > 10
> > > 73	     6.1.  Quality Transmission Service Scenario & Service
> Type  . .
> > > 10
> > > 74	     6.2.  Negotiation between a Service Initiator and a
Service
> > > 75	           Responser . . . . . . . . . . . . . . . . . . . .
. . . .
> > 11
> > > 76	     6.3.  Coordination among Multiple Service Responsers  .
. . . .
> > 12
> > > 77	     6.4.  Service Ending  . . . . . . . . . . . . . . . . .
. . . .
> > 12
> > > 78	   7.  Security Considerations . . . . . . . . . . . . . . .
. . . .
> > 12
> > > 79	   8.  IANA Considerations . . . . . . . . . . . . . . . . .
. . . .
> > 12
> > > 80	     8.1.  Service type  . . . . . . . . . . . . . . . . . .
. . . .
> > 13
> > > 81	     8.2.  Resource Type . . . . . . . . . . . . . . . . . .
. . . .
> > 13
> > > 82	   9.  Acknowledgements  . . . . . . . . . . . . . . . . . .
. . . .
> > 13
> > > 83	   10. References  . . . . . . . . . . . . . . . . . . . . .
. . . .
> > 13
> > > 84	     10.1.  Normative References . . . . . . . . . . . . . .
. . . .
> > 13
> > > 85	     10.2.  Informative References . . . . . . . . . . . . .
. . . .
> > 14
> > > 86	   Authors' Addresses  . . . . . . . . . . . . . . . . . . .
. . . .
> > 14
> > >
> > > 88	1.  Introduction
> > >
> > > 90	   Traditionally, IP networks are based on the best-efforts
model.
> > The
> > > 91	   IP layer does not reserve resources for upper-layer
applications.
> > >
> > >
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > ^^
> > >
> > > nit:
> > > s/IP layer/IP protocols/
> > >
> > > 92	   However, more and more emerging applications that require
> quality
> > > 93	   services, such as video, VR, AR, and so on.  They need
supports
> > from
> > > 94	   steady network resources, such as bandwidth, queue,
memory,
> > > priority,
> > > 95	   computational resources, etc.  On another side, from
network
> > side,
> > > 96	   more and more generic services, such as quality
transmission
> > > 97	   services, in-network data cache services and computing
services,
> > > 98	   etc., are starting to be deployed so that networks can
serve
> > these
> > > 99	   resource-consumption applications well.  These network
> services
> > are
> > >
> > > nit:
> > > Please provide references for "quality transmission services",
> > > "in-nework
> > data
> > > cache services", etc..
> > >
> > > 100	   strongly based on the availability and stability of
network
> > > 101	   resources.
> > >
> > > 103	   To enable these resource-based applications and services,
IETF
> > have
> > > 104	   developed many resource reservation mechanisms, such as
RSVP
> > > 105	   [RFC2205] that is mainly to reserve bandwidth only and
> > path-oriented,
> > >
> > > nit:
> > > When you say many, please cite at least one more example, ideally
> > > one most different from RSVP.
> > >
> > >
> > > 106	   etc.  However, most of them are mainly for reservation
during
> the
> > > 107	   deployment only and are rigid for dynamic adjustment.
> > > Furthermore,
> > >
> > > nit:
> > > It is unclear what other than "during the deployment only" means.
> > > Please explain in text.
> > >
> > > 108	   most of them are dedicated for a certain type of network
> > resources.
> > >
> > > 110	   This document introduces an enhanced and extensible
> mechanism
> > > that
> > > 111	   supports dynamically dispatching of network resources,
using the
> > > 112	   GeneRic Autonomic Signaling Protocol (GRASP) defined in
> [RFC8990]
> > > to
> > > 113	   dynamically exchange the information among the autonomic
> nodes.
> > > Its
> > >
> > > nit:
> > > Please explain what "enhanced" means - readers assume enhanced
> > > compared to RSVP, or any other prior mentioned example, but how ?
> > >
> > > 114	   dynamic adjust ability is mainly enabled by the
negotiation
> > ability
> > > 115	   defined by [RFC8990].
> > >
> > > 117	   This mechanism is generic for most, if not all, of kinds
of
> > network
> > >
> > > nit:
> > > Generic itself is not very specific, but generic or not generic wrt.
> > > to a
> > specific
> > > network resource is even less clear. Please explain.
> > >
> > > 118	   resources.  It can be easily extended to support network
> services
> > > 119	   deployment and management that is based on other network
> > > resources.
> > >
> > > nit:
> > > Other "network resources" than what network resource ? Please
> > > explain in text.
> > >
> > > 120	   It can be used, but no limited, in below network services
> > scenarios:
> > >
> > > 122	   *  Quality transmission services.  The quality could
means
> > > guaranteed
> > >
> > > nit:
> > > Please provide a reference or explain what "quality transmission
services"
> > > means.
> > >
> > > 123	      bandwidth, or jitter, etc.  In order guarantee the
quality of
> > > 124	      transmission services, the network should reserve
> transmission
> > > 125	      resource, particularly bandwidth or queues, on a
selected
> path
> > > 126	      from the ingress to the egress node.  The dynamic
resource
> > > 127	      dispatching mechanism should ensure the consistent of
> reserved
> > > 128	      resources on all the nodes in this path, particularly,
when
> > > 129	      dynamic changes are operated on this path.
> > >
> > > 131	   *  Difference transmission services.  The network may
provide
> > >
> > > nit:
> > > This probably should say "Differentiated Services" ?? If so, then
> > > please
> > add
> > > reference for DiffServ arch RFC, else explain or provide other
> > > reference
> > for
> > > what "Difference ... services" means.
> > >
> > > 132	      different transmission services by putting the user
packets
> > into
> > > 133	      different processes that have different resources,
such as
> > > 134	      bandwidth, queue length, priority, etc.  The results
would be
> > > 135	      different user experience in delay and jitter, or even
packet
> > lose
> > > 136	      rate.
> > >
> > > 138	   *  In network cache/storage services.  The network may
> provide
> > > cache
> > > 139	      or storage service by memory in the network devices or
> > attached
> > > 140	      devices.  The idle memory space is the resource that
need to
> > be
> > > 141	      request and managed.  The location or distance of the
> memory
> > is
> > > 142	      also relevant to user experience.
> > >
> > > nit:
> > > Please provide a reference for any such network cache/storage
> > > service and
> > any
> > > existing means to manage their resources. I can imagine such a
> > > thing, but
> > i am
> > > not aware of anything in the IETF context (CDNI for example does not
> > > seem
> > to
> > > be about managing resources, but rather content). Likewise "idle
memory"
> > > space.
> > > It is unclear to me what even a simple example of network based
> > > memory resource (idle or not) would be.
> > >
> > > 144	   *  Computing services.  More and more spare computational
> > > resources
> > > 145	      are from network providers.  They may be idle
> computational
> > > cycles
> > > 146	      on the network devices or deployed computational
servers.
> The
> > > 147	      occupation of these computational resources are
> > time-sensitive.
> > > 148	      Also, the location or distance of the computational
resource
> > is
> > > 149	      relevant to user experience.
> > >
> > > nit:
> > > Same question about providing example reference.
> > >
> > > If there are no useful referrences, then it would help to provide a
> > > simple explanation of a use-case exemplifying such a service. E.g.:
> > > for memory
> > one
> > > could think of an application that needs more memory, so it tries to
> > > get
> > it from
> > > a "memory server" and consumes it via e.g.: proprietary protocols
> > > like
> > > RoCEv2
> > > (https://www.infinibandta.org/ibta-announces-new-roce-specification/)
> > >
> > > 151	   *  Information services.  In some scenarios, network may
be
> the
> > > best
> > > 152	      information provider.  It may be the information are
from or
> > > 153	      generated by network itself.  Or the network has the
best
> > > location
> > > 154	      to provide the information.
> > >
> > > nit:
> > > reference and/or scenario.
> > >
> > > 156	   The Autonomic Control Plane (ACP) [RFC8994] and the
> Bootstrapping
> > > 157	   Remote Secure Key Infrastructure (BRSKI) [RFC8995]
provide the
> > > secure
> > > 158	   precondition for this mechanism.
> > >
> > > nit:
> > > We should always try to emphasize how the components provided by
> > > ANIMA can support each other but can also be used independently, e.g.:
> > >
> > > s/provide ..."/may provide the secure precodnitions for this
mechanism/.
> > > Nevertheless, the meachanism as presented is not dependent on them
> > > but can equally be combined with other security mechanisms that
> > > support mutual authentication between devices employing the mechanism
> proposed here.
> > >
> > > 160	   This document defines an Autonomic Resource Management
> > > Objective in
> > > 161	   Section 5.  Three new corresponding registries are
defined in
> > > 162	   Section 8.  This document defines the process of quality
> > transmission
> > > 163	   service deployment and management in Section 6.
> > >
> > > 165	2.  Requirements Language
> > >
> > > 167	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> "SHALL
> > > NOT",
> > > 168	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
> > > RECOMMENDED", "MAY", and
> > > 169	   "OPTIONAL" in this document are to be interpreted as
described
> in
> > > BCP
> > > 170	   14 [RFC2119] [RFC8174] when, and only when, they appear
in all
> > > 171	   capitals, as shown here.
> > >
> > > 173	3.  Terminology & Abbreviations
> > >
> > > 175	   This document uses terminology defined in [RFC7575].
> > >
> > > 177	   RM ASA: the Resource Manager ASA on an autonomic nodes.
It
> > > manages
> > > 178	   the local resources on the node, such as bandwidth,
queue,
> > memory,
> > > 179	   priority, computational resources, etc.  The RM ASA
> communicate
> > > with
> > > 180	   other counterpart RM ASAs in order to dynamically
dispatch
> > network
> > > 181	   resources within the autonomic network domain.  This
> document
> > > assumes
> > > 182	   all autonomic nodes have a RM ASA.
> > >
> > > 184	   Service Initiator: the autonomic node that initiates and
manages
> > a
> > > 185	   network service.  It requests and dynamically adjusts the
> > resources
> > > 186	   of this network service through its RM ASA.  Normally, a
> network
> > > 187	   service SHALL have one service initiator within an
autonomic
> > network
> > > 188	   domain.  However, multiple Service Initiators model MAY
also
> > > 189	   operational if there were good synchronous or coordinate
> > > mechanisms
> > > 190	   among them.
> > >
> > > 192	   Service Responser: the autonomic node that responses to
the
> > > requests
> > > 193	   from the Service Initiator.  It receives the requests
through its
> > RM
> > > 194	   ASA, checks or operates on its local resources, and
responds the
> > > 195	   results to the Service Initiator.  Typically, a network
service
> > MAY
> > > 196	   involve multiple Service Responser.  The consistency
among
> them
> > are
> > > 197	   the responsibility of the Service Initiator.
> > >
> > > 199	4.  A Generic Auto-deployment Mechanism of Resource-based
> Network
> > > 200	    Services
> > >
> > > 202	   This section describes the generic procedures of
autonomic
> > > deployment
> > > 203	   and management of the resource-based network services, as
> Figure1
> > > 204	   shows.  The detailed implementation or internal
algorithms of
> the
> > > 205	   Resource Manager ASAs are out of scope of this document.
> This
> > > 206	   section does not cover the specific details that depend
on
> > certain
> > > 207	   network services or certain type of network resources.
The
> > > 208	   prepositive operation that indicates the Service
Initiator to
> > start
> > > 209	   the service deployment are out of scope.  The information
or
> > > reasons
> > > 210	   that trigger the dynamic service changes are also out of
scope.
> > >
> > > 212	                   |           Node Discovery           |
> > > 213	                   |- - - - - - - - - - - - - - - - - ->|
> > > 214	            +-----------------+
+-----------------+
> > > 215	            |      RM ASA     |               |      RM
> ASA
> > > |
> > > 216	            |Service Initiator|               |Service
> Responser|
> > > 217	            +-----------------+ ASA Discovery
+-----------------+
> > > 218	                   |----------------------------------->|
> > > 219	                   |  Authentication and Authorization  |
> > > 220	                   |----------------------------------->|
> > > 221	                   |            M_RESPONSE
> |
> > > 222	                   |<-----------------------------------|
> > > 223	                   |
> |
> > > 224	                   |     Multiple rounds Negotiation    |
> > > 225	                   |<---------------------------------->|
> > > 226	                   |      on Resource Availability      |
> > > 227	                   |
> |
> > > 228	                   |               reserve the local
resource
> > > 229	                   |
> |
> > > 230	                  ...                                  ...
> > > 231	                   |   Coordination with other RM ASAs  |
> > > 232	                   |<---------------------------------->|
> > > 233	                  ...                                  ...
> > > 234	                   |           Service Ending           |
> > > 235	                   |<---------------------------------->|
> > > 236	                   |                       release
> resources
> > >
> > > 238	   Figure-1: generic procedures of autonomic deployment and
> > > management
> > >
> > > 240	4.1.  Discover RM ASA on Proper Service Responsers
> > >
> > > 242	   The Service Initiator MAY first discover the relevant
network
> > nodes
> > > 243	   according to the service setup in order to reduce the
node range
> > of
> > > 244	   sending GRASP Discovery message.  It may be all the nodes
on a
> > > giving
> > > 245	   path or nodes that have idle resource available for
giving
> > service
> > > 246	   condition, etc.  The node discover methods can be
> pre-configured,
> > > 247	   outbound discover, path detection, etc.
> > >
> > > 249	   The Service Initiator SHOULD send out a GRASP Discovery
> message
> > > that
> > > 250	   contains a Resource Manager Objective option defined in
Section
> > 5, in
> > > 251	   which the network service is described.  The Discovery
message
> > > SHOULD
> > > 252	   send to the reduced range nodes, by abovementioned
> mechanism, or
> > > all
> > > 253	   nodes within the AN domain.
> > >
> > > 255	   A RM ASA that receives the Discovery message with the
Resource
> > > 256	   Manager Objective option SHOULD check its satisfaction
against
> > the
> > > 257	   service description.  If meet, the node is a proper
Service
> > > 258	   Responser.  It SHOULD respond a GRASP Response message
> back to
> > > the
> > > 259	   Service Initiator.
> > >
> > > 261	   Defined in the section 2.5.5.1 of [RFC8990], the
Discovery
> > message
> > > 262	   MAY combine with the below negotiation process, if the
rapid
> > > 263	   negotiation function has been enabled network wide.  If
the
> rapid
> > > 264	   negotiation function has been disabled, the process would
fall
> > back
> > > 265	   to the normal discovery-only process.
> > >
> > > 267	4.2.  Authentication and Authorization
> > >
> > > 269	   In principle, any operations on resources MUST be
authorized.
> > The
> > > 270	   Service Responser SHOULD check the authentication of the
> Service
> > > 271	   Initiator and the authorization information for the
operation it
> > > 272	   requests.  This document assumes all autonomic nodes
within
> the
> > > AN
> > > 273	   domain have been authenticated and their requested
operations
> are
> > > 274	   authorized, giving the Autonomic Control Plane (ACP)
[RFC8994]
> > and
> > > 275	   the Bootstrapping Remote Secure Key Infrastructure
(BRSKI)
> > > [RFC8995]
> > > 276	   has provided the secure environment for this mechanism.
> > >
> > > 278	4.3.  Negotiate Resource with Service Responser
> > >
> > > 280	   After the discovery step, the RM ASA on the Service
Initiator
> > sends a
> > > 281	   GRASP Request message with a Resource Manager Objective
> option,
> > > in
> > > 282	   which the value of the requested resource is indicated.
> > >
> > > 284	   When the RM ASA on a Service Responser receives a
subsequent
> > > Request
> > > 285	   message, it SHOULD conduct a GRASP negotiation sequence,
> using
> > > 286	   Negotiate, Confirm Waiting, and Negotiation End messages
as
> > > 287	   appropriate.  The Negotiate messages carry a Resource
> Manager
> > > 288	   Objective option, which will indicate the resource type
and value
> > > 289	   offered to the requesting RM ASA.
> > >
> > > 291	   During the negotiation, the RM ASA on the Service
Responser will
> > > 292	   decide at each step how much resource can be offered.
That
> > > decision,
> > > 293	   and the decision to end the negotiation, are
implementation
> > choices.
> > > 294	   A resource shortage on the Service Responser may cause it
to
> > indicate
> > > 295	   the existing available value within a Resource Manager
Objective
> > > 296	   option back to the Service Initiator.  The Service
Initiator
> > might
> > > 297	   decide whether to accept the request of the resource.  If
not,
> > the RM
> > > 298	   ASA on the Service Initiator MAY terminate the
negotiation via
> > > 299	   Negotiation End messages.
> > >
> > > 301	   Upon completion of the negotiation, the Service Responser
> > reserves
> > > 302	   its local resources.  The Service Initiator may use the
> > negotiated
> > > 303	   resource after receiving synchronization message without
further
> > > 304	   messages.
> > >
> > > 306	   Normally, a network service SHALL have one service
initiator
> > within
> > > 307	   an autonomic network domain.  It is the Service
Initiator's
> > > 308	   responsibility to manage the service and coordinate among
> > multiple
> > > 309	   Service Responsers to ensure the consistent of reserved
> > resources.
> > >
> > > 311	4.4.  Change Reserved Resources
> > >
> > > 313	   After the process of automatic resource management
mechanism,
> RM
> > > ASAs
> > > 314	   are allowed to change and negotiate the resource
requirements.
> > In
> > > 315	   the lifetime of network services, there may be many
reasons that
> > the
> > > 316	   service has to be changed upon with its reserved
resources.
> > > Resource
> > > 317	   Manager ASA needs to be able to handle resource changes
in a
> > timely
> > > 318	   manner to meet service requirements.
> > >
> > > 320	   During the renegotiation process, RM ASA on the Service
Initiator
> > > 321	   resends the service's resource requirements by using
Resource
> > > Manager
> > > 322	   GRASP Objective.  RM ASA on the Service Responser
receives
> the
> > > 323	   resource negotiation message and makes the determination.
If
> the
> > > 324	   resource requirements are lower than those allocated
or/and less
> > > 325	   lifetime than previous, the Service Responser SHOULD
directly
> > confirm
> > > 326	   the information and release the excess resources.  If
more
> > resources
> > > 327	   or lifetime are required, RM ASA on the Service Responser
> SHOULD
> > > 328	   treat it as a brand-new request and make decision or
further
> > > 329	   negotiation.  The bottom line is the Service Responser
MUST
> allow
> > > the
> > > 330	   Service Initiator fall back to previous allocated
resource, both
> > on
> > > 331	   volume and lifetime.
> > >
> > > 333	   RM ASAs on the Service Responsers MUST NOT change
existing
> > > resource
> > > 334	   allocation until the new negotiation on resource changes
is
> > complete.
> > >
> > > 336	4.5.  Releasing Resources during Service Ending
> > >
> > > 338	   After the service is completed or expired, the reserved
network
> > > 339	   resources MUST be released so that network resources can
be
> used
> > > more
> > > 340	   efficiently.  If the service lifetime expires, the
Service
> > Responser
> > > 341	   MUST release its local resources and MAY send a
Synchronization
> > > 342	   message to the Service Initiator to notify the state
change of
> > its
> > > 343	   local resources.  If the Service Initiator wants to end
the
> > service
> > > 344	   before the service lifetime expires, the Service
Initiator MUST
> > send
> > > 345	   a negotiation message to the Service Responsers to
request the
> > > 346	   network resource to be changed to zero.  Upon completion
of
> the
> > > 347	   negotiation, the Service Responser releases the resources
> > occupied by
> > > 348	   the service.
> > >
> > > 350	5.  Autonomic Resource Management Objectives
> > >
> > > 352	   This section defines the GRASP technical objective
options that
> > are
> > > 353	   used to support autonomic resource management.  Resource
> > > Manager
> > > 354	   GRASP Objective allows multiple types of resources to be
> > requested
> > > 355	   simultaneously.
> > >
> > > 357	   The Resource Manager Objective option is a GRASP
Objective
> option
> > > 358	   conforming to the GRASP specification [RFC8990].  Its
name is
> > > 359	   "Resource Manager", and it carries the following data
items as
> > its
> > > 360	   value: the resource value.  Since GRASP is based on CBOR
> (Concise
> > > 361	   Binary Object Representation) [RFC8949], the format of
the
> > Resource
> > > 362	   Manager Objective option is described in the Concise Data
> > Definition
> > > 363	   Language (CDDL) [RFC8610] as follows:
> > >
> > > 365	   objective = ["Resource Manager", objective-flags,
loop-count,
> > > 366	   ?objective-value]
> > >
> > > 368	   objective-name = "Resource Manager"
> > >
> > > 370	   objective-flags = uint .bits objective-flag ; as in the
GRASP
> > > 371	   specification
> > >
> > > 373	   loop-count = 0..255 ; as in the GRASP specification
> > > 374	   The 'objective-value' field expresses the actual value of
a
> > > 375	   negotiation or synchronization objective.  So a new
> > objective-value
> > > 376	   named autonomic-network-service-value is defined for
Network
> > > Service
> > > 377	   Auto-deployment as follows.  The autonomic node can know
> that it
> > > is
> > > 378	   serving Network Service Auto-deployment according to the
> > objective-
> > > 379	   value after receiving the GRASP message.  The 'objective
value'
> > > 380	   contains two parts, one represents the information of the
service
> > > 381	   itself, and the other represents the requirements of
resources.
> > >
> > > 383	   objective-value = autonomic-network-service-value; An
> autonomic-
> > > 384	   network-service-value is defined as Figure-2.
> > >
> > > 386	    autonomic-network-service-value =
> > > 387	        [
> > > 388	         [
> > > 389	          service-type,
> > > 390	          service-id,
> > > 391	          service-lifetime,
> > > 392	          service-tag
> > > 393	          ],[
> > > 394	          *resource-requirement-pair
> > > 395	         ]
> > > 396	        ]
> > >
> > > 398	   Figure-2: Format of autonomic-network-service-value-value
> > >
> > > 400	   service-type = 0..7
> > >
> > > 402	   service-id = uint
> > >
> > > 404	   service-lifetime = 0..4294967295 ; in milliseconds
> > >
> > > 406	   service-tag = [ *service-tag-info]
> > >
> > > 408	   The combination service-type and the service-id MUST
uniquely
> > > 409	   represent a network service within the network.  The
> uniqueness
> > of
> > > 410	   the combination service-type and the service-id SHOULD be
> > > guaranteed
> > > 411	   by an allocation mechanism that is out of scope of this
document.
> > >
> > > 413	   The allocation of resources MUST specify the lifetime.
The
> > service-
> > > 414	   lifetime represents the usage time of the resources
required by
> > the
> > > 415	   service.
> > >
> > > 417	   The service-tag contains other information that describes
the
> > > 418	   service.  This information is not necessary, but will
affect the
> > > 419	   policy for RM ASA resource reservation.
> > >
> > > 421	   The resource-requirement-pair describes the resource
> requirements
> > > and
> > > 422	   it is defined as Figure-3.  Resource requirements of
different
> > types
> > > 423	   can be described in an objective option.  The Resource
Manager
> > > 424	   objective option supports multi-faceted resource
requirements
> and
> > > 425	   negotiation.  These resource requirements are all in
pairs,
> > described
> > > 426	   by resource type and resource value.
> > >
> > > 428	   resource-requirement-pair =
> > > 429	        [
> > > 430	         resource-type,
> > > 431	         resource-value
> > > 432	        ]
> > >
> > > 434	   Figure-3: Format of resource-requirement-pair
> > >
> > > 436	   resource-type = 0..7
> > >
> > > 438	   resource-value = uint
> > >
> > > 440	6.  Process of the Quality Network Transmission Service
> > > Auto-deployment
> > >
> > > 442	6.1.  Quality Transmission Service Scenario & Service Type
> > >
> > > 444	   The quality transmission service scenario is the most
important
> > > 445	   resource negotiation scenario.  In this scenario, RM ASAs
> > negotiate
> > > 446	   the resource that will affect the transmission quality.
The
> > basic
> > > 447	   resource is bandwidth and other types of resources such
as
> queue
> > can
> > > 448	   be required at the same time.
> > >
> > > 450	   The autonomic deployment and management of the quality
> > > transmission
> > > 451	   service includes the Service Initiator and the Service
Responsers
> > all
> > > 452	   have RM ASA.  The Service Initiator is the resource
demander,
> > which
> > > 453	   ensures the connection of services through negotiation
resources
> > with
> > > 454	   RM ASAs in the domain network.  Service Responsers are
the
> nodes
> > > 455	   which packets are forwarded in the transmission scenario
and
> > Service
> > > 456	   Initiator asks resource from them.  These nodes can be
> discovered
> > > 457	   through RM ASA discovery process or path discovery
methods.
> > >
> > > 459	                Negotiation Resource
> > > 460
+-------------------------------------------------------------+
> > > 461	    |       Negotiation Resource
> > > |
> > > 462	    | +--------------------------------------------+
|
> > > 463	    | |                                            |
> > > |
> > > 464	 +--------+ Negotiation Resource +---------+   +---------+
> > +---------+
> > > 465	 | RM ASA |<-------------------->|  RM ASA |   |  RM ASA |
|
> RM
> > > ASA  |
> > > 466	 +--------+                      +---------+   +---------+
> > +---------+
> > > 467	 |  SI    | -------------------->| SR Node |-->| SR Node
|-->| SR
> > Node |
> > > 468	 +--------+   Transmit data      +---------+   +---------+
> > +---------+
> > > 469	   Figure-3 shows how RM ASAs negotiate resources and how
> Service
> > > 470	   Initiator forwards packages.  The RM ASA on the Service
> Initiator
> > > 471	   negotiates resources with the RM ASAs on the Service
> Responsers
> > one
> > > 472	   by one.
> > >
> > > 474	   Figure-3: Negotiation procedure of a transmission service
> > >
> > > 476	6.2.  Negotiation between a Service Initiator and a Service
> > Responser
> > >
> > > 478	   In the process of negotiation, Service Initiator
negotiates
> > resources
> > > 479	   with Service Responsers and ensures resources enough.  RM
> ASAs
> > > are
> > > 480	   allowed to negotiate resources for multiple rounds.  It
often
> > happens
> > > 481	   that the network resources on one node cannot meet the
> resources
> > > 482	   required by the service, but the service is willing to
reduce its
> > > 483	   resource requirements to ensure the successful deployment
of
> the
> > > 484	   service.  The RM ASAs on the Service Responsers feedback
the
> > > maximum
> > > 485	   available resources using Resource Management Objectives
in
> the
> > > 486	   response message.  The RM ASA on the Service Initiator
> changes
> > the
> > > 487	   resource requirements according to the specific
requirements of
> > the
> > > 488	   received resources and services, to carry out the next
round of
> > > 489	   service negotiation.
> > >
> > > 491	    +----------+
+---------+
> > > 492	    |  RM ASA  |                                   | RM
> ASA
> > > |
> > > 493	    +----------+
+---------+
> > > 494	    |    SI    |                                   | SR
> Node |
> > > 495	    +----------+ [[0,36732,3600000,[]][[0,10]]]
+---------+
> > > 496	         |------------------------------------------->|
> > > 497	         |      [[0,36732,3600000,[]][[0,8]]]         |
> > > 498	         |<-------------------------------------------|
> > > 499	         |      [[0,36732,3600000,[]][[0,8]]]         |
> > > 500	         |------------------------------------------->|
> > > 501	         |          Negotiation End (ACCEPT)          |
> > > 502	         |<-------------------------------------------|
> > >
> > > 504	   Figure-4 shows an example of a negotiation process.  In
the first
> > > 505	   negotiation round, RM ASA on the Service Initiator wants
to get
> > > 506	   resource from RM ASA on the Service Responsers.  In this
> example,
> > > the
> > > 507	   service type is Transmission Service and service-id is
36732.
> > The
> > > 508	   service will last 3600 seconds and only ask for one kind
of
> > resource
> > > 509	   10 Mbit/s bandwidth.  So, the
autonomic-network-service-value
> is
> > > 510	   [[0,36732,3600000,[]][[0,10]]].
> > >
> > > 512	   Figure-4: an example of a negotiation process
> > >
> > > 514	   When RM ASA on the Service Responser Node receives the
> message,
> > > if
> > > 515	   the RM ASA thinks the network can offer this required
resource,
> > it
> > > 516	   will response the ACCEPT.  But if it does not meet the
request,
> > it
> > > 517	   will give how much resource it can offer.  In this
example, the
> > > 518	   Service Responser can offer 8 Mbit/s.  The next step, RM
ASA
> on
> > the
> > > 519	   Service Initiator needs to decide whether to change its
resource
> > > 520	   requirements according to the reply, and sends a next
round
> > > 521	   negotiation.  Then, RM ASA on the Service Responser finds
the
> new
> > > 522	   resource requirement, it can meet.  So, it will response
ACCEPT.
> > > 523	   This is an example how ASAs negotiate resources.
> > >
> > > 525	6.3.  Coordination among Multiple Service Responsers
> > >
> > > 527	   The Service Initiator decides a coordinated value of
resource and
> > > 528	   negotiates with multiple Service Responsers that need to
reduce
> > the
> > > 529	   locked resource.  The Service Responsers reserve
resources for
> > > 530	   service according to the negotiation results.  If the
operation
> > is
> > > 531	   successful, the Service Responser reply success message
to the
> > > 532	   Service Initiator.  If it fails, reply failure message to
the
> > Service
> > > 533	   Initiator.  And the Service Initiator will restart
negotiation
> > step.
> > >
> > > 535	   When the Service Initiator receives the success message
from all
> > the
> > > 536	   Service Responsers, the service can start to transmit the
> > message.
> > >
> > > 538	6.4.  Service Ending
> > >
> > > 540	   When the service is ended, it is the responsibility of
Service
> > > 541	   Initiator to release all reserved resources through the
dialogue
> > with
> > > 542	   the RM ASA on the Service Responser.  And if the service
> lifetime
> > is
> > > 543	   exceeded, the Service Initiator SHOULD also release
reserved
> > resource
> > > 544	   although the Service Responsers may release the reserved
> resource
> > by
> > > 545	   themselves.
> > >
> > > 547	7.  Security Considerations
> > >
> > > 549	   It complies with GRASP security considerations.  Relevant
> > security
> > > 550	   issues are discussed in [RFC8990].  The preferred
security model
> > is
> > > 551	   that devices are trusted following the secure bootstrap
> procedure
> > > 552	   [RFC8995] and that a secure Autonomic Control Plane (ACP)
> > [RFC8994]
> > > 553	   is in place.
> > >
> > > 555	8.  IANA Considerations
> > >
> > > 557	   This document defines a new GRASP Objective option names:
> > > "Resource
> > > 558	   Manager" which need to be added to the "GRASP Objective
> Names"
> > > 559	   registry defined by [RFC8990].  And this document defines
a
> new
> > > 560	   registry tables "service-type" and "resource-type" under
the
> > > 561	   "Resource Manager" GRASP Objective.  The following
> subsections
> > > 562	   describe the new parameters.
> > >
> > > 564	8.1.  Service type
> > >
> > > 566	   IANA has set up the "service-type" registry, which
contains 4-bit
> > > 567	   value.  The service-type defines the type of service
which is
> > used to
> > > 568	   describe the type of resource requirements.
> > >
> > > 570	   *  0 : Transmission Service
> > >
> > > 572	   *  1 : Computing Service
> > >
> > > 574	8.2.  Resource Type
> > >
> > > 576	   IANA has set up the "resource-type" registry, which
contains
> > 4-bit
> > > 577	   value.
> > >
> > > 579	   *  0 : bandwidth
> > >
> > > 581	   *  1 : queue
> > >
> > > 583	   *  2 : memery
> > >
> > > 585	   *  3 : priority
> > >
> > > 587	   *  4 : cache
> > >
> > > 589	   *  5 : computing
> > >
> > > 591	9.  Acknowledgements
> > >
> > > 593	   Valuable comments were received from Michael Richardson
and
> Brian
> > > 594	   Carpenter.  Contributions to early versions of this
document was
> > > made
> > > 595	   by Yujing Zhou.
> > >
> > > 597	10.  References
> > >
> > > 599	10.1.  Normative References
> > >
> > > 601	   [RFC2119]  Bradner, S., "Key words for use in RFCs to
Indicate
> > > 602	              Requirement Levels", BCP 14, RFC 2119,
> > > 603	              DOI 10.17487/RFC2119, March 1997,
> > > 604	              <https://www.rfc-editor.org/info/rfc2119>.
> > >
> > > 606	   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S.,
Herzog, S.,
> > and S.
> > > 607	              Jamin, "Resource ReSerVation Protocol (RSVP)
--
> > Version
> > > 1
> > > 608	              Functional Specification", RFC 2205, DOI
> > > 10.17487/RFC2205,
> > > 609	              September 1997,
> > > <https://www.rfc-editor.org/info/rfc2205>.
> > >
> > > 611	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs
Lowercase in
> RFC
> > > 612	              2119 Key Words", BCP 14, RFC 8174, DOI
> > > 10.17487/RFC8174,
> > > 613	              May 2017,
> <https://www.rfc-editor.org/info/rfc8174>.
> > >
> > > 615	   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann,
"Concise
> > Data
> > > 616	              Definition Language (CDDL): A Notational
> Convention to
> > > 617	              Express Concise Binary Object Representation
> (CBOR)
> > > and
> > > 618	              JSON Data Structures", RFC 8610, DOI
> > > 10.17487/RFC8610,
> > > 619	              June 2019,
> <https://www.rfc-editor.org/info/rfc8610>.
> > >
> > > 621	   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary
Object
> > > 622	              Representation (CBOR)", STD 94, RFC 8949,
> > > 623	              DOI 10.17487/RFC8949, December 2020,
> > > 624	              <https://www.rfc-editor.org/info/rfc8949>.
> > >
> > > 626	   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu,
Ed.,
> > "GeneRic
> > > 627	              Autonomic Signaling Protocol (GRASP)", RFC
8990,
> > > 628	              DOI 10.17487/RFC8990, May 2021,
> > > 629	              <https://www.rfc-editor.org/info/rfc8990>.
> > >
> > > 631	   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S.
Bjarnason,
> > "An
> > > 632	              Autonomic Control Plane (ACP)", RFC 8994,
> > > 633	              DOI 10.17487/RFC8994, May 2021,
> > > 634	              <https://www.rfc-editor.org/info/rfc8994>.
> > >
> > > 636	   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T.,
Behringer,
> > M.,
> > > 637	              and K. Watsen, "Bootstrapping Remote Secure
Key
> > > 638	              Infrastructure (BRSKI)", RFC 8995, DOI
> > > 10.17487/RFC8995,
> > > 639	              May 2021,
> <https://www.rfc-editor.org/info/rfc8995>.
> > >
> > > 641	10.2.  Informative References
> > >
> > > 643	   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S.,
Clemm, A.,
> > > 644	              Carpenter, B., Jiang, S., and L. Ciavaglia,
"Autonomic
> > > 645	              Networking: Definitions and Design Goals", RFC
> 7575,
> > > 646	              DOI 10.17487/RFC7575, June 2015,
> > > 647	              <https://www.rfc-editor.org/info/rfc7575>.
> > >
> > > 649	Authors' Addresses
> > >
> > > 651	   Sheng Jiang (editor)
> > > 652	   Beijing University of Posts and Telecommunications
> > > 653	   No. 10 Xitucheng Road
> > > 654	   Beijing
> > > 655	   Haidian District, 100083
> > > 656	   China
> > > 657	   Email: [e-mail]
> > > 658	   Joanna Dang
> > > 659	   Huawei
> > > 660	   No.156 Beiqing Road
> > > 661	   Beijing
> > > 662	   P.R. China, 100095
> > > 663	   China
> > > 664	   Email: [e-mail]
> > >
> > > 666	   Zongpeng Du
> > > 667	   China Mobile
> > > 668	   32 Xuanwumen West Street
> > > 669	   Beijing
> > > 670	   P.R. China, 100053
> > > 671	   China
> > > 672	   Email: [e-mail]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/anima
> >
> 
> --
> ---
> [e-mail]