BGP Extensions for SRv6 SIDs Allocation
draft-chen-idr-bgp-srv6-sid-allocation-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Huaimo Chen , Zhenbin Li , Shunwan Zhuang | ||
| Last updated | 2019-03-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-idr-bgp-srv6-sid-allocation-00
DetNet J. Farkas
Internet-Draft B. Varga
Intended status: Standards Track Ericsson
Expires: September 6, 2018 R. Cummings
National Instruments
Y. Jiang
Huawei
Y. Zha
Tencent
March 05, 2018
DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-01
Abstract
This document describes flow and service information model for
Deterministic Networking (DetNet). The DetNet service is provided
either for a Layer 3 or a Layer 2 flow. This document provides
DetNet flow and service information model both for Layer 3 and Layer
2 flows in an integrated fashion.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
Farkas, et al. Expires September 6, 2018 [Page 1]
Internet-Draft DetNet Flow Information Model March 2018
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5
5. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Service overview . . . . . . . . . . . . . . . . . . . . 6
5.2. Service parameters . . . . . . . . . . . . . . . . . . . 6
5.3. Reference Points . . . . . . . . . . . . . . . . . . . . 7
5.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 8
6. End System and DetNet domain . . . . . . . . . . . . . . . . 8
7. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Identification and Specification of Flows . . . . . . . . 11
7.1.1. DetNet L3 Flow Identification and Specification at
UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.2. DetNet L2 Flow Identification and Specification at
UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.3. DetNetwork Flow Identification and Specification . . 12
7.2. Traffic Specification . . . . . . . . . . . . . . . . . . 12
7.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 14
7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14
8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Common Attributes of Source and Destination . . . . . . . . . 16
10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16
10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16
10.3. User to Network Requirements . . . . . . . . . . . . . . 17
11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 18
14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20
14.2. Interface Configuration . . . . . . . . . . . . . . . . 21
14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21
15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 21
16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
Farkas, et al. Expires September 6, 2018 [Page 2]
Internet-Draft DetNet Flow Information Model March 2018
18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
19.1. Normative References . . . . . . . . . . . . . . . . . . 22
19.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
A Deterministic Networking (DetNet) service provides a capability to
carry a unicast or a multicast data flow for an application with
constrained requirements on network performance, e.g., low packet
loss rate and/or latency. The DetNet service is provided either for
a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network,
see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive
Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged
network. DetNet and TSN have common architecture as expressed in
[IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can
be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and
DetNet L2 flows. Therefore, the DetNet flow and service information
model provided by this document covers both DetNet L3 flows and
DetNet L2 flows in an integrated fashion.
In a given network scenario three information models can
distinguished:
o Flow models describe characteristics of data flows. These models
describe in detail all relevant aspects of a flow that are needed
to support the flow properly by the network between the source and
the destination(s).
o Service models describe characteristics of services being provided
for data flows over a network. These models can be treated as a
network operator independent information model.
o Configuration models describe in detail the settings required on
network nodes to serve a data flow properly.
Service and flow information models are used between the user and the
network operator. Configuration information models are used between
the management/control plane entity of the network and the network
nodes. They are shown in Figure 1.
Farkas, et al. Expires September 6, 2018 [Page 3]
Internet-Draft DetNet Flow Information Model March 2018
User Network Operator
flow/service
/\ info model +---+
/ \ <---------------> | X | management/control
---- +-+-+ plane entity
^
| configuration
| info model
+------------+
v | |
+-+ | v Network
+-+ v +-+ nodes
+-+ +-+
+-+
Figure 1: Usage of Information models (flow, service and
configuration)
DetNet flow and service information model is based on
[I-D.ietf-detnet-architecture] and on the data model specified by
[IEEE8021Qcc]. Furthermore, the DetNet flow information model relies
on the flow identification possibilities described in [IEEE8021CB],
which is used by [IEEE8021Qcc] as well. In addition to TSN data
model, [IEEE8021Qcc] also specifies configuration of TSN features
(e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the
common architecture and flow model, configuration features can be
leveraged in certain deployment scenarios, e.g., when the network
that provides the DetNet service includes both L3 and L2 network
segments.
Based on the DetNet architecture [I-D.ietf-detnet-architecture] (see
Section 4), this document (this revision) only considers the
Centralized Network / Distributed User Model out of the models
specified by [IEEE8021Qcc]. That is, there is a User-Network
Interface (UNI) between an end system and a network. Furthermore,
there is a central entity for the control of the network. For
instance, the central entity implements a Path Computation Element
(PCE) for the calculation and establishment of paths needed for
packet replication and elimination, if any.
1.1. Goals
As it is expressed in the Charter [IETFDetNet], the DetNet WG
collaborates with IEEE 802.1 TSN in order to define a common
architecture for both Layer 2 and Layer 3, which is beneficial for
various reasons, e.g., in order to simplify implementations. The
flow and service information models should be also common along those
lines. As the TSN flow information/data model specified by
Farkas, et al. Expires September 6, 2018 [Page 4]
Internet-Draft DetNet Flow Information Model March 2018
[IEEE8021Qcc] is mature, the DetNet flow and service information
models described in this document are based on [IEEE8021Qcc], which
is an amendment to [IEEE8021Q].
This document intends to specify flow and service information models
only.
1.2. Non Goals
This document (this revision) does not intend to specify either flow
data model or DetNet configuration. From these aspects, the goals of
this document differ from the goals of [IEEE8021Qcc], which also
specifies data model and configuration of certain TSN features.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The lowercase forms with an initial capital "Must", "Must Not",
"Shall", "Shall Not", "Should", "Should Not", "May", and "Optional"
in this document are to be interpreted in the sense defined in
[RFC2119], but are used where the normative behavior is defined in
documents published by SDOs other than the IETF.
3. Terminology and Definitions
This document uses the terminology established in Section 2 of the
DetNet architecture document [I-D.ietf-detnet-architecture]. The
DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used
to perform translation from [IEEE8021Qcc] to this document.
Additional terms used in this document:
DetNet L3 Flow: Layer 3 (L3) flow leveraging DetNet service.
DetNet L2 Flow: Layer 2 (L2) flow leveraging DetNet service.
DetNetwork Flow: DetNet data plane specific encapsulated format of a
DetNet L2 or L3 flow leveraging DetNet service.
4. Naming Conventions
The following naming conventions were used for naming information
model components in this document. It is recommended that extensions
of the model use the same conventions.
o Names SHOULD be descriptive.
Farkas, et al. Expires September 6, 2018 [Page 5]
Internet-Draft DetNet Flow Information Model March 2018
o Names MUST start with uppercase letters.
o Composed names MUST use capital letters for the first letter of
each component. All other letters are lowercase, even for
acronyms. Exceptions are made for acronyms containing a mixture
of lowercase and capital letters, such as IPv6. Examples are
SourceMacAddress and DestinationIPv6Address.
5. Service model
5.1. Service overview
The DetNet service can be defined as a service that provides a
capability to carry a unicast or a multicast data flow for an
application with constrained requirements on network performance,
e.g., low packet loss rate and/or latency.
The simplest DetNet service is to provide bridging over the DN domain
(i.e., tunneling for L2), where the connected hosts are in the same
broadcast (BC) domain. Forwarding over the DetNet domain is based on
L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is
DetNet Routing service that provides routing, so available only for
L3 hosts that are in different BC domains. Forwarding over the
DetNet domain is based on L3 (IP) addresses (i.e. dst-IP).
Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] shows the
DetNet service related reference points and main components.
5.2. Service parameters
Two forwarding methods are distinguished: (1) Bridging and (2)
Routing. The DN service is represented by a DN-PSeudoWire (DN-PW).
Data-flows are received over the UNI. Usually there is a DN service
related legacy VPN service. The DN service and the legacy VPN
service use a common AC (attachment circuit). Legacy VPN is used by
regular traffic of the DetNet end-systems. DN flows are "directed"
by a selector to DN-PW(s). (See Figure 8. in
[I-D.ietf-detnet-architecture])
Service attributes for DetNet connectivity are:
o Bandwidth parameter(s),
o Delay parameter(s),
o Loss parameter(s),
Farkas, et al. Expires September 6, 2018 [Page 6]
Internet-Draft DetNet Flow Information Model March 2018
o Connectivity type,
o In order delivery,
o Service rank.
Time/loss sensitive applications may have somewhat special
requirements especially for loss (e.g., no loss in two consecutive
communication cycles; very low outage time, etc.).
Two connectivity types are distinguished: point-to-point (p2p) and
point-to-multipoint (p2mp). Connectivity type p2mp is created by a
transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity
is a superposition of p2mp connections.)
Depending on the application and the end-system capabilities DetNet
service may be requested to provide in order delivery.
Service rank provides the rank of a service instance relative to
other services in the network. Rank is used by the network in case
of network resource limitation scenarios.
5.3. Reference Points
From service model design perspective a fundamental question is the
location of the service endpoints, i.e., where the service starts and
ends.
Note: Further discussion is needed based on data plane encapsulation
results what reference points should be defined. Only some possible
examples listed here:
o App-flow endpoint: End system's internal reference point for the
native data flow.
o DetNet-UNI: UNI interface ("U") on a DetNet edge node.
o DetNet-NNI: NNI interface ("N") between DetNet domains.
[[NOTE: Contributions are welcome whether we should define or
distinguish internal reference point(s) for DetNet-aware end-systems
as well. ]]
DetNet-UNI and DetNet-NNI are assumed in this document to be packet-
based reference points and provide connectivity over the packet
network and between domains. A DetNet-UNI adds networking technology
specific encapsulation to the data flow in order to transport it over
the network.
Farkas, et al. Expires September 6, 2018 [Page 7]
Internet-Draft DetNet Flow Information Model March 2018
[[NOTE: Differences between the service over end-systems internal
reference points and DetNet-UNI is for further discussions. For
example, in-order delivery is expected in end system internal
reference points, whereas it is considered optional over the DetNet-
UNI. ]]
5.4. Service scenarios
Using the above defined reference points, two major service scenarios
can be identified:
o End-to-End-Service: the service reaches out to final source or
destination nodes, so it is an e2e service between application
hosting devices (end systems).
o DetNet-Service: the service connects networking islands, so it is
a service between the borders of network domain(s).
[[NOTE: we may consider to define further scenarios based on the
result of reference point related discussions. ]]
6. End System and DetNet domain
Deterministic service is required by time/loss sensitive
application(s) running on an end system during communication with its
peer(s). Such a data exchange has various requirements on delay and/
or loss parameters.
The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes
two kinds of end systems: Source and Destination. The same
distinction is applied for the DetNet flow information model. In
addition to the end systems interested in a flow, the status
information of the flow is also important. Therefore, the DetNet
flow information model relies on three high level groups:
o Source: an end system capable of sourcing a DetNet flow. The
Source information group includes elements that specify the Source
for a single flow. This information group is applied from the
user to the network.
o Destination: an end system that is a destination of a DetNet flow.
The Destination information group includes elements that specify
the Destination for a single flow. This information group is
applied from the user to the network.
o Flow-Status: the status of a DetNet flow. The status information
group includes elements that specify the status of the flow in the
network. This information group is applied from the network to
Farkas, et al. Expires September 6, 2018 [Page 8]
Internet-Draft DetNet Flow Information Model March 2018
the user. This information group informs the user whether or not
the flow is ready for use.
From service perspective two kinds of edge nodes can be
distinguished: Ingress and Egress. In addition the technology of the
DetNet domain and the status of the service are also important.
Therefore, the DetNet service information model relies on four high
level groups:
o Ingress: an edge system receiving a DetNet flow from a Source.
The Ingress information group includes elements that specify the
entry point for a single flow. This information group is applied
from the network to the user.
o Egress: an edge system sending traffic towards a Destination of a
DetNet flow. The Egress information group includes elements that
specify the egress point for a single flow. This information
group is applied from the network to the user.
o DetNet Domain: an administrative domain providing the DetNet
service. The DetNet domain information group includes elements
that specify the forwarding capabilities and methods for a single
flow. This information group is applied within the network.
o Service-Status: the status of a DetNet service. The status
information group includes elements that specify the status of the
service specific state of the network. This information group is
applied from the network to the user. This information group
informs the user whether or not the service is ready for use.
There are two operations for each flow with respect to a Source or a
Destination (and an Ingress or an Egress):
o Join: Source/Destination request to join the flow.
o Leave: Source/Destination request to leave the flow.
o Modify: Source/Destination request to change the flow.
Modify operation can be considered to address cases when a flow is
slightly changed, e.g., only MaxPayloadSize (Section 7.2) has been
changed. The advantage of having a Modify is that it allows to
initiate a change of flow spec while leaving the current flow is
operating until the change is accepted. If there is no linkage
between the Join and the Leave, then in figuring out whether the new
flow spec can be supported, the central entity has to assume that the
resources committed to the current flow are in use. Via Modify the
central entity knows that the resources supporting the current flow
Farkas, et al. Expires September 6, 2018 [Page 9]
Internet-Draft DetNet Flow Information Model March 2018
can be available for supporting the altered flow. Modify is
considered to be an optional operation due to possible control-plane
limitations.
As the DetNet UNI can provide service for both L3 and L2 flows, end
systems may not need to implement the L3 <=> L2 Transfer Function
specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also
subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a
function similar to the Transfer Function, see, e.g., the Svc Proxy
in Figure 1 in [I-D.ietf-detnet-dp-alt].
7. Flow
The flows leveraging DetNet service can be unicast or multicast data
flows for an application with constrained requirements on network
performance, e.g., low packet loss rate and/or latency. Therefore,
they can require different connectivity types: point-to-point (p2p)
or point-to-multipoint (p2mp). The p2mp connectivity is created by a
transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt].
(Note that mp2mp connectivity is a superposition of p2mp
connections.)
Many flows using DetNet service are periodic with fix packet size
(i.e., Constant Bit Rate (CBR) flows), or periodic with variable
packet size.
Delay and loss parameters are correlated because the effect of late
delivery can result data loss for an application. However, not all
applications require hard limits on both parameters (delay and loss).
For example, some real-time applications allow graceful degradation
if loss happens (e.g., sample-based processing, media distribution).
Some others may require high-bandwidth connections that make the
usage of techniques like packet replication economically challenging
or even impossible. Some applications may not tolerate loss, but are
not delay sensitive (e.g., bufferless sensors). Time/loss sensitive
applications may have somewhat special requirements especially for
loss (e.g., no loss in two consecutive communication cycles; very low
outage time, etc.).
Flows have the following attributes:
a. DataFlowSpecification (Section 7.1)
b. TrafficSpecification (Section 7.2)
c. FlowRank (Section 7.3)
Flow attributes are described in the following sections.
Farkas, et al. Expires September 6, 2018 [Page 10]
Internet-Draft DetNet Flow Information Model March 2018
7.1. Identification and Specification of Flows
Identification options for DetNet flows at the UNI and within the
DetNet domain are specified as follows; see Section 7.1.1 for DetNet
L3 flows (at UNI), Section 7.1.2 for DetNet L2 flows (at UNI) and
Section 7.1.3 for DetNetwork flows (within the network).
7.1.1. DetNet L3 Flow Identification and Specification at UNI
DetNet L3 flows can be identified and specified by the following
attributes:
a. SourceIpAddress
b. DestinationIpAddress
c. IPv6FlowLabel
d. Dscp
e. Protocol
f. SourcePort
g. DestinationPort
7.1.2. DetNet L2 Flow Identification and Specification at UNI
DetNet L2 flows can be identified and specified by the following
attributes:
a. DestinationMacAddress
b. SourceMacAddress
c. Pcp
d. VlanId
e. EtherType
Note: The Multiple Stream Registration Protocol (MSRP) [IEEE8021Q]
uses StreamID to match Talker registrations with their corresponding
Listener registrations, i.e., to identify Streams (L2 TSN flows).
The StreamID includes the following subcomponents:
o A 48-bit MAC Address associated with the Talker sourcing the
stream to the bridged network.
Farkas, et al. Expires September 6, 2018 [Page 11]
Internet-Draft BGP for SRv6 SIDs March 2019
SRv6 LAN Adj-SID TLV (TBD3): A new TLV, called SRv6 LAN Adj-SID
TLV, contains an SRv6 LAN Adj-SID and related information.
The format of an SRv6 Adj-SID TLV is illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | Algorithm |B|S|P| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SRv6 Endpoint Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Identifier |
| (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRv6 Adj-SID TLV
Type: TBD3 for SRv6 Adj-SID TLV is to be assigned by IANA.
Length: Variable.
Weight: 1 octet. The value represents the weight of the SID for the
purpose of load balancing.
Algorithm: 1 octet. Associated algorithm.
Flags: 2 octets. Three flags are defined in
[I-D.bashandy-isis-srv6-extensions].
SRv6 Endpoint Function: 2 octets. The function associated with SRv6
SID.
SRv6 Identifier: 16 octets. IPv6 address representing SRv6 SID.
Reserved: MUST be set to 0 while sending and ignored on receipt.
The format of an SRv6 LAN Adj-SID TLV is illustrated below.
Chen, et al. Expires September 9, 2019 [Page 7]
Internet-Draft BGP for SRv6 SIDs March 2019
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | Algorithm |B|S|P| Flags |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SRv6 Endpoint Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| neighbor Router ID (4 octets) / System ID (6 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Identifier |
| (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRv6 LAN Adj-SID TLV
Type: TBD4 for SRv6 LAN Adj-SID TLV is to be assigned by IANA.
Length: Variable.
Weight: 1 octet. The value represents the weight of the SID for the
purpose of load balancing.
Algorithm: 1 octet. Associated algorithm.
Flags: 2 octets. Three flags B, S and P are defined in
[I-D.bashandy-isis-srv6-extensions]. Flag O set to 1 indicating
OSPF neighbor Router ID of 4 octets, set to 0 indicating IS-IS
neighbor System ID of 6 octets.
SRv6 Endpoint Function: 2 octets. The function associated with SRv6
SID.
SRv6 Identifier: 16 octets. IPv6 address representing SRv6 SID.
Reserved: MUST be set to 0 while sending and ignored on receipt.
Chen, et al. Expires September 9, 2019 [Page 8]
Internet-Draft BGP for SRv6 SIDs March 2019
4. IANA Considerations
This document requests assigning a code-point from the registry "BGP-
LS Protocol-IDs" as follows:
+-------------+-----------------------------------+-------------+
| Protocol-ID | Description | Reference |
+-------------+-----------------------------------+-------------+
| TBD | IDs Allocation | Section 3 |
+-------------+-----------------------------------+-------------+
This document requests assigning a code-point from the registry "BGP-
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
TLVs" as follows:
+----------------+-----------------------------------+-------------+
| TLV Code Point | Description | Reference |
+----------------+-----------------------------------+-------------+
| TBD1 | SRv6 Node SID | Section 3 |
+----------------+-----------------------------------+-------------+
| TBD2 | SRv6 Adj-SID | Section 3 |
+----------------+-----------------------------------+-------------+
| TBD3 | SRv6 LAN Adj-SID | Section 3 |
+----------------+-----------------------------------+-------------+
5. Security Considerations
Protocol extensions defined in this document do not affect the BGP
security other than those as discussed in the Security Considerations
section of [RFC7752].
6. Acknowledgements
The authors would like to thank Nan Wu, and others for their valuable
suggestions and comments on this draft.
7. References
7.1. Normative References
[I-D.bashandy-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Routing over IPv6
Dataplane", draft-bashandy-isis-srv6-extensions-05 (work
in progress), March 2019.
Chen, et al. Expires September 9, 2019 [Page 9]
Internet-Draft BGP for SRv6 SIDs March 2019
[I-D.ietf-idr-flowspec-path-redirect]
Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id
Redirect", draft-ietf-idr-flowspec-path-redirect-07 (work
in progress), December 2018.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing-
extensions-22 (work in progress), December 2018.
[I-D.ietf-rtgwg-bgp-routing-large-dc]
Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for
routing in large-scale data centers", draft-ietf-rtgwg-
bgp-routing-large-dc-11 (work in progress), June 2016.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-segment-routing-ldp-interop]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-15 (work in
progress), September 2018.
[I-D.li-ospf-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-li-ospf-
ospfv3-srv6-extensions-03 (work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
Chen, et al. Expires September 9, 2019 [Page 10]
Internet-Draft BGP for SRv6 SIDs March 2019
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
7.2. Informative References
[I-D.gredler-idr-bgp-ls-segment-routing-extension]
Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M.,
and J. Tantsura, "BGP Link-State extensions for Segment
Routing", draft-gredler-idr-bgp-ls-segment-routing-
extension-02 (work in progress), October 2014.
[I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-17 (work in progress), October 2018.
Authors' Addresses
Huaimo Chen
Huawei
Boston, MA
USA
Email: Huaimo.chen@huawei.com
Zhenbin Li
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Chen, et al. Expires September 9, 2019 [Page 11]
Internet-Draft BGP for SRv6 SIDs March 2019
Shunwan Zhuang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Chen, et al. Expires September 9, 2019 [Page 12]