idnits 2.17.1 draft-ietf-l2tpext-mpls-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 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 a Security Considerations 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. ** The abstract seems to contain references ([3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '...Tunnel Initiator SHALL determine what ...' RFC 2119 keyword, line 79: '...unnel Terminator SHALL determine the a...' RFC 2119 keyword, line 88: '... MAY have its sessions(s) dropped....' RFC 2119 keyword, line 95: '... o MUST, SHALL, or MANDATORY -- ...' RFC 2119 keyword, line 98: '... o SHOULD or RECOMMEND -- This i...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 157, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-03 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-06 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Informational Sun Microsystems, Inc. 3 Title: draft-ietf-l2tpext-mpls-00.txt Ken Peirce 4 Date: March 2000 Malibu Networks, Inc. 6 Layer Two Tunneling Protocol "L2TP" 7 Multi-Protocol Label Switching Extension 9 Status of this Memo 11 This document is a submission by the L2TP Extensions Working Group of 12 the Internet Engineering Task Force (IETF). Comments should be 13 submitted to the l2tp@ipsec.org mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The L2TP document [1] defines the base protocol which describes the 39 method of tunneling PPP data. The L2TP base protocol does not address 40 any MPLS extensions. 42 The goal of MPLS is to speed forwarding of packets by reducing the 43 lookup required in routing. This draft proposes a method to allow 44 L2TP Data Sessions to be assigned an MPLS Label Switched Path Id 45 (LSPID)[3] for an explicit route (ER). Assignment of such an ER is 46 necessary for traffic engineering. 48 Table of Contents 50 1.0 Introduction 51 1.1 Conventions 52 2.0 Multi-Protocol Label Switching 53 2.1 Multi-Protocol LSPID AVP 54 2.2 Error Reporting 55 3.0 References 56 4.0 Acknowledgements 57 5.0 Authors' Addresses 59 1.0 Introduction 61 The L2TP protocol specification does not discuss Multi-Protocol Label 62 Switching (MPLS)[5] in any way. This document will describe how two 63 L2TP peers can negotiate an LSPID for an L2TP over MPLS session. This 64 will provide either the LNS or LAC with an LSPID with which to select 65 an explicit MPLS Label Switched Path to the peer. The application of 66 an LSPID should speed the forwarding of the L2TP packets by reducing 67 the header analysis/lookup and permit effective traffic engineering. 69 Note that this document does not cover the creation of the LSPID. 70 This is a function of the Label Distribution Protocol[4]. 72 MPLS explicit routes are uni-directional. Thus LSPIDs may be used to 73 specify ERs in either or both the LAC-to-LNS and the LNS-to-LAC 74 directions. The mechanism defined in this document assumes that the 75 Tunnel Initiator SHALL determine what the user's appropriate LSPID is 76 for LNS-to-LAC traffic and send that information in either the ICRQ 77 or OCRQ messages. 79 The Tunnel Terminator SHALL determine the appropriate LSPID for LAC- 80 to-LNS traffic by including this information in the ICRP or OCRP. 82 In the case where either one or both peers do not propose ANY LSPIDs, 83 (which is inferred by the absence of the LSPID AVPs in the respective 84 request and or response, it is assumed that the sending peer has no 85 preference for the routing of the session traffic. 87 A peer which fails to use an accepted LSPID in the routing of traffic 88 MAY have its sessions(s) dropped. 90 1.1 Conventions 92 The following language conventions are used in the items of 93 specification in this document: 95 o MUST, SHALL, or MANDATORY -- This item is an absolute 96 requirement of the specification. 98 o SHOULD or RECOMMEND -- This item should generally be followed 99 for all but exceptional circumstances. 101 o MAY or OPTIONAL -- This item is truly optional and may be 102 followed or ignored according to the needs of the implementor. 104 2.0 Multi-Protocol Label Switching 106 This section will define the new AVP which is required for the MPLS 107 label distribution extension of the L2TP protocol. The AVP allows the 108 designation of an LSPID for a specific data channel or group of data 109 channels. 111 2.1 Multi-Protocol LSPID AVP 113 The LSPID is an opaque object for an L2TP session used in a method 114 similar to [3]. The LSPID is defined in [3]. The following AVP holds 115 the LSPID without any knowledge of its composition. The reader should 116 note that the format of the LSPID is that of an MPLS TLV. However, 117 that MPLS TLV is to be strictly treated as an opaque object by L2TP. 119 The Multi-Protocol LSPID AVP MAY be present in ICRQ, ICRP, OCRQ and 120 OCRP. This message is used to inform the tunnel peer that a specific 121 MPLS ER SHOULD be used for all packets related to the data channel 122 associated with the Tunnel and Call Identifiers in the L2TP header 123 [1]. 125 A peer which violates the routing of traffic in accordance with an 126 accepted LSPID MAY have its sessions(s) dropped. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |1|1|0|0| Length | 43 | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | 1 | LSPID TLV[see 3] Value ... 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 This AVP MAY be present in the messages shown above. It is encoded 137 with a Vendor ID of 43 (3Com Corporation) with the attribute set to 138 2, marked as optional, with the indicator value as data. This AVP 139 SHOULD NOT be hidden and is optional. When present, the L2TP peer is 140 indicating that Multi-Protocol LSPIDs are to be used. 142 2.2 Error Reporting 144 In the event that the peer did not accept the LSPID provided, or is 145 unable to support MPLS a Call-Disconnect-Notify is returned to the 146 peer. 148 If the LSPID provided cannot be used by the peer, the Call- 149 Disconnect-Notify message will include the Multi-Protocol LSPID AVP 150 as provided in the message that caused the Call-Disconnect-Notify. 152 3.0 References 154 [1] W.M. Townsley, A. J. Valencia, A. Rubens, G.S. Pall, G. Zorn, 155 B. Palter. "Layer Two Tunneling Protocol (L2TP)", RFC 2661. 156 August 1999. 157 [2] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. 158 Li, A. Conta. "MPLS Label Stack Encoding", draft-ietf-mpls- 159 label-encaps-07.txt, IETF Work in Progress. September 1999. 160 [3] Jamoussi et al. "Constraint-Based LSP Setup using LDP", draft- 161 ietf-mpls-cr-ldp-03.txt, IETF Work in Progress. September 1999. 162 [4] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. 163 "LDP Specification", draft-ietf-mpls-ldp-06.txt, IETF Work in 164 Progress. October 1999. 165 [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. 166 Viswanathan. "A Framework for Multiprotocol Label Switching", 167 draft-ietf-mpls-framework-05.txt, IETF Work in Progress. 168 September 1999. 170 4.0 Acknowledgements 172 The Authors would like to acknowledge John Shriver for his useful 173 comments to an earlier version of this document. 175 5.0 Authors' Addresses 177 Questions about this memo can be directed to: 179 Pat R. Calhoun 180 Network and Security Research Center, Sun Labs 181 Sun Microsystems, Inc. 182 15 Network Circle 183 Menlo Park, California, 94025 184 USA 186 Phone: 1-650-786-7733 187 Fax: 1-650-786-6445 188 E-mail: pcalhoun@eng.sun.comt 190 Ken Peirce 191 Malibu Networks 192 1035 Suncast Lane, Suite 130 193 El Dorado Hills, CA, 95762 195 Phone: 1-916-941-8814 196 Fax: 1-916-941-8850 197 E-mail: Ken@malibunetworks.com