idnits 2.17.1 draft-ietf-pwe3-iana-allocation-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 4) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7314 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: 'Note1' on line 80 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-05 == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-sonet-03 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Luca Martini 2 Internet Draft W. Mark Townsley 3 Expiration Date: October 2004 Cisco Systems Inc. 5 April 2004 7 IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) 9 draft-ietf-pwe3-iana-allocation-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Control and maintenance protocol for providing various Layer 1 34 and Layer 2 services over a Packet Switched Network has been 35 described in [1]. This document pre-allocates the fixed Pseudo-wire 36 identifier , and other fixed protocol values that are to be assigned 37 by IANA using the "IETF Consensus" policy defined in RFC2434 39 Table of Contents 41 1 Specification of Requirements .......................... 2 42 2 PW type ................................................ 2 43 3 Interface Parameters field ............................. 3 44 4 LDP Status codes ....................................... 4 45 5 Pseudo Wire Status ..................................... 4 46 6 Security Considerations ................................ 5 47 7 Intellectual Property Disclaimer ....................... 5 48 8 References ............................................. 5 49 9 Author Information ..................................... 5 51 1. Specification of Requirements 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 57 2. PW type 59 As specified in [1], a Virtual Circuit FEC element contains the PW 60 Type field. PW Type value 0 is reserved. PW Type values 1 through 24 61 are defined in this document. PW Type values 25 through 63 are to be 62 assigned by IANA using the "IETF Consensus" policy defined in 63 RFC2434. PW Type values 64 through 127 are to be assigned by IANA, 64 using the "First Come First Served" policy defined in RFC2434. VC 65 Type values 128 through 32767 are vendor-specific, and values in this 66 range are not to be assigned by IANA. 68 The PW Type is 15 bit quantity containing a value which represents 69 the type of PW. Assigned Values are: 71 PW type Description 73 0x0001 Frame Relay DLCI 74 0x0002 ATM AAL5 SDU VCC transport 75 0x0003 ATM transparent cell transport 76 0x0004 Ethernet Tagged Mode 77 0x0005 Ethernet 78 0x0006 HDLC 79 0x0007 PPP 80 0x0008 SONET/SDH Circuit Emulation Service Over MPLS (CEM) [Note1] 81 0x0009 ATM n-to-one VCC cell transport 82 0x000A ATM n-to-one VPC cell transport 83 0x000B IP Layer2 Transport 84 0x000C ATM one-to-one VCC Cell Mode 85 0x000D ATM one-to-one VPC Cell Mode 86 0x000E ATM AAL5 PDU VCC transport 87 0x000F Frame-Relay Port mode 88 0x0010 SONET/SDH Circuit Emulation over Packet (CEP) 89 0x0011 Structure-agnostic E1 over Packet (SAToP) 90 0x0012 Structure-agnostic T1 (DS1) over Packet (SAToP) 91 0x0013 Structure-agnostic E3 over Packet (SAToP) 92 0x0014 Structure-agnostic T3 (DS3) over Packet (SAToP) 93 0x0015 CESoPSN basic mode 94 0x0016 TDMoIP basic mode 95 0x0017 CESoPSN TDM with CAS 96 0x0018 TDMoIP TDM with CAS 98 Note 1: This PW type is grandfathered for a historical protocol. The 99 recommended standards-track protocol to use is CEP (PW type 0x0010). 101 3. Interface Parameters field 103 As specified in [1], a PW FEC element contains the Interface 104 Parameters field, which is a list of one or more parameters, and each 105 parameter is identified by the Parameter ID field. Parameter ID value 106 0 is reserved. Parameter ID values 1 through 11 are defined in this 107 document. Parameter ID values 12 through 63 are to be assigned by 108 IANA using the "IETF Consensus" policy defined in RFC2434. Parameter 109 ID values 64 through 127 are to be assigned by IANA, using the "First 110 Come First Served" policy defined in RFC2434. Parameter ID values 128 111 through 255 are vendor- specific, and values in this range are not to 112 be assigned by IANA. 114 The interface parameter ID is assigned as follows: 115 Parameter ID Length Description 117 0x01 4 Interface MTU in octets 118 0x02 4 Maximum Number of concatenated ATM cells 119 0x03 up to 82 Optional Interface Description string 120 0x04 4 CEP/TDM [2] Payload Bytes 121 0x05 4 CEP options 122 0x06 4 Requested VLAN ID 123 0x07 6 CEP/TDM bit-rate 124 0x08 4 Frame-Relay DLCI Length 125 0x09 4 Fragmentation indicator 126 0x0A 4 FCS retension indicator 127 0x0B 4/8/12 TDM options 128 0x0C 4VCCV parameter 130 Note that the Length field is defined as the length of the interface 131 parameter including the parameter id and length field itself. 133 4. LDP Status codes 135 RFC 3036 has a range of LDP Status Code values which are assigned by 136 IANA through an IETF Consensus action. These are in the range 137 0x00000000-0x1fffffff. To meet the protocol requirements of [1], the 138 following new status codes are defined: 140 0x00000024 "Illegal C-Bit" 141 0x00000025 "Wrong C-Bit" 142 0x00000026 "Incompatible bit-rate" 143 0x00000027 "CEP/TDM mis-configuration" 144 0x00000028 "PW status" 146 RFC 3036 has a range of LTLV type name space values which are assigned by IANA 147 through an IETF Consensus action. the following new code is defined : 148 TLV type Description 149 0x096A PW Status TLV 151 5. Pseudo Wire Status" 153 As specified in [1], a new PW status TLV contains a 32 bit field, PW 154 status value 0 is reserved to clear all failures. PW Status Bits 0 155 through 4 are defined in this document. PW Status Bits 6 through 15 156 are to be assigned by IANA using the "IETF Consensus" policy defined 157 in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA, 158 using the "First Come First Served" policy defined in RFC2434. PW 159 Status Bits 24 through 31 are vendor-specific, and values in this 160 range are not to be assigned by IANA. 162 PW status is a 4 octet bit field as follows: 164 0x00000000 - Pseudo Wire forwarding ( clear all failures ) 165 0x00000001 - Pseudo Wire Not Forwarding 166 0x00000002 - Local Attachement Circuit ( ingress ) Receive Fault 167 0x00000004 - Local Attachement Circuit ( egress ) Transmit Fault 168 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault 169 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault 171 6. Security Considerations 173 This document specifies only fixed identifiers, and not the protocols 174 used to carry the encapsulated packets across the network. Each such 175 protocol may have its own set of security issues, but those issues 176 are not affected by the identifiers specified herein. 178 7. Intellectual Property Disclaimer 180 This document is being submitted for use in IETF standards 181 discussions. 183 8. References 185 [1] "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3- 186 control-protocol-05.txt. ( work in progress ) 188 [2] "SONET/SDH Circuit Emulation over Packet (CEP)", draft-ietf- 189 pwe3-sonet-03.txt (work in progress). 191 9. Author Information 193 Luca Martini 194 Cisco Systems, Inc. 195 9155 East Nichols Avenue, Suite 400 196 Englewood, CO, 80112 197 e-mail: lmartini@cisco.com 199 W. Mark Townsley 200 Cisco Systems 201 7025 Kit Creek Road 202 PO Box 14987 203 Research Triangle Park, NC 27709 204 e-mail: mark@townsley.net