draft-ietf-idr-bgpls-segment-routing-epe-07.txt   draft-ietf-idr-bgpls-segment-routing-epe-08.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: August 12, 2017 S. Ray Expires: August 19, 2017 K. Patel
Individual Contributor Arrcus, Inc.
K. Patel
Individual
J. Dong J. Dong
M. Chen M. Chen
Huawei Technologies Huawei Technologies
February 8, 2017 February 15, 2017
Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Segment Routing BGP Egress Peer Engineering BGP-LS Extensions
draft-ietf-idr-bgpls-segment-routing-epe-07 draft-ietf-idr-bgpls-segment-routing-epe-08
Abstract Abstract
Segment Routing (SR) leverages source routing. A node steers a Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any prepending the packet with an SR header. A segment can represent any
instruction, topological or service-based. SR allows to enforce a instruction, topological or service-based. SR allows to enforce a
flow through any topological path and service chain while maintaining flow through any topological path and service chain while maintaining
per-flow state only at the ingress node of the SR domain. per-flow state only at the ingress node of the SR domain.
skipping to change at page 2, line 12 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2017. This Internet-Draft will expire on August 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 4
6.3. Peer Node Segment for Node H . . . . . . . . . . . . . . 14 6.3. Peer Node Segment for Node H . . . . . . . . . . . . . . 14
6.4. Peer Node Segment for Node E . . . . . . . . . . . . . . 14 6.4. Peer Node Segment for Node E . . . . . . . . . . . . . . 14
6.5. Peer Adjacency Segment for Node E, Link 1 . . . . . . . . 15 6.5. Peer Adjacency Segment for Node E, Link 1 . . . . . . . . 15
6.6. Peer Adjacency Segment for Node E, Link 2 . . . . . . . . 15 6.6. Peer Adjacency Segment for Node E, Link 2 . . . . . . . . 15
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 17 8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 17
8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 17 8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 17
9. Manageability Considerations . . . . . . . . . . . . . . . . 18 9. Manageability Considerations . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Segment Routing (SR) leverages source routing. A node steers a Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any prepending the packet with an SR header. A segment can represent any
skipping to change at page 18, line 24 skipping to change at page 18, line 24
+---------------------------------------+ +---------------------------------------+
| Codepoint | Description | | Codepoint | Description |
+---------------------------------------+ +---------------------------------------+
| TBD4 | Peer-Node-SID | | TBD4 | Peer-Node-SID |
| TBD5 | Peer-Adj-SID | | TBD5 | Peer-Adj-SID |
| TBD6 | Peer-Set-SID | | TBD6 | Peer-Set-SID |
+------------+--------------------------+ +------------+--------------------------+
9. Manageability Considerations 9. Manageability Considerations
TBD This BGP-LS ([RFC7752]) extensions that are described in this
document consists of additional BGP-LS descriptors and TLVs that will
follow the same manageability functions of BGP-LS, described in
[RFC7752].
The operator MUST be capable of configuring, enabling, disabling the
advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer-
Set-SID as well as to control which information is advertised to
which internal or external peer. This is not different from what is
required by a BGP speaker in terms of information origination and
advertisement. In addition, the advertisement of EPE information
MUST conform to standard BGP advertisement and propagation rules
(iBGP, eBGP, Route-Reflectors, Confederations).
10. Security Considerations 10. Security Considerations
[RFC7752] defines BGP-LS NLRIs to which the extensions defined in [RFC7752] defines BGP-LS NLRIs to which the extensions defined in
this document apply. this document apply.
The Security Section of [RFC7752] also applies to: The Security Section of [RFC7752] also applies to:
o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP-
Confederation-Member; Confederation-Member;
o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer-
Set-SID. Set-SID.
11. Contributors 11. Contributors
Acee Lindem gave a substantial contribution to this document. Saikat Ray and Acee Lindem gave a substantial contribution to this
document.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Jakob Heitz, Howard Yang, Hannes The authors would like to thank Jakob Heitz, Howard Yang, Hannes
Gredler, Peter Psenak, Ketan Jivan Talaulikar, and Arjun Sreekantiah Gredler, Peter Psenak, Ketan Jivan Talaulikar, and Arjun Sreekantiah
for their feedback and comments. for their feedback and comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
skipping to change at page 20, line 27 skipping to change at page 20, line 39
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Saikat Ray
Individual Contributor
Email: raysaikat@gmail.com
Keyur Patel Keyur Patel
Individual Arrcus, Inc.
Email: Keyur@arrcus.com
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Mach (Guoyi) Chen Mach (Guoyi) Chen
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
 End of changes. 11 change blocks. 
17 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/