idnits 2.17.1 draft-chen-isis-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 3726 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 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-06) exists of draft-chen-mpls-source-label-01 Summary: 1 error (**), 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 ISIS for Source Label Distribution 9 draft-chen-isis-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 ISIS 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 ISIS 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 ISIS . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 ISIS [RFC1195] protocol to 93 distribute SL to LSR mapping and advertise the SLC of each LSR. 95 2. Extensions to ISIS 97 The Source Label sub-TLV is used to distribute the Source Label to 98 LSR mapping and the SLC. The Source Label sub-TLV is advertised 99 within an IS-IS CAPABILITY TLV that is defined in [RFC4971], it has 100 the following format: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type | Length | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | System ID | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | System ID(cond.) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Reserved | Source Label | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1 - ISIS Source Label sub-TLV format 116 The value of Type field is TBD1. 118 The Length field defines the length of the Reserved and Source Label 119 in octets, the value is 4. 121 The Source Label field contains the Source Label that identifies the 122 advertising LSR. 124 3. Elements of Procedure 126 The Source Label sub-TLV is carried within an IS-IS CAPABILITY TLV 127 defined in [RFC4971]. All the procedures that defined in [RFC4971] 128 are inherited here. 130 The flooding scope of the Source Label sub-TLV can be either area 131 local or entire IGP domain. The flooding scope is controlled by the 132 S flag in the IS-IS Router Capability TLV [RFC4971]. If the flooding 133 scope is area local, the Source Label sub-TLV MUST be carried within 134 an IS-IS Router Capability TLV with the S flag clear. If the 135 flooding scope is the entire IGP domain, the Source Label sub-TLV 136 MUST be carried within an IS-IS Router Capability TLV with the S flag 137 set. 139 The Source Label sub-TLV is an optional sub-TLV. Upon receipt the 140 sub-TLV, a router will silently ignore the sub-TLV as defined in 141 [RFC4971] if it does not support it. If Source Label sub-TLV is not 142 present that MUST be interpreted as signaling of non-support of SLC 143 by the LSR. Presence of a Source Label sub-TLV MUST be interpreted 144 as support of SLC by the LSR. A Source Label sub-TLV MUST appear 145 only one time in an LSP. 147 4. IANA Considerations 149 IANA is requested to assign a new sub-TLV code point for the Source 150 Label sub-TLV carried within the IS-IS Router Capability TLV. 152 Type Value TLV Name Reference 153 ---------- --------------- -------------- 154 TBD1 Source Label (this document) 156 5. Security Considerations 158 TBD. 160 6. Acknowledgements 162 7. References 164 7.1. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, March 1997. 169 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 170 System to Intermediate System (IS-IS) Extensions for 171 Advertising Router Information", RFC 4971, July 2007. 173 7.2. Informative References 175 [I-D.chen-mpls-source-label] 176 Chen, M., Building, K., Li, Z., and L. Fang, 177 "MultiProtocol Label Switching (MPLS) Source Label", 178 draft-chen-mpls-source-label-01 (work in progress), 179 October 2013. 181 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 182 dual environments", RFC 1195, December 1990. 184 Authors' Addresses 186 Mach(Guoyi) Chen 187 Huawei 189 Email: mach.chen@huawei.com 190 Greg Mirsky 191 Ericsson 193 Email: Gregory.mirsky@ericsson.com