IDR Working Group J. Dong
Internet-Draft Z. Hu
Intended status: Standards Track Huawei Technologies
Expires: May 3, 2021 R. Pang
China Unicom
October 30, 2020
BGP SR Policy Extensions for Virtual Transport Network
draft-dong-idr-sr-policy-vtn-00
Abstract
Segment Routing (SR) Policy is a set of candidate paths, each
consisting of one or more segment lists and the associated
information. The header of a packet steered in an SR Policy is
augmented with an ordered list of segments associated with that SR
Policy. In scenarios where multiple Virtual Transport Networks
(VTNs) exist in the network, the VTN in which the SR policy is
instantiated may also need to be specified, so that the header of
packet can also be augmented with the information associated with the
VTN. An SR Policy candidate path can be distributed using BGP SR
Policy. This document defines extensions to BGP SR policy to specify
the VTN associated with the SR policy.
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 May 3, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dong, et al. Expires May 3, 2021 [Page 1]
Internet-Draft BGP SR Policy for VTN October 2020
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. VTN Information Encoding in SR Policy . . . . . . . . . . . . 3
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The concept of Segment Routing (SR) policy is defined in
[I-D.ietf-spring-segment-routing-policy]. An SR Policy is a set of
candidate paths, each consisting of one or more segment lists. The
head end of an SR Policy may learn multiple candidate paths for an SR
Policy. The header of a packet steered in an SR Policy is augmented
with an ordered list of segments associated with that SR Policy. The
BGP extensions to distribute SR Policy candidate paths is defined in
[I-D.ietf-idr-segment-routing-te-policy].
The concept of Virtual Transport Network (VTN) is introduced in
[I-D.ietf-teas-enhanced-vpn]. A VTN is a virtual underlay network
which has customized network topology and a set of dedicated or
shared network resources. In a network, different VTNs may be
created to meet different service requirements, and different
services can be mapped to different VTNs.
In scenarios where multiple virtual networks (VTNs) exist in the
network, the identifier of VTN in which the SR policy is instantiated
may also need to be specified, so that the header of data packet can
also be augmented with the information of the associated VTN. This
document defines the BGP extensions to specify the VTN ID associated
with a candidate path of SR policy.
Dong, et al. Expires May 3, 2021 [Page 2]
Internet-Draft BGP SR Policy for VTN October 2020
2. Specification of Requirements
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 RFC 2119 [RFC2119].
3. VTN Information Encoding in SR Policy
In order to specify the VTN the candidate path of SR policy is
associated with, a new sub-TLV called "VTN sub-TLV" is defined in the
BGP Tunnel Encapsulation Attribute [I-D.ietf-idr-tunnel-encaps]. The
VTN sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute
with the tunnel type set to SR Policy.
The VTN sub-TLV is optional and MUST NOT appear more than once for
one SR Policy candidate path. If the VTN sub-TLV appears more than
once, the associated BGP SR Policy NLRI is considered malformed and
the "treat-as-withdraw" strategy of [RFC7606] is applied.
The VTN sub-TLV has the following format:
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTN ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. VTN Sub-TLV
where:
o Type: TBA
o Length: 6
o Flags: 1-octet flag field. None is defined at this stage. The
flags SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. It SHOULD be set to zero on
transmission and MUST be ignored on receipt.
o VTN ID: A 32-bit global significant identifier which is used to
identify a VTN. Value 0 and 0xFFFFFFFF are reserved.
The encoding structure of BGP SR Policy with the VTN sub-TLV is
expressed as below:
Dong, et al. Expires May 3, 2021 [Page 3]
Internet-Draft BGP SR Policy for VTN October 2020
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
Binding SID
Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
VTN
Segment List
Weight
Segment
Segment
...
...
4. Procedures
When a candidate path of SR policy is associated with a specific VTN,
the originating node of SR policy SHOULD include the associated VTN
in the BGP Tunnel Encapsulation Attribute of the BGP SR policy. The
setting of other fields and attributes in BGP SR policy SHOULD
follows the mechanism as defined in
[I-D.ietf-idr-segment-routing-te-policy].
When a BGP speaker receives an SR Policy which is acceptable and
usable according to the rules as defined in
[I-D.ietf-idr-segment-routing-te-policy], and the SR Policy candidate
path selected as the best candidate path is associated with a VTN,
the BGP speaker SHOULD encapsulate VTN-specific information to the
header of packets steered to the SR policy. For SR Policy with IPv6
data plane, the possible approach is to encapsulate the VTN-ID to the
packets using the mechanism defined in
[I-D.dong-6man-enhanced-vpn-vtn-id]. For SR Policy with MPLS data
plane, the usage of the VTN information is similar, the mechanism
will be defined in a separate document and is out of the scope of
this document.
Although the proposed mechanism allows that different candidate paths
in one SR policy be associated with different VTNs, in normal network
scenarios it is considered that the mapping between service to VTN is
consistent, in such case all candidate paths of one SR policy are
associated with the same VTN.
Dong, et al. Expires May 3, 2021 [Page 4]
Internet-Draft BGP SR Policy for VTN October 2020
5. Security Considerations
The security considerations of BGP and BGP SR policy apply to this
document.
6. IANA Considerations
This document requests IANA to allocate a new sub-TLV type as defined
in Section 3 from "BGP Tunnel Encapsulation Attribute sub-TLVs"
registry.
Value Description Reference
----------------------------------------------------
TBA VTN This document
7. Acknowledgments
The authors would like to thank Guoqi Xu, Lei Bao and Haibo Wang for
the review and discussion of this document.
8. References
8.1. Normative References
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-09 (work in progress), May 2020.
[I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
encaps-19 (work in progress), September 2020.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-08 (work in progress),
July 2020.
[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>.
Dong, et al. Expires May 3, 2021 [Page 5]
Internet-Draft BGP SR Policy for VTN October 2020
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
8.2. Informative References
[I-D.dong-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual
Transport Network Identifier in IPv6 Extension Header",
draft-dong-6man-enhanced-vpn-vtn-id-01 (work in progress),
July 2020.
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Networks (VPN+)
Service", draft-ietf-teas-enhanced-vpn-06 (work in
progress), July 2020.
Authors' Addresses
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Zhibo Hu
Huawei Technologies
Email: huzhibo@huawei.com
Ran Pang
China Unicom
Email: pangran@chinaunicom.cn
Dong, et al. Expires May 3, 2021 [Page 6]