--- 1/draft-ietf-mpls-rfc3036bis-00.txt 2006-02-05 00:42:27.000000000 +0100 +++ 2/draft-ietf-mpls-rfc3036bis-01.txt 2006-02-05 00:42:27.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Loa Andersson Internet Draft Ina Minei -Expiration Date: March 2005 Bob Thomas +Expiration Date: May 2005 Bob Thomas Editors - September 2004 + November 2004 LDP Specification - draft-ietf-mpls-rfc3036bis-00.txt + draft-ietf-mpls-rfc3036bis-01.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. @@ -57,46 +57,55 @@ ### This document is produced as part of advancing the LDP specification to draft standard status. The LDP specification was originally published as RFC 3036 in January 2001. It was produced by the MPLS working of the IETF and was jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette and Bob Thomas. ### -Changes from RFC3036 - ### - Here is a list of changes from RFC3036 +Changes from version 00 - 1. Split the reference list into normative and non-normative + 1. Removed the host address fec and the references to it. + 2. Removed the text added in version 00 regarding use of wildcard + fec in label request messages, as it contradicts section 3.4.1. + 3. Reversed the change from version 00: In the "receive label + mapping" procedures, removed unnecessary checks in step LMp.29. + The checks are left in place since they make the code more + readable. + +Changes from RFC3036 + + Here is a list of changes from RFC3036 + 1. Removed the Host Address FEC and references to it, since it is + not used by any implementation. + 2. Split the reference list into normative and non-normative references - 2. Removed "MPLS using ATM VP Switching" from the list of + 3. Removed "MPLS using ATM VP Switching" from the list of normative references. - 3. Clarified the use of the F bit. - 4. Added option to allow split horizon when doing ordered control. - 5. Clarified the processing of messages with the U-bit set during + 4. Clarified the use of the F bit. + + 5. Added option to allow split horizon when doing ordered control. + 6. Clarified the processing of messages with the U-bit set during the session initialization procedures - 6. Clarified the processing of the E-bit during session + 7. Clarified the processing of the E-bit during session initialization procedures. - 7. Added case for TLV length too short in the specification for + 8. Added case for TLV length too short in the specification for handling malformed TLVs. - 8. Clarified the use of the Wildcard FEC in label request - messages. 9. In the section describing handling of unknown TLV, removed reference to inexistent section (errata in original document) 10. In the "receive label request" procedures, if a loop is detected, changed the procedure to send a notification before aborting the rest of the processing. - 11. In "receive label release" procedures, clarified the behavior for merge-capable LSRs. 12. In "receive label release" procedures, clarified the behavior for receipt of an unknown FEC. 13. In note 4 of "Detect Change in FEC Next Hop", modified the text to reference the correct set of conditions for sending a label request procedure (typo in the original document) 14. In the procedures for "LSR decides to no longer label switch a FEC", clarified the fact that the label must not be reused until a label release is received. @@ -110,25 +119,23 @@ address. 17. In the routine "Receive Label Mapping" clarified the meaning of PrevAdvLabel when no label advertisement message has been sent previously. 18. In the "receive label mapping" procedures, if a loop is detected, modified the procedure to send a notification before aborting the rest of the processing. 19. In the "receive label mapping" procedures, corrected step LMp.10 to handle label mapping messages for additional (non- merged) LSPs for the FEC. - 20. In the "receive label mapping" procedures, removed unnecessary - checks in step LMp.29. - 21. In the routine "Receive Label Abort Request" clarified the + 20. In the routine "Receive Label Abort Request" clarified the behavior for non-merging LSRs. - 22. Added the following items to the section discussing areas for + 21. Added the following items to the section discussing areas for future study: o extensions for communicating the maximum transmission unit o basic peer discovery on NBMA media o option of shutting down an adjacency o mechanisms for securing Hello messages o detection of a stateless fast control plane restart o o support of "end of LIB" message o mechanisms for dealing with the case where different LSRs advertise the same address. @@ -144,43 +151,44 @@ label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. Table of Contents How to read this document ............................. 1 Source of this document ............................... 2 + Changes from version 00 ............................... 2 Changes from RFC3036 .................................. 2 1 LDP Overview .......................................... 9 1.1 LDP Peers ............................................. 10 1.2 LDP Message Exchange .................................. 10 1.3 LDP Message Structure ................................. 11 1.4 LDP Error Handling .................................... 11 1.5 LDP Extensibility and Future Compatibility ............ 11 1.6 Specification Language ................................ 11 2 LDP Operation ......................................... 12 2.1 FECs .................................................. 12 2.2 Label Spaces, Identifiers, Sessions and Transport ..... 13 2.2.1 Label Spaces .......................................... 13 2.2.2 LDP Identifiers ....................................... 14 2.2.3 LDP Sessions .......................................... 14 - 2.2.4 LDP Transport ......................................... 15 + 2.2.4 LDP Transport ......................................... 14 2.3 LDP Sessions between non-Directly Connected LSRs ...... 15 2.4 LDP Discovery ......................................... 15 - 2.4.1 Basic Discovery Mechanism ............................. 16 + 2.4.1 Basic Discovery Mechanism ............................. 15 2.4.2 Extended Discovery Mechanism .......................... 16 2.5 Establishing and Maintaining LDP Sessions ............ 17 2.5.1 LDP Session Establishment ............................. 17 2.5.2 Transport Connection Establishment .................... 17 - 2.5.3 Session Initialization ................................ 19 + 2.5.3 Session Initialization ................................ 18 2.5.4 Initialization State Machine .......................... 21 2.5.5 Maintaining Hello Adjacencies ......................... 24 2.5.6 Maintaining LDP Sessions .............................. 24 2.6 Label Distribution and Management ..................... 25 2.6.1 Label Distribution Control Mode ....................... 25 2.6.1.1 Independent Label Distribution Control ................ 25 2.6.1.2 Ordered Label Distribution Control .................... 25 2.6.2 Label Retention Mode .................................. 26 2.6.2.1 Conservative Label Retention Mode ..................... 26 2.6.2.2 Liberal Label Retention Mode .......................... 27 @@ -194,62 +202,62 @@ 2.9.1 TCP MD5 Signature Option .............................. 33 2.9.2 LDP Use of TCP MD5 Signature Option ................... 34 2.10 Label Distribution for Explicitly Routed LSPs ......... 35 3 Protocol Specification ................................ 35 3.1 LDP PDUs .............................................. 35 3.2 LDP Procedures ........................................ 36 3.3 Type-Length-Value Encoding ............................ 37 3.4 TLV Encodings for Commonly Used Parameters ............ 39 3.4.1 FEC TLV ............................................... 39 3.4.1.1 FEC Procedures ........................................ 42 - 3.4.2 Label TLVs ............................................ 42 - 3.4.2.1 Generic Label TLV ..................................... 42 - 3.4.2.2 ATM Label TLV ......................................... 43 - 3.4.2.3 Frame Relay Label TLV ................................. 43 - 3.4.3 Address List TLV ...................................... 44 - 3.4.4 Hop Count TLV ......................................... 45 - 3.4.4.1 Hop Count Procedures .................................. 45 - 3.4.5 Path Vector TLV ....................................... 47 - 3.4.5.1 Path Vector Procedures ................................ 47 - 3.4.5.1.1 Label Request Path Vector ............................. 47 - 3.4.5.1.2 Label Mapping Path Vector ............................. 49 - 3.4.6 Status TLV ............................................ 50 - 3.5 LDP Messages .......................................... 52 - 3.5.1 Notification Message .................................. 54 - 3.5.1.1 Notification Message Procedures ....................... 55 - 3.5.1.2 Events Signaled by Notification Messages .............. 56 - 3.5.1.2.1 Malformed PDU or Message .............................. 56 - 3.5.1.2.2 Unknown or Malformed TLV .............................. 58 - 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 59 - 3.5.1.2.4 Unilateral Session Shutdown ........................... 60 - 3.5.1.2.5 Initialization Message Events ......................... 60 - 3.5.1.2.6 Events Resulting From Other Messages .................. 60 - 3.5.1.2.7 Internal Errors ....................................... 60 - 3.5.1.2.8 Miscellaneous Events .................................. 60 - 3.5.2 Hello Message ......................................... 60 - 3.5.2.1 Hello Message Procedures .............................. 63 - 3.5.3 Initialization Message ................................ 64 - 3.5.3.1 Initialization Message Procedures ..................... 72 - 3.5.4 KeepAlive Message ..................................... 72 - 3.5.4.1 KeepAlive Message Procedures .......................... 73 - 3.5.5 Address Message ....................................... 73 - 3.5.5.1 Address Message Procedures ............................ 74 - 3.5.6 Address Withdraw Message .............................. 74 - 3.5.6.1 Address Withdraw Message Procedures ................... 75 - 3.5.7 Label Mapping Message ................................. 75 - 3.5.7.1 Label Mapping Message Procedures ...................... 77 - 3.5.7.1.1 Independent Control Mapping ........................... 77 - 3.5.7.1.2 Ordered Control Mapping ............................... 78 - 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 78 - 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 80 - 3.5.8 Label Request Message ................................. 80 - 3.5.8.1 Label Request Message Procedures ...................... 81 + 3.4.2 Label TLVs ............................................ 43 + 3.4.2.1 Generic Label TLV ..................................... 43 + 3.4.2.2 ATM Label TLV ......................................... 44 + 3.4.2.3 Frame Relay Label TLV ................................. 44 + 3.4.3 Address List TLV ...................................... 45 + 3.4.4 Hop Count TLV ......................................... 46 + 3.4.4.1 Hop Count Procedures .................................. 46 + 3.4.5 Path Vector TLV ....................................... 48 + 3.4.5.1 Path Vector Procedures ................................ 48 + 3.4.5.1.1 Label Request Path Vector ............................. 48 + 3.4.5.1.2 Label Mapping Path Vector ............................. 50 + 3.4.6 Status TLV ............................................ 51 + 3.5 LDP Messages .......................................... 53 + 3.5.1 Notification Message .................................. 55 + 3.5.1.1 Notification Message Procedures ....................... 56 + 3.5.1.2 Events Signaled by Notification Messages .............. 57 + 3.5.1.2.1 Malformed PDU or Message .............................. 57 + 3.5.1.2.2 Unknown or Malformed TLV .............................. 59 + 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 60 + 3.5.1.2.4 Unilateral Session Shutdown ........................... 61 + 3.5.1.2.5 Initialization Message Events ......................... 61 + 3.5.1.2.6 Events Resulting From Other Messages .................. 61 + 3.5.1.2.7 Internal Errors ....................................... 61 + 3.5.1.2.8 Miscellaneous Events .................................. 61 + 3.5.2 Hello Message ......................................... 61 + 3.5.2.1 Hello Message Procedures .............................. 64 + 3.5.3 Initialization Message ................................ 65 + 3.5.3.1 Initialization Message Procedures ..................... 73 + 3.5.4 KeepAlive Message ..................................... 73 + 3.5.4.1 KeepAlive Message Procedures .......................... 74 + 3.5.5 Address Message ....................................... 74 + 3.5.5.1 Address Message Procedures ............................ 75 + 3.5.6 Address Withdraw Message .............................. 75 + 3.5.6.1 Address Withdraw Message Procedures ................... 76 + 3.5.7 Label Mapping Message ................................. 76 + 3.5.7.1 Label Mapping Message Procedures ...................... 78 + 3.5.7.1.1 Independent Control Mapping ........................... 78 + 3.5.7.1.2 Ordered Control Mapping ............................... 79 + 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 79 + 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 81 + 3.5.8 Label Request Message ................................. 81 + 3.5.8.1 Label Request Message Procedures ...................... 82 3.5.9 Label Abort Request Message ........................... 84 3.5.9.1 Label Abort Request Message Procedures ................ 85 3.5.10 Label Withdraw Message ................................ 86 3.5.10.1 Label Withdraw Message Procedures ..................... 87 3.5.11 Label Release Message ................................. 89 3.5.11.1 Label Release Message Procedures ...................... 90 3.6 Messages and TLVs for Extensibility ................... 91 3.6.1 LDP Vendor-private Extensions ......................... 91 3.6.1.1 LDP Vendor-private TLVs ............................... 91 3.6.1.2 LDP Vendor-private Messages ........................... 94 @@ -283,22 +291,22 @@ A.1.2 Receive Label Mapping ................................. 120 A.1.3 Receive Label Abort Request ........................... 130 A.1.4 Receive Label Release ................................. 133 A.1.5 Receive Label Withdraw ................................ 135 A.1.6 Recognize New FEC ..................................... 137 A.1.7 Detect Change in FEC Next Hop ......................... 140 A.1.8 Receive Notification / Label Request Aborted .......... 143 A.1.9 Receive Notification / No Label Resources ............. 144 A.1.10 Receive Notification / No Route ....................... 144 A.1.11 Receive Notification / Loop Detected .................. 146 -A.1.12 Receive Notification / Label Resources Available ...... 146 +A.1.12 Receive Notification / Label Resources Available ...... 146 A.1.13 Detect local label resources have become available .... 147 A.1.14 LSR decides to no longer label switch a FEC ........... 148 A.1.15 Timeout of deferred label request ..................... 149 A.2 Common Label Distribution Procedures .................. 150 A.2.1 Send_Label ............................................ 150 A.2.2 Send_Label_Request .................................... 151 A.2.3 Send_Label_Withdraw ................................... 153 A.2.4 Send_Notification ..................................... 154 A.2.5 Send_Message .......................................... 154 A.2.6 Check_Received_Attributes ............................. 155 @@ -446,92 +454,75 @@ each LSP. This is done by providing a FEC specification for each LSP. The FEC identifies the set of IP packets which may be mapped to that LSP. Each FEC is specified as a set of one or more FEC elements. Each FEC element identifies a set of packets which may be mapped to the corre- sponding LSP. When an LSP is shared by multiple FEC elements, that LSP is terminated at (or before) the node where the FEC elements can no longer share the same path. - Following are the currently defined types of FEC elements. New ele- - ment types may be added as needed: + ### - 1. Address Prefix. This element is an address prefix of any - length from 0 to a full address, inclusive. + Changed the text to the end of the section to reflect removal of the + host address fec. This includes changing the processing rules (remov- + ing the unnecessary ones). - 2. Host Address. This element is a full host address. + ### - (We will see below that an Address Prefix FEC element which is a full - address has a different effect than a Host Address FEC element which - has the same address.) + This specification defines a single type of FEC element, the "Address + Prefix FEC element". This element is an address prefix of any length + from 0 to a full address, inclusive. + + Additional FEC elements may be defined, as needed, by other specifi- + cations. + + In the remainder of this section we give the rules to be used for + mapping packets to LSPs that have been set up using an Address Prefix + FEC element. We say that a particular address "matches" a particular address pre- fix if and only if that address begins with that prefix. We also say that a particular packet matches a particular LSP if and only if that LSP has an Address Prefix FEC element which matches the packet's des- tination address. With respect to a particular packet and a particu- lar LSP, we refer to any Address Prefix FEC element which matches the packet as the "matching prefix". The procedure for mapping a particular packet to a particular LSP uses the following rules. Each rule is applied in turn until the packet can be mapped to an LSP. - - If there is exactly one LSP which has a Host Address FEC element - that is identical to the packet's destination address, then the - packet is mapped to that LSP. - - - If there are multiple LSPs, each containing a Host Address FEC - element that is identical to the packet's destination address, - then the packet is mapped to one of those LSPs. The procedure - for selecting one of those LSPs is beyond the scope of this docu- - ment. - - If a packet matches exactly one LSP, the packet is mapped to that LSP. - If a packet matches multiple LSPs, it is mapped to the LSP whose matching prefix is the longest. If there is no one LSP whose matching prefix is longest, the packet is mapped to one from the set of LSPs whose matching prefix is longer than the others. The procedure for selecting one of those LSPs is beyond the scope of this document. - If it is known that a packet must traverse a particular egress router, and there is an LSP which has an Address Prefix FEC ele- - ment which is an address of that router, then the packet is + ment which is a /32 address of that router, then the packet is mapped to that LSP. The procedure for obtaining this knowledge is beyond the scope of this document. The procedure for determining that a packet must traverse a particu- lar egress router is beyond the scope of this document. (As an exam- ple, if one is running a link state routing algorithm, it may be pos- sible to obtain this information from the link state data base. As another example, if one is running BGP, it may be possible to obtain this information from the BGP next hop attribute of the packet's route.) - It is worth pointing out a few consequences of these rules: - - - A packet may be sent on the LSP whose Address Prefix FEC element - is the address of the packet's egress router ONLY if there is no - LSP matching the packet's destination address. - - - A packet may match two LSPs, one with a Host Address FEC element - and one with an Address Prefix FEC element. In this case, the - packet is always assigned to the former. - - - A packet which does not match a particular Host Address FEC ele- - ment may not be sent on the corresponding LSP, even if the Host - Address FEC element identifies the packet's egress router. - 2.2. Label Spaces, Identifiers, Sessions and Transport 2.2.1. Label Spaces The notion of "label space" is useful for discussing the assignment and distribution of labels. There are two types of label spaces: - Per interface label space. Interface-specific incoming labels are used for interfaces that use interface resources for labels. An example of such an interface is a label-controlled ATM inter- @@ -803,23 +795,23 @@ ters it wishes to use and a KeepAlive message to signal acceptance of LSR2's parameters. If the parameters are not acceptable, LSR1 responds by sending a Session Rejected/Parameters Error Notification message and closing the TCP connection. c. If LSR1 cannot find a matching Hello adjacency it sends a Session Rejected/No Hello Error Notification message and closes the TCP connection. - d. If LSR1 receives a KeepAlive in response to its Initializa- - tion message, the session is operational from LSR1's point - of view. + d. If LSR1 receives a KeepAlive in response to its + Initialization message, the session is operational from + LSR1's point of view. e. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP con- nection. 2. When LSR1 plays the active role: a. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP con- nection. @@ -1692,21 +1684,25 @@ itself is one where standard LDP TLV encoding is not used. The FEC Element value encoding is: FEC Element Type Value type name Wildcard 0x01 No value; i.e., 0 value octets; see below. Prefix 0x02 See below. - Host Address 0x03 Full host address; see below. + ### + + Removed reference to host address fec + + ### Note that this version of LDP supports the use of multiple FEC Elements per FEC for the Label Mapping message only. The use of multiple FEC Elements in other messages is not permitted in this version, and is a subject for future study. Wildcard FEC Element To be used only in the Label Withdraw and Label Release Mes- sages. Indicates the withdraw/release is to be applied to all FECs associated with the label within the following label TLV. @@ -1731,42 +1727,25 @@ One octet unsigned integer containing the length in bits of the address prefix that follows. A length of zero indicates a pre- fix that matches all addresses (the default destination); in this case the Prefix itself is zero octets). Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary. - Host Address FEC Element encoding: - - 0 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Host Addr (3) | Address Family | Host Addr Len | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - | Host Addr | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Address Family - Two octet quantity containing a value from ADDRESS FAMILY - NUMBERS in [RFC1700] that encodes the address family for the - address prefix in the Prefix field. + ### - Host Addr Len - Length of the Host address in octets. + Removed Host address FEC element encoding - Host Addr - An address encoded according to the Address Family field. + ### 3.4.1.1. FEC Procedures If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it should stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error. If it encounters a FEC Element type it cannot decode, it should stop @@ -3219,23 +3198,23 @@ The Mapping message is used by an LSR to distribute a label mapping for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC to multiple LDP peers, it is a local matter whether it maps a single label to the FEC, and distributes that mapping to all its peers, or whether it uses a different mapping for each of its peers. An LSR is responsible for the consistency of the label mappings it has distributed, and that its peers have these mappings. An LSR receiving a Label Mapping message from a downstream LSR for a - Prefix or Host Address FEC Element should not use the label for for- - warding unless its routing table contains an entry that exactly - matches the FEC Element. + Prefix ### Removed mention of the Host Address FEC Element ### should + not use the label for forwarding unless its routing table contains an + entry that exactly matches the FEC Element. See Appendix A "LDP Label Distribution Procedures" for more details. 3.5.7.1.1. Independent Control Mapping If an LSR is configured for independent control, a mapping message is transmitted by the LSR upon any of the following conditions: 1. The LSR recognizes a new FEC via the forwarding table, and the label advertisement mode is Downstream Unsolicited advertise- @@ -3399,36 +3378,29 @@ 3. The LSR receives a Label Request for a FEC from an upstream LDP peer, the FEC next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop. Note that since a non-merge LSR must setup a separate LSP for each upstream peer requesting a label, it must send a separate Label Request for each such peer. A consequence of this is that a non-merge LSR may have multiple Label Request messages for a given FEC outstanding at the same time. - ### - - 4. An LSR may send a request for all a peer's bindings by send- - ing a label Request message with the Wildcard FEC. - - ### - The receiving LSR should respond to a Label Request message with a Label Mapping for the requested label or with a Notification message indicating why it cannot satisfy the request. - When the FEC for which a label is requested is a Prefix FEC Element - or a Host Address FEC Element, the receiving LSR uses its routing ta- - ble to determine its response. Unless its routing table includes an - entry that exactly matches the requested Prefix or Host Address, the - LSR must respond with a No Route Notification message. + When the FEC for which a label is requested is a Prefix FEC Element, + ### Removed mention of the host address fec ### the receiving LSR + uses its routing table to determine its response. Unless its routing + table includes an entry that exactly matches the requested Prefix, + the LSR must respond with a No Route Notification message. The message ID of the Label Request message serves as an identifier for the Label Request transaction. When the receiving LSR responds with a Label Mapping message, the mapping message must include a Label Request/Returned Message ID TLV optional parameter which includes the message ID of the Label Request message. Note that since LSRs use Label Request message IDs as transaction identifiers an LSR should not reuse the message ID of a Label Request message until the corresponding transaction completes. @@ -4275,22 +4247,22 @@ The ideas and text in RFC3036 were collected from a number of sources. We would like to thank Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter, and Arun Viswanathan for their input for RFC3036. The editors would like to thank Eric Gray for his insight and input to the current document. In addition, the editors would like to thank the members of the mpls working group for their ideas and the support they have given to this - document, and in particular to Luca Martini, Markus Jork, Mark Duffy, - Eric Rosen, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan + document, and in particular to Eric Rosen, Luca Martini, Markus Jork, + Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan and Nick Weeds. ### 8. References 8.1. Normative references ### Remove the following reference, it never went past the -00 stage.