idnits 2.17.1 draft-chen-ospf-source-identifier-distribution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2014) is 3482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 81 -- Looks like a reference, but probably isn't: '65535' on line 81 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) == Outdated reference: A later version (-06) exists of draft-chen-mpls-source-label-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft Huawei 4 Intended status: Standards Track G. Mirsky 5 Expires: April 16, 2015 Ericsson 6 October 13, 2014 8 Extensions to OSPF for Source Identifier Distribution 9 draft-chen-ospf-source-identifier-distribution-00 11 Abstract 13 A Source Identifier (SI) is carried in an MPLS Source Label and used 14 to identify (one of) the ingress LSR(s) to a specific LSP. This 15 document defines extensions to OSPF protocol for distribution of the 16 correlation of a SI to an specific LSR. Therefore, the egress and 17 intermediate LSRs can determine from which LSR an MPLS packet is 18 sent. 20 This document also defines OSPF extensions to advertise the Source 21 Label Capability (SLC) of each LSR that indicates whether an LSR can 22 properly process the Source Label Indicator (SLI) special purpose 23 label and Source Label (SL). With the SLC, an ingress LSR can 24 determine whether it is allowed to insert a SL into the label stack 25 for a specific LSP. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 16, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . . . 3 69 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 3 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 75 7.2. Informative References . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 78 1. Introduction 80 As defined in [I-D.chen-mpls-source-label], a Source Identifier (SI) 81 is a number in the range of [16, 65535]. Each node in a domain will 82 be allocated one or more unique SIs. A SI is carried in an 83 MultiProtocol Label Switching (MPLS) Source Label (SL) and used to 84 identify (one of) the ingress Label Switching Router (LSR) to a 85 specific Label Switched Path (LSP). 87 To identify from where an MPLS packet is sent, the egress/ 88 intermediate LSRs need to know to which ingress LSR a SI is 89 correlated. Therefore, a mechanism to distribute the correlation of 90 a SI to its correlated LSR is required. 92 In addition, for an ingress LSR, before inserting a SL in the label 93 stack of an LSP, it needs to know whether the egress LSR has the 94 capability to process the SLI and SL, otherwise the packet will be 95 dropped at the egress LSR. The capability is called Source Label 96 Capability (SLC). 98 This document defines extensions to OSPF protocol to distribute SI to 99 LSR mapping and advertise the SLC of each LSR. 101 2. Extensions to OSPF 103 The Source Identifier TLV is defined to distribute the SI(s) to 104 ingress LSR mapping information and the SLC. No sub-TLV is currently 105 defined for the Source Identifier TLV. 107 The Source Identifier TLV is advertised in an OSPF Router Information 108 (RI) [RFC4790] Link State Advertisement (LSA), it has the following 109 format: 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Type | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Router ID | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Reserved | Source Identifier 1 | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 ~ ... ~ 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Reserved | Source Identifier n | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1 - OSPF Source Identifier TLV format 127 The value of "Type" field is TBD1. 129 The "Length" field defines the length of the Reserved and Source 130 Identifier fields in octets, which excludes the Router ID field. 132 Each "Source Identifier" field (20 bits) contains a SI that 133 identifies the advertising LSR. 135 The "Reserved" field MUST be set to zero when sending and MUST be 136 ignored when received. 138 3. Elements of Procedure 140 The Source Identifier TLV is carried in the OSPF Router Information 141 (RI) LSA that is defined in [RFC4790]. All the procedures that 142 defined in [RFC4790] are inherited here. 144 The flooding scope of the Source Identifier TLV can be either area 145 local or entire OSPF domain. The flooding scope is controlled by the 146 Opaque LSA type in OSPFv2 [RFC2370] and by the S1 and S2 bits in 147 OSPFv3 [RFC2740]. If the flooding scope is area local, the Source 148 Identifier TLV MUST be carried within an OSPFv2 Type 10 RI LSA or 149 within an OSPFv3 RI LSA with the S1 bit set and the S2 bit clear. If 150 the flooding scope is the entire IGP domain, the Source Identifier 151 TLV MUST be carried within an OSPFv2 Type 11 RI LSA or within an 152 OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. 154 The Source Identifier TLV is an optional TLV. Upon receipt the TLV, 155 a router will silently ignore the TLV as defined in [RFC4790] if it 156 does not support it. If Source Identifier TLV is not present that 157 MUST be interpreted as signaling of non-support of SLC by the LSR. 158 Presence of a Source Identifier TLV MUST be interpreted as support of 159 SLC by the LSR. A Source Identifier TLV MUST appear only one time in 160 an LSA. When received, only first Source Identifier TLV is valid, 161 subsequent Source Identifier TLVs MUST be ignored. 163 4. IANA Considerations 165 IANA is requested to assign a new TLV code point for the Source 166 Identifier TLV carried within the Router Information LSA. 168 Type Value TLV Name Reference 169 ---------- ------------------ -------------- 170 TBD1 Source Identifier (this document) 172 5. Security Considerations 174 TBD. 176 6. Acknowledgements 178 7. References 180 7.1. Normative References 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, March 1997. 185 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 186 1998. 188 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 189 2740, December 1999. 191 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 192 Application Protocol Collation Registry", RFC 4790, March 193 2007. 195 7.2. Informative References 197 [I-D.chen-mpls-source-label] 198 Chen, M., Xu, X., Li, Z., Fang, L., and G. Mirsky, 199 "MultiProtocol Label Switching (MPLS) Source Label", 200 draft-chen-mpls-source-label-05 (work in progress), July 201 2014. 203 Authors' Addresses 205 Mach(Guoyi) Chen 206 Huawei 208 Email: mach.chen@huawei.com 210 Greg Mirsky 211 Ericsson 213 Email: Gregory.mirsky@ericsson.com