idnits 2.17.1 draft-metz-aii-aggregate-00.txt: -(135): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(139): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(220): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(267): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(447): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(459): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(460): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(467): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(486): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(538): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(546): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(548): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(552): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(553): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.3 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 619), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 45. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 28 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 225 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 9, 2005) is 6864 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) == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-10 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-03 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-requirements-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-ms-pw-requirements (ref. 'REQ-MH-PW') == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-06 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'MP-BGP-AUTO-DISC') Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Chris Metz 3 Internet Draft Luca Martini 4 Expires: January 2006 Cisco Systems 6 Florin Balus 7 Jeff Sugimoto 8 Nortel Networks 10 July 9, 2005 12 AII Types for Aggregation 13 draft-metz-aii-aggregate-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 This document may only be posted in an Internet-Draft. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on January 9, . 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). All Rights Reserved. 47 Abstract 49 [PWE3 Control] defines the signaling mechanisms for establishing 50 point-to-point pseudowires between two provider edge (PE) nodes. The 51 Generalized ID FEC element contained in PWE3 signaling protocols 52 include TLV fields that identify pseudowire endpoints called 53 attachment individual identifiers (AII). This document defines an AII 54 structure in the form of new AII type-length-value fields that 55 supports AII aggregation for improved scalability. It is envisioned 56 that this would be useful in large inter-domain virtual private wire 57 service networks where pseudowires are established between selected 58 local and remote PE nodes based on customer need. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 Error! 65 Reference source not found.. 67 Table of Contents 69 1. Introduction...................................................2 70 2. Proposed Structure for New AII Types...........................4 71 2.1. Short Prefix AII Type.....................................5 72 2.2. Long Prefix AII Type.....................................11 73 3. IANA Considerations...........................................13 74 4. Security Considerations.......................................13 75 5. Acknowledgments...............................................14 76 6. References....................................................15 77 Author's Addresses...............................................15 78 Intellectual Property Statement..................................16 79 Disclaimer of Validity...........................................16 80 Copyright Statement..............................................17 81 Acknowledgment...................................................17 83 1. Introduction 85 [PWE3-CONTROL] defines the signaling mechanisms for establishing 86 point-to-point pseudowires (PWs) between two provider edge (PE) 87 nodes. When a PW is set up, the LDP signaling messages include a FEC 88 element containing information about the PW type and an endpoint 89 identifier used in the selection of the PW forwarder that binds the 90 PW to the attachment circuit at each end. 92 There are two types of FEC elements defined for this purpose: PWid 93 FEC (type 128) and the Generalized ID (GID) FEC (type 129). The PWid 94 FEC element includes a fixed-length 32 bit value called the PWid that 95 serves as an endpoint identifier. The same PWid value must be 96 configured on the local and remote PE prior to PW setup. 98 The GID FEC element includes TLV fields for attachment individual 99 identifiers (AII) that, in conjunction with an attachment group 100 identifier (AGI), serve as PW endpoint identifiers. The endpoint 101 identifier on the local PE (denoted as 130 tuples. 132 An AII that is globally unique would facilitate PW management and 133 security in large inter-AS and inter-provider environments. Providers 134 would not have to worry about AII value overlap during provisioning 135 or the need for AII �NATs� during signaling. Globally unique AII 136 values could aid in troubleshooting and could be subjected to source- 137 validity checks during AII distribution and signaling. 139 An AII that can be automatically derived from a provider�s existing 140 IP address space can simplify the provisioning process. In addition 141 an AII structure that is backwards compatible with previous endpoint 142 identifier semantics (i.e. PWid) would help providers to converge 143 upon a PW provisioning and signaling behavior employing GID FEC TLVs. 145 In summary the purpose of this draft is to define an AII structure 146 based on [PWE3-CONTROL] that: 148 o Enables many discrete attachment individual identifiers to be 149 aggregated into a single AII aggregate. This will enhance 150 scalability by reducing the burden on AII distribution mechanisms 151 and on PE memory. 153 o Ensures global uniqueness if desired by the provider. This will 154 facilitate Internet-wide PW connectivity and provide a means for 155 providers to perform source validation on the AII distribution 156 (e.g. MP-BGP) and signaling (e.g. LDP) channels. 158 o Supports a uniform PW signaling mechanism employing the GID FEC 159 TLV structure for endpoints provisioned with the AII types defined 160 in this draft including those previously configured with the older 161 FEC 128 PWid value. 163 This is accomplished by defining two new AII types and associated 164 formats of the value fields. 166 2. Proposed Structure for New AII Types 168 The format of the GID FEC TLV is defined in [PWE3-CONTROL] and is 169 illustrated in figure 1: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | 129 |C| PW Type |PW info Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | AGI Type | Length | Value | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 ~ AGI Value (contd.) ~ 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | AII Type | Length | Value | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 ~ SAII Value (contd.) ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | AII Type | Length | Value | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 ~ TAII Value (contd.) ~ 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1 GID FEC TLV Format 194 In this document the Attachment Group Identifier (AGI) type retains 195 the semantics specified in [PWE3-CONTROL]. Definition of specific AGI 196 types is outside the scope of this document. However if the AGI is 197 non-null, then the SAI consists of the AGI together with the SAII, 198 and the TAI consists of the TAII together with the AGI. If the AGI 199 is null, then the SAII and TAII are the SAI and TAI respectively. 201 New AII types and the format of their associated AII value fields are 202 defined next. 204 2.1. Short Prefix AII Type 206 The Short Prefix AII type permits varying levels of AII summarization 207 to take place thus reducing the scaling burden on the aforementioned 208 AII distribution mechanisms and PE memory. In other words it no 209 longer becomes necessary to distribute or configure all individual 210 AII values (which could number in the tens of thousands or more) on 211 local PEs prior to establishing PWs to remote PEs. An AII aggregate 212 representing a range of individual candidate AII values on the remote 213 PEs coupled with corresponding IP reachability information leading to 214 the remote PE is all that is required. The next obvious step would be 215 to route a PW setup message containing a fully qualified target AII 216 type towards the IP next hop address associated with the AII 217 aggregate. The details of how this is performed are not discussed in 218 this document. 220 The Short Prefix AII type uses a combination of a provider�s globally 221 unique identifier (Global ID) and a variable length prefix up to 32 222 bits in length to create globally unique AII aggregates. It is termed 223 the Short Prefix AII type because of the shorter 32-bit prefix used 224 here as compared to the longer 256-bit prefix used in the Long Prefix 225 AII type defined in the next section. 227 The encoding of the Short Prefix AII type is shown in figure 2. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | AII Type=01 | Length | Flags | Global ID | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Global ID (contd.) | Prefix Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Prefix | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | AC ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2 Short Prefix AII TLV Structure 243 o AII Type = 0x01 245 o Length = length of value field in octets 247 o Flags = One octet flags field reserved for future use. The FLAGS 248 field MUST be set to zero when transmitting a message containing 249 this AII type and MUST BE ignored when receiving a message 250 containing this AII type. 252 o Global ID = This is a 4 octet field containing a value that is 253 unique to the provider. The global ID can contain the 2 octet or 4 254 octet value of the provider�s Autonomous System Number, a global 255 unicast IPv6 /48 prefix assigned to the provider or some other 256 globally unique value up to 4 octets in length. It is expected 257 that the global ID will be derived from the globally unique AS 258 number of the autonomous system hosting the PEs containing the 259 actual AIIs. If the PE hosting the AIIs is present in an 260 autonomous system where the provider is not running BGP, chooses 261 not to expose this information or does not wish to use the global 262 ID, then the global ID field MUST be set to zero. If the global 263 ID is derived from a 2-octet AS number, then the high-order 2 264 octets of this 4 octet field MUST be set to zero. 266 Please note that the use of the provider�s AS number as a global 267 ID DOES NOT have anything at all to do with the use AS number�s in 268 protocols such as BGP. 270 o Prefix Length = One octet value representing the significant 271 length of the 32-bit prefix in bits. 273 o Prefix = The 32-bit prefix is a value assigned by the provider or 274 it can be automatically derived from the PE�s /32 IPv4 loopback 275 address. Note that it is not required that the 32-bit prefix have 276 any association with the IPv4 address space used in the provider�s 277 IGP or BGP for IP reachability. 279 If the prefix length is less than 32 then the 32-bit prefix field 280 is padded with zeroes out to 32 bits, but only the first bits are significant. On receipt, bits beyond the first 282 number of bits MUST be ignored. 284 o Attachment Circuit (AC) ID = This is a fixed length four octet 285 field used to further refine identification of an attachment 286 circuit on the PE. For example if the target PE advertises a short 287 prefix AII aggregate representing all of its attachment circuits 288 using a single aggregate value, then the AC ID included in a fully 289 qualified Short Prefix AII Type (i.e. advertised for policy 290 reasons or included in a PW signaling message) can be used to 291 identify specific attachment circuits on that target PE. 293 If the AC ID is not present then the AC ID field MUST be null and 294 the AII Length field is set to 9. 296 The presence of a non-null AC ID in conjunction with zeroed out 297 global ID and prefix fields (i.e. prefix length equals zero) 298 enables backwards compatibility with PW end-points provisioned 299 with the older FEC 128 PWid value. This may be useful to provider 300 who will to converge upon GID FEC 129 signaling semantics. 302 Here are some examples of how the Short Prefix AII type applies. We 303 assume that the AGI is null and that the prefix where appropriate is 304 auto-generated from the configured /32 IPv4 loopback address of the 305 PE. 307 �All AIIs located in ASN = 2� is summarized as: 309 AII Type = 0x01 310 Length = variable 311 Flags = 0x00 312 Global ID = 0x00000002 313 Prefix Length = 0 314 Prefix = all zeroes 315 AC ID = null 317 This enables AII aggregation at the ASN level. A provider might use 318 this to advertise AII aggregate �reachability� to other providers in 319 an inter-domain PW provisioning scenario. 321 �All AIIs contained in ASN = 2 and located on remote PEs with 322 addresses beginning with 192.0.2/24� is summarized as: 324 AII Type = 0x01 325 Length = variable 326 Flags = 0x00 327 Global ID = 0x00000002 328 Prefix Length = 24 329 Prefix = 192.0.2.0 330 AC ID = null 332 Here we have aggregated all AIIs contained on up to 254 remote PEs in 333 a specific ASN into a single AII aggregate. This would likely apply 334 in an inter-domain case and would be used to limit external AII 335 reachability to just those PEs sharing a common IPv4 prefix. 337 �All AIIs contained on a single remote PE (192.0.2.21) located in ASN 338 = 2� is summarized as: 340 AII Type = 0x01 341 Length = variable 342 Flags = 0x00 343 Global ID = 0x00000002 344 Prefix Length = 32 345 Prefix = 192.0.2.21 346 AC ID = null 348 This is per-PE aggregation. Observe that this could be useful in a 349 single-domain environment. A local PE would only need to learn and 350 store the AII aggregate of the remote PE rather then learn and store 351 each individual AII value. 353 AS in the previous example but now the provider wants to advertise a 354 couple of specific AC IDs (00000001 and 00000003) on the remote PE of 355 192.0.2.3. Again the analogy is inter-domain routing where providers 356 export more specific routes as a means of expressing routing policy. 357 The provider in this case may wish to express their PW connectivity 358 policies to these two respective attachment circuits on this PE. 360 There would now be a single AII aggregate summarized as: 362 AII Type = 0x01 363 Length = variable 364 Flags = 0x00 365 Global ID = 0x00000002 366 Prefix Length = 32 367 Prefix = 192.0.2.3 368 AC ID = null 370 and two discrete AII �specifics� encoded as: 372 AII Type = 0x01 373 Length = variable 374 Flags = 0x00 375 Global ID = 0x00000002 376 Prefix Length = 32 377 Prefix = 192.0.2.3 378 AC ID = 00000001 380 and � 382 AII Type = 0x01 383 Length = variable 384 Flags = 0x00 385 Global ID = 0x00000002 386 Prefix Length = 32 387 Prefix = 192.0.2.3 388 AC ID = 00000003 390 Note that in this case we have punched a couple of holes into the AII 391 aggregate space that will increase the amount of AII information that 392 must be distributed. 394 And finally here is an example where the global ID is zeroed and 395 combination of the prefix (192.0.2.3) and AC ID (00000004) are used 396 to identify a particular AII: 398 AII Type = 0x01 399 Length = variable 400 Flags = 0x00 401 Global ID = 0x00000000 402 Prefix Length = 32 403 Prefix = 192.0.2.3 404 AC ID = 00000004 406 2.2. Long Prefix AII Type 408 The Long Prefix AII type employs a global ID and variable-length 409 prefixes up to 256 bits (versus 32 bits for the Short Prefix AII 410 type) in length to create AII values and their aggregates. The Long 411 Prefix AII type might be useful to providers with an NSAP-based 412 provisioning system or who are migrating a network with an NSAP 413 addressing scheme to a network supporting PW connectivity. It can 414 also be used to auto-generate AII aggregates based on /128 IPv6 and 415 /32 IPv4 PE loopbacks. 417 The encoding of the Long Prefix AII type is shown in figure 3: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | AII Type=02 | Length | Flags | Global ID | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Global ID (contd.) | Prefix Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 | | 428 | | 429 | Prefix | 430 | | 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 3 Long Prefix AII TLV Structure 436 o AII Type = 0x02 438 o Length = length of value field in octets 440 o Flags = One octet flags field reserved for future use. The FLAGS 441 field MUST be set to zero when transmitting a message containing 442 this AII type and MUST BE ignored when receiving a message 443 containing this AII type. 445 o Global ID = This is a 4 octet field containing a value that is 446 unique to the provider. The global ID can contain the 2 octet or 4 447 octet value of the provider�s Autonomous System Number, a global 448 unicast IPv6 /48 prefix assigned to the provider or some other 449 globally unique value up to 4 octets in length. It is expected 450 that the global ID will be derived from the globally unique AS 451 number of the autonomous system hosting the PEs containing the 452 actual AIIs. If the PE hosting the AIIs is present in an 453 autonomous system where the provider is not running BGP, chooses 454 not to expose this information or does not wish to use the global 455 ID, then the global ID field MUST be set to zero. If the global ID 456 is derived from a 2-octet AS number, then the high-order 2 octets 457 of this 4 octet field MUST be set to zero. 459 Please note that the use of the provider�s AS number as a global 460 ID DOES NOT have anything at all to do with the use AS number�s in 461 protocols such as BGP. 463 o Prefix Length = One octet value representing the length of the 464 prefix in bits. 466 o Prefix = The Prefix is a value assigned by the provider or it can 467 be automatically derived from the PE�s local addressing scheme 468 such as IPv6, NSAP or IPv4. 470 If the prefix length is less than 256 then the prefix field is 471 padded with zeroes out to 256 bits, but only the first bits are significant. On receipt, bits beyond the first 473 number of bits MUST be ignored. 475 This AII type does not employ an optional AC ID field. This is 476 because there are sufficient bits available in the prefix field to 477 hold a fully qualified target PE value auto-generated from 160 bit 478 NSAP or 128 bit IPv6 addresses with the remainder available for 479 attachment circuit identification. 481 Here is an example of how the Long Prefix AII type applies. Again we 482 assume that the AGI value is null and that the AII aggregate is auto- 483 generated from the loopback address of the PE. 485 �All AIIs contained on a single remote IPv6 PE 486 (2001:DB8:C003:1:0:0:0:1234) located in ASN = 3� is summarized as: 488 AII Type = 0x02 489 Length = variable 490 Flags = 0x00 491 Global ID = 0x00000003 492 Prefix Length = 128 493 Prefix = 2001:DB8:C003:1:0:0:0:1234 495 This is an example of per-PE aggregation. Identification of a 496 specific attachment circuit (01) on this PE requires a fully 497 qualified long prefix AII type consisting of: 499 AII Type = 0x02 500 Length = variable 501 Flags = 0x00 502 Global ID = 0x00000003 503 Prefix Length = 256 504 Prefix = 2001:DB8:C003:1:0:0:0:1234::01 506 3. IANA Considerations 508 This document requests that IANA allocate three AII types from the 509 "Attachment Individual Identifier (AII) Type" registry defined in 510 [IANA]. 512 The suggested values for the AAI types are: 514 Value Description 516 0x01 Short Prefix AII Type 518 0x02 Long Prefix AII Type 520 4. Security Considerations 522 AII values appear in AII distribution protocols [MP-BGP-AUTO-DISC] 523 and PW signaling protocols [PWE3-CONTROL] and are subject to various 524 authentication schemes (i.e. MD5) if so desired. 526 The use of global ID values (e.g. ASN) in the inter-provider case 527 could enable a form of source-validation checking to ensure that the 528 AII value (aggregated or explicit) originated from a legitimate 529 source. 531 5. Acknowledgments 533 Thanks to Carlos Pignataro, Scott Brim, Skip Booth and George Swallow 534 for their input into this draft. 536 6. References 538 [PWE3-CONTROL], �Pseudowire Setup and Maintenance using LDP�, 539 draft-ietf-pwe3-control-protocol-17.txt, June 2005 541 [IANA], "IANA Allocations for pseudo Wire Edge to Edge Emulation 542 (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation- 543 10.txt, work in progress), June 2005 545 [L2VPN-SIG], �Provisioning Models and Endpoint Identifiers in L2VPN 546 Signaling�, draft-ietf-l2vpn-signaling-03.txt, Feb. 2005 548 [REQ-MH-PW], �Requirements for inter domain Pseudo-Wires�, draft- 549 ietf-pwe3-ms-pw-requirements-00.txt, Internet Draft, June 550 2005 552 [MP-BGP-AUTO-DISC], �Using BGP as an Auto-Discovery Mechanism for 553 Layer-3 and Layer-2 VPNs�, Ould-Brahim, H. et al, draft- 554 ietf-l3vpn-bgpvpn-auto-06.txt, June 2005 556 Author's Addresses 558 Chris Metz 559 Cisco Systems, Inc. 560 3700 Cisco Way 561 San Jose, Ca. 95134 562 Email: chmetz@cisco.com 564 Luca Martini 565 Cisco Systems, Inc. 566 9155 East Nichols Avenue, Suite 400 567 Englewood, CO, 80112 568 Email: lmartini@cisco.com 570 Florin Balus 571 Nortel 572 3500 Carling Ave. 574 Ottawa, Ontario, CANADA 575 Email: balus@nortel.com 577 Jeff Sugimoto 578 Nortel 579 3500 Carling Ave. 580 Ottawa, Ontario, CANADA 581 Email: sugimoto@nortel.com 583 Intellectual Property Statement 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org 607 Disclaimer of Validity 609 This document and the information contained herein are provided on an 610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 612 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 613 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 614 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 Copyright Statement 619 Copyright (C) The Internet Society (2005). 621 This document is subject to the rights, licenses and restrictions 622 contained in BCP 78, and except as set forth therein, the authors 623 retain all their rights. 625 Acknowledgment 627 Funding for the RFC Editor function is currently provided by the 628 Internet Society.