Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-wu-idr-flowspec-rpd-impl-00.txt Дата изменения: Tue Mar 15 12:45:08 2016 Дата индексирования: Sun Apr 10 07:29:26 2016 Кодировка:

Network Working Group N. Wu
Internet-Draft S. Devadiga
Intended status: Informational Huawei
Expires: September 16, 2016 March 15, 2016


Implementation Report for BGP FlowSpec RPD
draft-wu-idr-flowspec-rpd-impl-00

Abstract

BGP FlowSpec Extensions for Routing Policy Distribution (RPD) has
provided a mechanism to use BGP Flowspec address family as routing-
policy distribution protocol.

This document provides an implementation report for RPD mechanism on
inbound-traffic and outbound-traffic adjustment scenarios. What's
more, it gives some details and consideration for exceptions during
development and verification.

Requirements Language

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].

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 September 16, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.




Wu & Devadiga Expires September 16, 2016 [Page 1]

Internet-Draft Implementation of BGP-FS RPD March 2016


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. Implementation Detail . . . . . . . . . . . . . . . . . . . . 2
2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Platforms . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Exception Consideration . . . . . . . . . . . . . . . . . . . 3
3.1. Transitive Wide Community . . . . . . . . . . . . . . . . 4
3.2. Unnecessary Flowspec Population . . . . . . . . . . . . . 4
3.3. Network Route Selection . . . . . . . . . . . . . . . . . 4
4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5

1. Introduction

To facilitate the traffic optimization in a traditional IP network,
an automatic mechanism called BGP Flowspec RPD
[I-D.li-idr-flowspec-rpd] is introduced. This document provides an
implementation report for this RPD mechanism on inbound-traffic and
outbound-traffic adjustment scenarios. What's more, it gives some
details and consideration for exceptions during development and
verification.

2. Implementation Detail

2.1. Roles

o Policy Makers: sender, encode and populate BGP Flowspec routes
based on policies input from manual configuration or automatic
generated rules.




Wu & Devadiga Expires September 16, 2016 [Page 2]

Internet-Draft Implementation of BGP-FS RPD March 2016


o Routers: receiver, decode BGP Flowspec routes from Policy Makers
and behave accordingly.

2.2. Features

o FlowSpec Traffic Actions, covered section 5.1 of
[I-D.li-idr-flowspec-rpd].

o BGP Policy Attribute, NOT covered section 5.2 of
[I-D.li-idr-flowspec-rpd].

o BGP Wide Community, covered section 5.3 of
[I-D.li-idr-flowspec-rpd].

o Capability Negotiation, covered section 5.4 of
[I-D.li-idr-flowspec-rpd].

2.3. Platforms

o VRP

* Release: VRPV800R010C00

* Vendor: Huawei

* Role: Router

* Contact: Eric Wu, Shankara

* Email: eric.wu@huawei.com, shankara@huawei.com

o SNC

* Release: SNCV100R001C50

* Vendor: Huawei

* Role: Policy Maker

* Contact: Eric Wu, Shankara

* Email: eric.wu@huawei.com, shankara@huawei.com

3. Exception Consideration







Wu & Devadiga Expires September 16, 2016 [Page 3]

Internet-Draft Implementation of BGP-FS RPD March 2016


3.1. Transitive Wide Community

As specified in [I-D.ietf-idr-wide-bgp-communities], "The Wide BGP
Community Attribute is an optional, transitive BGP attribute, and may
be present only once in the BGP UPDATE message." In RPD's cases, the
policy maker can only have access to those routers in its domain.
And it is unnecessary and not safe for the border routers(IGW) to
populate RPD route(BGP Flowspec) into another AS. In our
implementation, a "NO_ADVERTISE" community is attached by the policy
maker to make sure that. So in RPD's cases the wide community will
not be "transitive" even when the Flowspec Address Family has been
enabled on the inter-AS session.

3.2. Unnecessary Flowspec Population

In RPD's cases, all border routers (IGW) will get BGP Flowspec routes
update from the policy maker even though only one of them is the real
receiver. Because of BGP's P2MP route population style, IGWs will
receive unnecessary updates which will consume extra resource to
maintain them. In our implementation, more information is attached
with routes to identify who is the corresponding executor. Better
solution SHOULD be sending the route to the real receiver only.

3.3. Network Route Selection

RPD mechanism changes traffic behavior through affecting the decision
in control plane. In both inbound and outbound scenarios, those
newly preferred routes will be propagated to other BGP peers, which
may impact route selection of the whole network in the end. Even
though this is the basic protocol behavior, it may generate
unexpected consequence on network forwarding. Better solution SHOULD
consider how to eliminate this negative impact.

4. Future Work

1. More platform. More implementation will be available on
different platforms, including open source.

2. Interoperability. Plan to do interoperation test on different
platforms when they are ready.

3. Operator Deployment. Operators are interested in testing and
deploy RPD mechanism. Deployment report may be available in
future.







Wu & Devadiga Expires September 16, 2016 [Page 4]

Internet-Draft Implementation of BGP-FS RPD March 2016


5. IANA Considerations

This draft has no request to IANA.

6. Security Considerations

This draft has no security issue introduced.

7. Acknowledgements

The authors would like to thank Weisu Qi, Haijun Xu, Shunwan Zhuang
for their constructive help to this work.

8. References

8.1. Normative References

[I-D.ietf-idr-wide-bgp-communities]
Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B.,
Jakma, P., and R. Steenbergen, "Wide BGP Communities
Attribute", draft-ietf-idr-wide-bgp-communities-01 (work
in progress), November 2015.

[I-D.li-idr-flowspec-rpd]
Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu,
"BGP FlowSpec Extensions for Routing Policy Distribution
(RPD)", draft-li-idr-flowspec-rpd-01 (work in progress),
October 2015.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.

8.2. Informative References

[I-D.ietf-idr-registered-wide-bgp-communities]
Raszuk, R. and J. Haas, "Registered Wide BGP Community
Values", draft-ietf-idr-registered-wide-bgp-communities-01
(work in progress), November 2015.

Authors' Addresses









Wu & Devadiga Expires September 16, 2016 [Page 5]

Internet-Draft Implementation of BGP-FS RPD March 2016


Nan Wu
Huawei
Huawei Campus., No.156 Beiqing Rd.
Beijing 100095
China

Email: eric.wu@huawei.com


Shankara Devadiga
Huawei
Bangalore 560037
India

Email: shankara@huawei.com




































Wu & Devadiga Expires September 16, 2016 [Page 6]