idnits 2.17.00 (12 Aug 2021) /tmp/idnits20025/draft-vandevelde-sfc-nsh-length-overload-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 17, 2016) is 2035 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) == Unused Reference: '2' is defined on line 168, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Working Group G. Van de Velde, Ed. 3 Internet-Draft M. Vigoureux 4 Intended status: Standards Track P. Mulay 5 Expires: April 20, 2017 Nokia 6 October 17, 2016 8 Network Services Header Context Allocation Identifier 9 draft-vandevelde-sfc-nsh-length-overload-00 11 Abstract 13 The specification of the NSH MD Type 1 header [draft-ietf-sfc-nsh] 14 mandates four Context Headers, 4-byte each, and they MUST be added 15 immediately following the Service Path Header. As direct 16 consequence, an NSH MD Type 1 header is always Length 0x6 (six 4-byte 17 words). As a result, the Length field of the NSH MD Type 1 header 18 provides an information which is known by simply looking at the "MD 19 Type" field. However, while [draft-ietf-sfc-nsh] does not specify 20 the encoding of these Context Headers, other specifications have 21 started to do so. A need to distinguish types of Context Headers 22 therefore arises. 24 This draft proposes to overload the Length field of an NSH MD Type 1 25 as Meta-Data context allocation identifier and to create a IANA 26 repository for NSH MD Type 1 allocation schemes. The NSH MD Type 1 27 Length field overload intends to allow universal understanding at any 28 network location and by any network device of the context allocation 29 structure. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [1]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 20, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 74 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 78 6.2. Informative References . . . . . . . . . . . . . . . . . 4 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 81 1. Introduction 83 The specification of the NSH MD Type 1 header [draft-ietf-sfc-nsh] 84 mandates four Context Headers, 4-byte each, and they MUST be added 85 immediately following the Service Path Header. As direct 86 consequence, an NSH MD Type 1 header is always Length 0x6 (six 4-byte 87 words). As a result, the Length field of the NSH MD Type 1 header 88 provides an information which is known by simply looking at the "MD 89 Type" field. However, while [draft-ietf-sfc-nsh] does not specify 90 the encoding of these Context Headers, other specifications have 91 started to do so. A need to distinguish types of Context Headers 92 therefore arises. 94 This draft proposes to overload the Length field of an NSH MD Type 1 95 as Meta-Data context allocation identifier and to create a IANA 96 repository for NSH MD Type 1 allocation schemes. The NSH MD Type 1 97 Length field overload intends to allow universal understanding at any 98 network location and by any network device of the context allocation 99 structure. 101 The capability of overloading the NSH MD Type 1 Length field as 102 context allocation identifier is particular useful in networks 103 environments where multiple different NSH MD Type 1 allocation 104 schemes exist simultaneously. For example in Datacenters where data- 105 flows are serviced and allocations are based upon either [draft- 106 guichard-sfc-nsh-dc-allocation] or [draft-napper-sfc-nsh-broadband- 107 allocation]. Without Length field overload, it is for a servicing 108 node non-trivial to know how the NSH Meta Data is structured and how 109 the Meta Data should be consumed without provisioning of additional 110 context information to understand the NSH embedded Meta-Data. 112 In addition, this document serves as anchor-point to request an IANA 113 repository for NSH MD Type 1 allocation schemes. 115 2. Operation 117 The Length field in the NSH Base header intends to provide the length 118 of the NSH header including the Base header itself in 4-byte words. 119 According [draft-ietf-sfc-nsh] the NSH MD Type 1 the value within the 120 Length field MUST always be 0x6. 122 This note proposes a different usage for the length field taking 123 backward compatibility into account. This draft proposes to use the 124 Length field of a fixed length NSH MD Type 1 header as indication of 125 the Meta Data allocation scheme. The allocation scheme context 126 overloading of the length field does not modify the fixed length of 127 the NSH MD Type 1 fields and expected Meta Data fields is fixed at 128 four words of 4-byte data. 130 The different from 0x6 value represents the Meta Data allocation 131 scheme used for the NSH MD Type 1 header. To avoid compatibility 132 issues with older NSH MD Type implementations the Length value of 0x6 133 is reserved and allows existing NSH MD Type 1 usage to carry opaque 134 Meta Data. 136 The following MD allocation types have been defined: 138 0x0: draft-guichard-sfc-nsh-dc-allocation 140 0x1: draft-napper-sfc-nsh-broadband-allocation 142 0x6: draft-ietf-sfc-nsh 144 3. Security Considerations 146 tbc 148 4. Acknowledgements 150 tbc 152 5. IANA Considerations 154 This document requests IANA to setup a central repository to keep 155 track of the different NSH MD Type 1 allocation schemes 157 6. References 159 6.1. Normative References 161 [1] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, 163 DOI 10.17487/RFC2119, March 1997, 164 . 166 6.2. Informative References 168 [2] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 169 Chaining (SFC) Architecture", RFC 7665, 170 DOI 10.17487/RFC7665, October 2015, 171 . 173 Authors' Addresses 175 Gunter Van de Velde (editor) 176 Nokia 177 Antwerp 178 Belgium 180 Email: gunter.van_de_velde@nokia.com 182 Martin Vigoureux 183 Nokia 184 Route de Villejust 185 Nozay 91620 186 France 188 Email: martin.vigoureux@nokia.com 189 Praveen Mulay 190 Nokia 191 Mountain View 192 USA 194 Email: praveen.muley@nokia.com