IDR WG Sandy. Zhang
Internet-Draft ZTE Corporation
Intended status: Standards Track Ying. Cheng
Expires: January 7, 2016 China Unicom
July 6, 2015
Upstream Assigned Label Collision Solution
draft-zhang-idr-upstream-assigned-label-solution-00.txt
Abstract
The upstream-assigned label is used to identify the specific
multicast flow. In MVPN technology RFC6513, it says: "This procedure
requires each egress PE to support a separate label space for every
other PE. The egress PEs creates a forwarding entry for the
upstream-assigned MPLS label, allocated by the ingress PE, in this
label space."
In common scenario, the "separate label space" is planned by network
administrator in advance. For the stable network, the method of
allocating the separate label space is easy and practicable. But
when the network changes dynamically, it is very hard to allocate the
separate label space in advance. The planned label space is probably
insufficient. That leads to collision when PE uses the common label
space to allocate upstream-assigned label. Therefore we need a
flexible solution for the collision of upstream-assigned label in the
dynamically changing network.
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 http://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 January 7, 2016.
Zhang & Cheng Expires January 7, 2016 [Page 1]
Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015
Copyright Notice
Copyright (c) 2015 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
(http://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. Timestamp Attribute . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability Restriction and Cautions . . . . . . . . . 4
2.2. Handing a malformed UALRT Attribute . . . . . . . . . . . 4
2.3. Restriction . . . . . . . . . . . . . . . . . . . . . . . 4
3. Originating and Sending the UALRT attribute . . . . . . . . . 4
4. Receiving the UALRT attribute . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
As the development of MVPN technology, data center interconnection
technology, and BIER (Bit Indexed Explicit Replication) technology,
etc. Multicast is more and more used. Upstream-assigned label is
used for egress PEto indicate a specific multicast flow. uppose at a
L3VPN network which was used for MVPN only is expanded to support the
interconnection of DC. Many VxLan which each need an upstream-
assigned label to indicate lead to lack of the label space and it
will comsumes a lot of manpower to adjust the label space on every
PE. Adjusting the label space on every PE will be difficult and cost
more manpower.
In this document, we define a new BGP attribute, named UALRT:
"upstream-assigned label route's timestamp". When the collision of
upstream-assigned label occurs, all the PEs in the L3VPN, will find
out those routes which are feasible with use of the common algorithm.
And the PE which announces the collision upstream-assigned label will
adjust the label to avoid collision.
Zhang & Cheng Expires January 7, 2016 [Page 2]
Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015
-------
| PEa | ---------------------------------
------- | | -------
| MVPN | | PEc |
------- | | -------
| PEb | ---------------------------------
-------
Figure 1: collision of upstream-assigned label in MVPN
For example, PEa and PEb send MVPN flows to PEc with a same I-PMSI.
PEa send (vpn1, S1, G1) flows to PEc, PEb send (vpn1, S2, G2) flows
to PEc similar. PEa and PEb advertise the two multicast routes by
upstream-assigned label to let PEc distinguish the two flows. If
network manager has not programmed the separate space for upstream-
assigned label on every PE, PEa and PEb may advertise the same label
for each route. When PEc receives the two multicast flows from the
common I-PMSI tunnel, PEc can not distinguish the two flows
correctly, and PEc then forward the two flows to wrong receivers.
2. Timestamp Attribute
The UALRT attribute is an optional, non-transitive BGP path
attribute. The attribute type code for the UALRT attribute is TBD.
The value field of the UALRT attribute is defined here to be a set of
elements encoded as "Type/Length/Value" (i.e., a set of TLVs). Each
such TLV is encoded as shown in Figure 1.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| Value +-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Figure 2: UALRT TLV
o Type: A single octet encoding the TLV Type. Only type 1, "UALRT
TLV", is defined in this document. Use of other TLV types is
outside the scope of this document.
o Length: Two octets encoding the length in octets of the TLV,
including the Type and Length fields. The length is encoded as an
unsigned binary integer.
o Value: A field containing eight octets of timestamp.
Zhang & Cheng Expires January 7, 2016 [Page 3]
Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015
This document defines only a single such TLV, the "UALRT TLV". The
UALRT TLV is encoded as follows:
o Type: 1
o Length: 11
o Value: timestamp.
The value field of the UALRT TLV is always 8 octets long, and its
value is interpreted as an unsigned 64-bit integer. The time clock
when the label is assigned are frequently expressed as 4-octet
fragment. By using an 8-octet field, we can be more accurate for
high rate clock.
When an UALRT attribute is created, it SHOULD contain no more than
one UALRT TLV. However, if it contains more than one UALRT TLV, only
the first one is used as described the generation of routes.
2.1. Applicability Restriction and Cautions
The documents only consider the use of UALRT attribute in MVPN
networks, the interconnection of data center, BIER, etc, where the
PEs generate upstream-assigned label for multicast routes.
2.2. Handing a malformed UALRT Attribute
When receiving a BGP Update message which contains a malformed UALRT
attribute, the attribute should be treated as if it was an
unrecognized non-transitive attribute. That is, it MUST be quietly
ignored and not passed along to other BGP peers.
If the UALRT attribute is received and its value is set to 0x0 or the
maximum value of 0xFFFFFFFFFFFFFFFF, the attribute should be
considered to be malformed and SHOULD be ignored.
2.3. Restriction
In this document we discuss the UALRT attribute should be used in
intranet of network. The use of UALRT attribute across multi-ASs May
be out of the scope of this document.
3. Originating and Sending the UALRT attribute
When a PE decides to generate a UALRT attribute for multicast routes
with upstream-assigned label, the PE should set the value of UALRT to
the time when the route is generated. The PE sends the route with
UALRT attribute and other attributes to other PEs to let all the PEs
Zhang & Cheng Expires January 7, 2016 [Page 4]
Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015
receive the routes with UALRT attribute. The UALRT attribute MUST be
transferred by RR. To avoid all the PEs to generate label in the
first label space, each PE SHOULD start assign the label with a
random offset.
4. Receiving the UALRT attribute
When a PE received an upstream-assigned label multicast routes, it
will check if there is a BGP UALRT attribute. If the UALRT value is
correct, the PE will store the route with the UALRT. Then PE will
check if the label is conflict with any exist upstream-assigned
label, include the lable generated by the PE or other PEs. If there
is a collision, the PE MUST choose the one which timestamp was
earlier as the legal route. If the timestamp of two conflict routes
are equal, the PE will use the BGP peer address to judge which one is
legal. The PE SHOULD choose the one which was advertised by the peer
with smaller BGP peer address or larger BGP peer address.
If the other conflict label is generated by the PE itself, the PE
will adjust the upstream-assigned label to other value, and the PE
MUST re-advertise a route with new label and new UALRT attribute. If
the other conflict route was not generated by the PE itself, the PE
will do nothing until other PE re-advertise a route with new
upstream-assigned label and the UALRT attribute. When the PE
receives route with new upstream-assigned label and the UALRT
attribute, the PE will repeat the store and conflict check function.
5. Security Considerations
For general BGP Security Considerations.
6. IANA Considerations
IANA is requested to allocate BGP path attribute for UALRT TLVs.
7. Normative References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
Zhang & Cheng Expires January 7, 2016 [Page 5]
Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015
[RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro,
J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, February 2015.
Authors' Addresses
Sandy Zhang
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing 210000
China
Phone: +86-025-88014634
Email: zhang.zheng@zte.com.cn
Ying Cheng
China Unicom
Beijing
China
Phone: +86-10-68799999-7702
Email: chengying10@chinaunicom.cn
Zhang & Cheng Expires January 7, 2016 [Page 6]