rfc9834v3.txt | rfc9834.txt | |||
---|---|---|---|---|
skipping to change at line 135 ¶ | skipping to change at line 135 ¶ | |||
Routers (ASBRs), data centers gateways, or Internet Exchange Points | Routers (ASBRs), data centers gateways, or Internet Exchange Points | |||
(IXPs). A connectivity service is basically about ensuring data | (IXPs). A connectivity service is basically about ensuring data | |||
transfer received from or destined to a given termination point to or | transfer received from or destined to a given termination point to or | |||
from other termination points. The objectives for the connectivity | from other termination points. The objectives for the connectivity | |||
service can be negotiated and agreed upon between the customer and | service can be negotiated and agreed upon between the customer and | |||
the network provider. To facilitate data transfer within the | the network provider. To facilitate data transfer within the | |||
provider network, it is assumed that the appropriate setup is | provider network, it is assumed that the appropriate setup is | |||
provisioned over the links that connect customer termination points | provisioned over the links that connect customer termination points | |||
and a provider network (usually via a Provider Edge (PE)), allowing | and a provider network (usually via a Provider Edge (PE)), allowing | |||
data to be successfully exchanged over these links. The required | data to be successfully exchanged over these links. The required | |||
setup is referred to in this document as an AC, while the underlying | setup is referred to in this document as an attachment circuit (AC), | |||
link is referred to as a "bearer". | while the underlying link is referred to as a "bearer". | |||
When a customer requests a new service, the service can be bound to | When a customer requests a new service, the service can be bound to | |||
existing ACs or trigger the instantiation of new ACs. The | existing ACs or trigger the instantiation of new ACs. The | |||
provisioning of a service should, thus, accommodate both deployments. | provisioning of a service should, thus, accommodate both deployments. | |||
Also, because the instantiation of an AC requires coordinating the | Also, because the instantiation of an AC requires coordinating the | |||
provisioning of endpoints that might not belong to the same | provisioning of endpoints that might not belong to the same | |||
administrative entity (customer vs. provider or distinct operational | administrative entity (customer vs. provider or distinct operational | |||
teams within the same provider, etc.), providing programmatic means | teams within the same provider, etc.), providing programmatic means | |||
to expose Attachment Circuits as a Service (ACaaS) greatly simplifies | to expose Attachment Circuits as a Service (ACaaS) greatly simplifies | |||
skipping to change at line 1190 ¶ | skipping to change at line 1190 ¶ | |||
provider network. That is, a 'peer-sap' will refer to a customer | provider network. That is, a 'peer-sap' will refer to a customer | |||
node. | node. | |||
'group-profile-ref': Indicates references to one or more profiles | 'group-profile-ref': Indicates references to one or more profiles | |||
that are defined in Section 5.2.3. | that are defined in Section 5.2.3. | |||
'parent-ref': Specifies an AC that is inherited by an AC. | 'parent-ref': Specifies an AC that is inherited by an AC. | |||
In contexts where dynamic termination points are managed for a | In contexts where dynamic termination points are managed for a | |||
given AC, a Parent AC can be defined with a set of stable and | given AC, a Parent AC can be defined with a set of stable and | |||
common information, while "Child" ACs are defined to track dynamic | common information, while Child ACs are defined to track dynamic | |||
information. These "Child" ACs are bound to the Parent AC, which | information. These Child ACs are bound to the Parent AC, which is | |||
is exposed to services (as a stable reference). | exposed to services (as a stable reference). | |||
Whenever a Parent AC is deleted, all its "Child" ACs MUST be | Whenever a Parent AC is deleted, all its Child ACs MUST be | |||
deleted. | deleted. | |||
A "Child" AC MAY rely upon more than one Parent AC (e.g., parent | A Child AC MAY rely upon more than one Parent AC (e.g., parent | |||
Layer 2 AC and parent Layer 3 AC). In such cases, these ACs MUST | Layer 2 AC and parent Layer 3 AC). In such cases, these ACs MUST | |||
NOT be overlapping. An example to illustrate the use of multiple | NOT be overlapping. An example to illustrate the use of multiple | |||
Parent ACs is provided in Appendix A.12. | Parent ACs is provided in Appendix A.12. | |||
'child-ref': Lists one or more references of Child ACs that rely | 'child-ref': Lists one or more references of Child ACs that rely | |||
upon this AC as a Parent AC. | upon this AC as a Parent AC. | |||
'group': Lists the groups to which an AC belongs [RFC9181]. For | 'group': Lists the groups to which an AC belongs [RFC9181]. For | |||
example, the 'group-id' is used to associate redundancy or | example, the 'group-id' is used to associate redundancy or | |||
protection constraints of ACs. An example is provided in | protection constraints of ACs. An example is provided in | |||
skipping to change at line 5283 ¶ | skipping to change at line 5283 ¶ | |||
} | } | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
Figure 42: Example of a Message Body of a Response Indicating the | Figure 42: Example of a Message Body of a Response Indicating the | |||
Creation of the ACs | Creation of the ACs | |||
Figure 43 shows the message body of the request to create an RFC 9543 | Figure 43 shows the message body of the request to create an RFC 9543 | |||
Netowrk Slice Service bound to the ACs created using Figure 41. Only | Network Slice Service bound to the ACs created using Figure 41. Only | |||
references to these ACs are included in the RFC 9543 Network Slice | references to these ACs are included in the RFC 9543 Network Slice | |||
Service request. | Service request. | |||
{ | { | |||
"ietf-network-slice-service:network-slice-services": { | "ietf-network-slice-service:network-slice-services": { | |||
"slo-sle-templates": { | "slo-sle-templates": { | |||
"slo-sle-template": [ | "slo-sle-template": [ | |||
{ | { | |||
"id": "low-latency-template", | "id": "low-latency-template", | |||
"description": "Lowest latency forwarding behavior" | "description": "Lowest latency forwarding behavior" | |||
skipping to change at line 6176 ¶ | skipping to change at line 6176 ¶ | |||
100". The Parent AC captures Layer 2 and Layer 3 properties for | 100". The Parent AC captures Layer 2 and Layer 3 properties for | |||
this VLAN: vlan-id, IP default gateway and subnet, IP address pool | this VLAN: vlan-id, IP default gateway and subnet, IP address pool | |||
for NFs endpoints, static routes with BFD to user plane, and BGP | for NFs endpoints, static routes with BFD to user plane, and BGP | |||
configuration to control plane NFs. In addition, the IP addresses | configuration to control plane NFs. In addition, the IP addresses | |||
of the user plane ("nf-up") instances are protected using BFD. | of the user plane ("nf-up") instances are protected using BFD. | |||
* Configuration of a Parent AC as a centralized attachment for "vlan | * Configuration of a Parent AC as a centralized attachment for "vlan | |||
200". This VLAN is for Layer 2 connectivity between NFs (no IP | 200". This VLAN is for Layer 2 connectivity between NFs (no IP | |||
configuration in the provider network). | configuration in the provider network). | |||
* "Child ACs" binding bearers to Parent ACs for "vlan 100" and "vlan | * Child ACs binding bearers to Parent ACs for "vlan 100" and "vlan | |||
200". | 200". | |||
* The deployment of the network service to all compute nodes | * The deployment of the network service to all compute nodes | |||
("compute-01" to "compute-10"), even though the NF is not | ("compute-01" to "compute-10"), even though the NF is not | |||
instantiated on "compute-07"/"compute-08". This approach permits | instantiated on "compute-07"/"compute-08". This approach permits | |||
handling compute failures and scale-out scenarios in a reactive | handling compute failures and scale-out scenarios in a reactive | |||
and flexible fashion thanks to a pre-provisioned networking logic. | and flexible fashion thanks to a pre-provisioned networking logic. | |||
.-------------------------------------. | .-------------------------------------. | |||
|VLAN 100: | | |VLAN 100: | | |||
End of changes. 6 change blocks. | ||||
9 lines changed or deleted | 9 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |