draft-ietf-idr-bgp-ls-segment-routing-ext-09.txt   draft-ietf-idr-bgp-ls-segment-routing-ext-10.txt 
Inter-Domain Routing S. Previdi, Ed. Inter-Domain Routing S. Previdi, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track K. Talaulikar Intended status: Standards Track K. Talaulikar
Expires: April 13, 2019 C. Filsfils Expires: April 22, 2019 C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
M. Chen M. Chen
Huawei Technologies Huawei Technologies
October 10, 2018 October 19, 2018
BGP Link-State extensions for Segment Routing BGP Link-State extensions for Segment Routing
draft-ietf-idr-bgp-ls-segment-routing-ext-09 draft-ietf-idr-bgp-ls-segment-routing-ext-10
Abstract Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths by encoding paths as sequences of topological sub-paths, called paths by encoding paths as sequences of topological sub-paths, called
"segments". These segments are advertised by routing protocols e.g. "segments". These segments are advertised by routing protocols e.g.
by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within
IGP topologies. IGP topologies.
This draft defines extensions to the BGP Link-state address-family in This draft defines extensions to the BGP Link-state address-family in
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 13, 2019. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 45 skipping to change at page 2, line 45
2.3.1. Prefix-SID TLV . . . . . . . . . . . . . . . . . . . 15 2.3.1. Prefix-SID TLV . . . . . . . . . . . . . . . . . . . 15
2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 16 2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 16
2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 17 2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 17
2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 17 2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 19 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 19
2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 20 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 20
3. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 3. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 21 4.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 21
5. Manageability Considerations . . . . . . . . . . . . . . . . 22 5. Manageability Considerations . . . . . . . . . . . . . . . . 22
5.1. Operational Considerations . . . . . . . . . . . . . . . 22
5.2. Management Considerations . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 25
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths by combining sub-paths called "segments". A segment can paths by combining sub-paths called "segments". A segment can
represent any instruction, topological or service-based. A segment represent any instruction, topological or service-based. A segment
can have a local semantic to an SR node or global within a domain. can have a local semantic to an SR node or global within a domain.
Within IGP topologies an SR path is encoded as a sequence of Within IGP topologies an SR path is encoded as a sequence of
topological sub-paths, called "IGP segments". These segments are topological sub-paths, called "IGP segments". These segments are
advertised by the link-state routing protocols (IS-IS, OSPFv2 and advertised by the link-state routing protocols (IS-IS, OSPFv2 and
skipping to change at page 5, line 19 skipping to change at page 5, line 19
collect SR information from across an SR domain and construct the collect SR information from across an SR domain and construct the
end-to-end path (with its associated SIDs) that need to be applied to end-to-end path (with its associated SIDs) that need to be applied to
an incoming packet to achieve the desired end-to-end forwarding. an incoming packet to achieve the desired end-to-end forwarding.
Here the SR domain is defined as a single administrative domain that Here the SR domain is defined as a single administrative domain that
may be comprised of a single AS or multiple ASes under consolidated may be comprised of a single AS or multiple ASes under consolidated
global SID administration. global SID administration.
2. BGP-LS Extensions for Segment Routing 2. BGP-LS Extensions for Segment Routing
This document defines SR extensions to BGP-LS and specifies the TLVs This document defines SR extensions to BGP-LS and specifies the TLVs
and sub-TLVs for advertising SR information. Section 2.4 and and sub-TLVs for advertising SR information within the BGP-LS
Section 2.5 illustrates the equivalent TLVs and sub-TLVs in IS-IS, Attribute. Section 2.4 and Section 2.5 illustrates the equivalent
OSPFv2 and OSPFv3 protocols. TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols.
BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a
Link NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a Link NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a
Node Attribute, a Link Attribute or a Prefix Attribute. BGP-LS Node Attribute, a Link Attribute or a Prefix Attribute. BGP-LS
[RFC7752] defines the TLVs that map link-state information to BGP-LS [RFC7752] defines the TLVs that map link-state information to BGP-LS
NLRI and the BGP-LS attribute. This document adds additional BGP-LS NLRI and the BGP-LS attribute. This document adds additional BGP-LS
attribute TLVs in order to encode SR information. attribute TLVs in order to encode SR information. It does not
introduce any changes to the encoding of the BGP-LS NLRIs.
Some of the TLVs defined in this document contain fields (e.g. flags) Some of the TLVs defined in this document contain fields (e.g. flags)
whose semantics need to be interpreted accordingly to the respective whose semantics need to be interpreted accordingly to the respective
underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the
BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the
NLRI and refer to the underlying protocol specification in order to NLRI and refer to the underlying protocol specification in order to
parse such fields. The individual field descriptions in the sub- parse such fields. The individual field descriptions in the sub-
sections below point to the relevant underlying protocol sections below point to the relevant underlying protocol
specifications for such fields. specifications for such fields.
skipping to change at page 22, line 36 skipping to change at page 22, line 36
5. Manageability Considerations 5. Manageability Considerations
This section is structured as recommended in [RFC5706]. This section is structured as recommended in [RFC5706].
The new protocol extensions introduced in this document augment the The new protocol extensions introduced in this document augment the
existing IGP topology information that was distributed via [RFC7752]. existing IGP topology information that was distributed via [RFC7752].
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the BGP protocol operations and management other than as affect the BGP protocol operations and management other than as
discussed in the Manageability Considerations section of [RFC7752]. discussed in the Manageability Considerations section of [RFC7752].
Specifically, the malformed NLRIs attribute tests for syntactic Specifically, the malformed attribute tests for syntactic checks in
checks in the Fault Management section of [RFC7752] now encompass the the Fault Management section of [RFC7752] now encompass the new BGP-
new TLVs for the BGP-LS NLRI in this document. The semantic or LS Attribute TLVs defined in this document. The semantic or content
content checking for the TLVs specified in this document and their checking for the TLVs specified in this document and their
association with the BGP-LS NLRI types or their BGP-LS Attribute is association with the BGP-LS NLRI types or their BGP-LS Attribute is
left to the consumer of the BGP-LS information (e.g. an application left to the consumer of the BGP-LS information (e.g. an application
or a controller) and not the BGP protocol. or a controller) and not the BGP protocol.
5.1. Operational Considerations A consumer of the BGP-LS information is retrieving this information
from a BGP protocol component that is doing the signaling over a BGP-
No additional operation considerations are defined in this document. LS session, via some APIs or a data model (refer Section 1 and 2 of
[RFC7752]). The handling of semantic or content errors by the
5.2. Management Considerations consumer would be dictated by the nature of its application usage and
hence is beyond the scope of this document. This document only
introduces new Attribute TLVs and an error in them would result in
only that specific attribute being discarded with an error log.
No additional management considerations are defined in this document. The extensions, specified in this document, do not introduce any new
configuration or monitoring aspects in BGP or BGP-LS other than as
discussed in [RFC7752]. The manageability aspects of the underlying
SR features are covered by [I-D.ietf-spring-sr-yang],
[I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang].
6. Security Considerations 6. Security Considerations
The new protocol extensions introduced in this document augment the The new protocol extensions introduced in this document augment the
existing IGP topology information that was distributed via [RFC7752]. existing IGP topology information that was distributed via [RFC7752].
Procedures and protocol extensions defined in this document do not The Security Considerations section of [RFC7752] also applies to
affect the BGP security model other than as discussed in the Security these extensions. The procedures and new TLVs defined in this
Considerations section of [RFC7752]. document, by themselves, do not affect the BGP-LS security model
discussed in [RFC7752].
BGP-LS SR extensions enable traffic engineering use-cases within the
Segment Routing domain. SR operates within a trusted domain (refer
Security Considerations section in [RFC8402] for more detail) and its
security considerations also apply to BGP-LS sessions when carrying
SR information.The SR traffic engineering policies using the SIDs
advertised via BGP-LS are expected to be used entirely within this
trusted SR domain (e.g. between multiple AS/domains within a single
provider network). Therefore, precaution is necessary to ensure that
the SR information collected via BGP-LS is limited to specific
controllers or applications in a secure manner within this SR domain.
The isolation of BGP-LS peering sessions is also required to ensure
that BGP-LS topology information (including the newly added SR
information) is not advertised to an external BGP peering session
outside an administrative domain.
7. Contributors 7. Contributors
The following people have substantially contributed to the editing of The following people have substantially contributed to the editing of
this document: this document:
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
skipping to change at page 25, line 17 skipping to change at page 25, line 37
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <https://www.rfc-editor.org/info/rfc7794>. March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA) F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>. 2018, <https://www.rfc-editor.org/info/rfc8362>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-isis-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J.
Tantsura, "YANG Data Model for IS-IS Segment Routing",
draft-ietf-isis-sr-yang-04 (work in progress), June 2018.
[I-D.ietf-ospf-sr-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"Yang Data Model for OSPF SR (Segment Routing) Protocol",
draft-ietf-ospf-sr-yang-05 (work in progress), July 2018.
[I-D.ietf-spring-segment-routing-ldp-interop] [I-D.ietf-spring-segment-routing-ldp-interop]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP", S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-15 (work in draft-ietf-spring-segment-routing-ldp-interop-15 (work in
progress), September 2018. progress), September 2018.
[I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG
Data Model for Segment Routing", draft-ietf-spring-sr-
yang-09 (work in progress), June 2018.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>. <https://www.rfc-editor.org/info/rfc5706>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
 End of changes. 15 change blocks. 
28 lines changed or deleted 66 lines changed or added

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