draft-ietf-ospf-encapsulation-cap-04.txt   draft-ietf-ospf-encapsulation-cap-05.txt 
OSPF Working Group X. Xu, Ed. OSPF Working Group X. Xu, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track B. Decraene, Ed. Intended status: Standards Track B. Decraene, Ed.
Expires: December 25, 2017 Orange Expires: January 4, 2018 Orange
R. Raszuk R. Raszuk
Bloomberg LP Bloomberg LP
L. Contreras L. Contreras
Telefonica I+D Telefonica I+D
L. Jalil L. Jalil
Verizon Verizon
June 23, 2017 July 3, 2017
Advertising Tunneling Capability in OSPF Advertising Tunneling Capability in OSPF
draft-ietf-ospf-encapsulation-cap-04 draft-ietf-ospf-encapsulation-cap-05
Abstract Abstract
Networks use tunnels for a variety of reasons. A large variety of Networks use tunnels for a variety of reasons. A large variety of
tunnel types are defined and the ingress needs to select a type of tunnel types are defined and the ingress needs to select a type of
tunnel which is supported by the egress and itself. This document tunnel which is supported by the egress and itself. This document
defines how to advertise egress tunnel capabilities in OSPF Router defines how to advertise egress tunnel capabilities in OSPF Router
Information Link State Advertisement (LSAs). Information Link State Advertisement (LSAs).
Requirements Language Requirements Language
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 December 25, 2017. This Internet-Draft will expire on January 4, 2018.
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 2, line 34 skipping to change at page 2, line 34
3. Advertising Encapsulation Capability . . . . . . . . . . . . 3 3. Advertising Encapsulation Capability . . . . . . . . . . . . 3
4. Tunnel Encapsulation Type . . . . . . . . . . . . . . . . . . 4 4. Tunnel Encapsulation Type . . . . . . . . . . . . . . . . . . 4
5. Tunnel Encapsulation Attribute . . . . . . . . . . . . . . . 4 5. Tunnel Encapsulation Attribute . . . . . . . . . . . . . . . 4
6. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 5 6. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 5
6.1. Encapsulation Sub-TLV . . . . . . . . . . . . . . . . . . 5 6.1. Encapsulation Sub-TLV . . . . . . . . . . . . . . . . . . 5
6.2. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . . . 5 6.2. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . . . 5
6.3. Endpoint Sub-TLV . . . . . . . . . . . . . . . . . . . . 5 6.3. Endpoint Sub-TLV . . . . . . . . . . . . . . . . . . . . 5
6.4. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 6.4. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5
6.5. IP QoS Field . . . . . . . . . . . . . . . . . . . . . . 6 6.5. IP QoS Field . . . . . . . . . . . . . . . . . . . . . . 6
6.6. UDP Destination Port . . . . . . . . . . . . . . . . . . 6 6.6. UDP Destination Port . . . . . . . . . . . . . . . . . . 6
6.7. future sub-TLV allocations . . . . . . . . . . . . . . . 6
7. Usage of the Tunnel Encapsulation attribute . . . . . . . . . 6 7. Usage of the Tunnel Encapsulation attribute . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. OSPF Router Information . . . . . . . . . . . . . . . . . 6 8.1. OSPF Router Information . . . . . . . . . . . . . . . . . 7
8.2. IGP Tunnel Encapsulation Attribute Types Registry . . . . 6 8.2. IGP Tunnel Encapsulation Attribute Sub-TLVs Registry . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Networks use tunnels for a variety of reasons, such as: Networks use tunnels for a variety of reasons, such as:
o Partial deployment of MPLS-SPRING as described in o Partial deployment of MPLS-SPRING as described in
skipping to change at page 5, line 28 skipping to change at page 5, line 28
6.1. Encapsulation Sub-TLV 6.1. Encapsulation Sub-TLV
This Sub-TLV is defined in section 3.2 "Encapsulation Sub-TLVs for This Sub-TLV is defined in section 3.2 "Encapsulation Sub-TLVs for
Particular Tunnel Types" of [I-D.ietf-idr-tunnel-encaps] from both a Particular Tunnel Types" of [I-D.ietf-idr-tunnel-encaps] from both a
syntax and semantic standpoint. Usage is defined in Section 7. syntax and semantic standpoint. Usage is defined in Section 7.
6.2. Protocol Type Sub-TLV 6.2. Protocol Type Sub-TLV
This Sub-TLV is defined in section 3.4.1 "Protocol Type sub-TLV" of This Sub-TLV is defined in section 3.4.1 "Protocol Type sub-TLV" of
[I-D.ietf-idr-tunnel-encaps] from a syntax, semantic and usage [I-D.ietf-idr-tunnel-encaps] from a syntactic, semantic, and usage
standpoint. standpoint.
6.3. Endpoint Sub-TLV 6.3. Endpoint Sub-TLV
The value field carries the Network Address to be used as tunnel The value field carries the Network Address to be used as tunnel
destination address. destination address.
If length is 4, the tunnel endpoint is an IPv4 address. If length is 4, the tunnel endpoint is an IPv4 address.
If length is 16, the tunnel endpoint is an IPv6 address. If length is 16, the tunnel endpoint is an IPv6 address.
6.4. Color Sub-TLV 6.4. Color Sub-TLV
The valued field is a 4-octet opaque unsigned integer. The valued field is a 4-octet opaque unsigned integer.
The color value is user defined and configured locally on the The color value is user-defined and configured locally on the
advertising routers. It may be used by service providers to define advertising routers. It may be used by service providers to define
policies on the ingress routers, for example to control the selection policies on the ingress routers, for example, to control the
of the tunnel to use. selection of the tunnel to use.
This color value can be referenced by BGP routes carrying Color This color value can be referenced by BGP routes carrying Color
Extended Community [I-D.ietf-idr-tunnel-encaps]. If the tunnel is Extended Community [I-D.ietf-idr-tunnel-encaps]. If the tunnel is
used to reach the BGP Next-Hop of BGP routes, then attaching a Color used to reach the BGP Next-Hop of BGP routes, then attaching a Color
Extended Community attached to those routes, express the willing of Extended Community attached to those routes express the willingness
the BGP speaker to use a tunnel of the same color. of the BGP speaker to use a tunnel of the same color.
6.5. IP QoS Field 6.5. IP QoS Field
This Sub-TLV is defined in section 3.3.1 "IPv4 DS Field" of This Sub-TLV is defined in section 3.3.1 "IPv4 DS Field" of
[I-D.ietf-idr-tunnel-encaps] from a syntax, semantic and usage [I-D.ietf-idr-tunnel-encaps] from a syntactic, semantic and usage
standpoint. standpoint.
6.6. UDP Destination Port 6.6. UDP Destination Port
This Sub-TLV is defined in section 3.3.2 "IPv4 DS Field" of This Sub-TLV is defined in section 3.3.2 "UDP Destination Port" of
[I-D.ietf-idr-tunnel-encaps] from a syntax, semantic and usage [I-D.ietf-idr-tunnel-encaps] from a syntactic, semantic and usage
standpoint. standpoint.
6.7. future sub-TLV allocations
[I-D.ietf-idr-tunnel-encaps] similarly defines Tunnel Encapsulation
Attribute Sub-TLVs. IGP and BGP have separate IANA registries
allowing for separate sub-TLV definitions. If the same information
is to be advertised for both IGP and BGP tunnel encapsulation, it is
RECOMMENDED to use the same code point, semantic and syntax.
However, it is to be noted that the "BGP Tunnel Encapsulation
Attribute Sub-TLVs" registry, allows for sub-TLV with two octets of
length, while the "IGP Tunnel Encapsulation Attribute Sub-TLVs"
registry only allows for one octet of length. Hence two-octets BGP
Tunnel Encapsulation Attribute Sub-TLVs won't be able to be defined
for IGP Tunnels. Eventually, their information may be split over
multiple sub-TLVs.
7. Usage of the Tunnel Encapsulation attribute 7. Usage of the Tunnel Encapsulation attribute
The advertisement of a Encapsulation Type Sub-TLVs indicates that the The advertisement of an Encapsulation Type Sub-TLVs indicates that
advertising router support a particular tunnel encapsulation along the advertising router support a particular tunnel encapsulation
with the parameters to be used for the tunnel. The decision to use along with the parameters to be used for the tunnel. The decision to
that tunnel, is driven by policy on the ingress router. The color use that tunnel is driven by the capability of the ingress router to
sub-TLV may be used as an input to this policy. Note that some support the encapsulation type and the policy on the ingress router.
tunnel types may require the execution of an explicit tunnel setup The color sub-TLV may be used as an input to this policy. Note that
protocol before they can be used to carry data. some tunnel types may require the execution of an explicit tunnel
setup protocol before they can be used to carry data.
A tunnel MUST NOT be used if there is no route toward the IP address A tunnel MUST NOT be used if there is no route toward the IP address
specified in the Endpoint Sub-TLV or if the route is not advertised specified in the Endpoint Sub-TLV or if the route is not advertised
by the router advertising the Tunnel Encapsulation attribute by the router advertising the Tunnel Encapsulation attribute for the
advertising this tunnel. tunnel.
8. IANA Considerations 8. IANA Considerations
8.1. OSPF Router Information 8.1. OSPF Router Information
This document requests IANA to allocate a new code point from the This document requests IANA to allocate a new code point from the
OSPF Router Information (RI) registry. OSPF Router Information (RI) registry.
Value TLV Name Reference Value TLV Name Reference
----- ------------------------------------ ------------- ----- ------------------------------------ -------------
TBD1 Tunnel Capabilities This document TBD1 Tunnel Capabilities This document
8.2. IGP Tunnel Encapsulation Attribute Types Registry 8.2. IGP Tunnel Encapsulation Attribute Sub-TLVs Registry
This document requests IANA to create a new registry "IGP Tunnel This document requests IANA to create a new registry "IGP Tunnel
Encapsulation Attribute Types" with the following registration Encapsulation Attribute Sub-TLVs" with the following registration
procedure: procedure:
Registry Name: IGP Tunnel Encapsulation Attribute Types Registry Name: IGP Tunnel Encapsulation Attribute Sub-TLVs
Value Name Reference Value Name Reference
------- ------------------------------------ ------------- ------- ------------------------------------ -------------
0 Reserved This document 0 Reserved This document
1 Encapsulation This document 1 Encapsulation This document
2 Protocol Type This document 2 Protocol Type This document
3 Endpoint This document 3 Endpoint This document
4 Color This document 4 Color This document
5 Unassigned 5 Unassigned
6 IP QoS This document 6 IP QoS This document
skipping to change at page 7, line 52 skipping to change at page 8, line 21
Huawei Huawei
Email: uma.chunduri@gmail.com Email: uma.chunduri@gmail.com
11. Acknowledgements 11. Acknowledgements
This document is partially inspired by [RFC5512]. This document is partially inspired by [RFC5512].
The authors would like to thank Greg Mirsky, John E Drake, Carlos The authors would like to thank Greg Mirsky, John E Drake, Carlos
Pignataro and Karsten Thomann for their valuable comments on this Pignataro and Karsten Thomann for their valuable comments on this
document. Special thanks should be given to Acee Lindem for his document. Special thanks should be given to Acee Lindem for his
detailed review of this document. detailed reviews of this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-06 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-06
(work in progress), June 2017. (work in progress), June 2017.
skipping to change at page 8, line 49 skipping to change at page 9, line 23
Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Explicit Replication in MPLS and non-MPLS Networks", Explicit Replication in MPLS and non-MPLS Networks",
draft-ietf-bier-mpls-encapsulation-07 (work in progress), draft-ietf-bier-mpls-encapsulation-07 (work in progress),
June 2017. June 2017.
[I-D.xu-mpls-unified-source-routing-instruction] [I-D.xu-mpls-unified-source-routing-instruction]
Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras,
L., Jalil, L., Assarpour, H., Velde, G., Tantsura, J., and L., Jalil, L., Assarpour, H., Velde, G., Tantsura, J., and
S. Ma, "Unified Source Routing Instruction using MPLS S. Ma, "Unified Source Routing Instruction using MPLS
Label Stack", draft-xu-mpls-unified-source-routing- Label Stack", draft-xu-mpls-unified-source-routing-
instruction-01 (work in progress), June 2017. instruction-02 (work in progress), June 2017.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>. <http://www.rfc-editor.org/info/rfc5340>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
 End of changes. 21 change blocks. 
32 lines changed or deleted 49 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/