idnits 2.17.1 draft-chen-ospf-source-label-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 (February 13, 2014) is 3722 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) ** 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-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: August 17, 2014 Ericsson 6 February 13, 2014 8 Extensions to OSPF for Source Label Distribution 9 draft-chen-ospf-source-label-distribution-00 11 Abstract 13 An MPLS Source Label (SL) is defined to identify a node that is (one 14 of) the ingress LSRs to a specific LSP. This document defines 15 extensions to OSPF protocol for distribution of the mapping of an 16 MPLS Source Label 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 process the Source Label. With the SLC, an ingress LSR can determine 23 whether it is allowed to insert a Source Label into the label stack 24 for a specific LSP. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 17, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . . . 3 68 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 3 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 74 7.2. Informative References . . . . . . . . . . . . . . . . . 4 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 The MPLS Source Label is defined in [I-D.chen-mpls-source-label], it 80 is used to identify (one of) the ingress LSR(s) of an LSP. To 81 identify from where an MPLS packet is sent, a pure Source Label (SL) 82 is not enough, it needs to know to which LSR a SL is correlated. 83 Therefore, there needs a mechanism to distribute the mapping 84 information between a SL and its correlated LSR. 86 In addition, for an ingress LSR, before inserting a SL in the label 87 stack of an LSP, it needs to know whether the egress LSR has the 88 capability to process the SL, otherwise the packet will be dropped at 89 the egress LSR. The capability is called Source Label Capability 90 (SLC). 92 This document defines extensions to OSPF protocol to distribute SL to 93 LSR mapping and advertise the SLC of each LSR. 95 2. Extensions to OSPF 97 The Source Label TLV is defined to distribute the Source Label to 98 ingress LSR mapping information and the SLC. No sub-TLV is currently 99 defined for the Source Label TLV. 101 The Source Label TLV is advertised in an OSPF Router Information (RI) 102 [RFC4790] Link State Advertisement (LSA), it has the following 103 format: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Type | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Router ID | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Reserved | Source Label | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Figure 1 - OSPF Source Label TLV format 117 The value of Type field is TBD1. 119 The Length field defines the length of the Reserved and Source Label 120 in octets, the value is 4. 122 The Source Label field contains the Source Label that identifies the 123 advertising LSR. 125 3. Elements of Procedure 127 The Source Label TLV is carried in the OSPF Router Information (RI) 128 LSAs that is defined in [RFC4790]. All the procedures that defined 129 in [RFC4790] are inherited here. 131 The flooding scope of the Source Label TLV can be either area local 132 or entire OSPF domain. The flooding scope is controlled by the 133 Opaque LSA type in OSPFv2 [RFC2370] and by the S1 and S2 bits in 134 OSPFv3 [RFC2740]. If the flooding scope is area local, the Source 135 Label TLV MUST be carried within an OSPFv2 Type 10 RI LSA or within 136 an OSPFv3 RI LSA with the S1 bit set and the S2 bit clear. If the 137 flooding scope is the entire IGP domain, the Source Label TLV MUST be 138 carried within an OSPFv2 Type 11 RI LSA or within an OSPFv3 RI LSA 139 with the S1 bit clear and the S2 bit set. 141 The Source Label TLV is an optional TLV. Upon receipt the TLV, a 142 router will silently ignore the TLV as defined in [RFC4790] if it 143 does not support it. If Source Label TLV is not present that MUST be 144 interpreted as signaling of non-support of SLC by the LSR. Presence 145 of a Source Label TLV MUST be interpreted as support of SLC by the 146 LSR. A Source Label TLV MUST appear only one time in an LSA. 148 4. IANA Considerations 150 IANA is requested to assign a new TLV code point for the Source Label 151 TLV carried within the Router Information LSA. 153 Type Value TLV Name Reference 154 ---------- --------------- -------------- 155 TBD1 Source Label (this document) 157 5. Security Considerations 159 TBD. 161 6. Acknowledgements 163 7. References 165 7.1. Normative References 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 171 1998. 173 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 174 2740, December 1999. 176 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 177 Application Protocol Collation Registry", RFC 4790, March 178 2007. 180 7.2. Informative References 182 [I-D.chen-mpls-source-label] 183 Chen, M., Building, K., Li, Z., and L. Fang, 184 "MultiProtocol Label Switching (MPLS) Source Label", 185 draft-chen-mpls-source-label-01 (work in progress), 186 October 2013. 188 Authors' Addresses 190 Mach(Guoyi) Chen 191 Huawei 193 Email: mach.chen@huawei.com 195 Greg Mirsky 196 Ericsson 198 Email: Gregory.mirsky@ericsson.com