idnits 2.17.1 draft-rekhter-mpls-over-gre-01.txt: ** The Abstract section seems to be numbered 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 61 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 35 has weird spacing: '...n cases it ma...' == Line 50 has weird spacing: '...eld may be co...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter 2 Internet Draft Juniper Networks 3 Expiration Date: August 2001 Daniel Tappan 4 Cisco Systems 5 Eric Rosen 6 Cisco Systems 8 MPLS Label Stack Encapsulation in GRE 10 draft-rekhter-mpls-over-gre-01.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 In certain cases it may be useful to carry MPLS packets through a 36 GRE tunnel. This document describes how to do that using existing 37 standards. 39 3. Encapsulation in GRE 41 If one wants to establish a Label Switched Path (LSP) over a set of 42 nodes that don't support MPLS, one could encapsulate MPLS header in 43 GRE [RFC2784] over the parts of the path that spans these nodes. The 44 protocol type field in the GRE header should be set to the Ethertype 45 value for MPLS Unicast (0x8847) or Multicast (0x8848). 47 If GRE is extended to carry the Key field [RFC2890], then in 48 principle the outer label in the MPLS header could be placed in the 49 Key field, the TTL field could be placed in the TTL field of the IP 50 header, and the value of the EXP field may be considered when 51 setting the value of the DSCP field of the IP header. The Protocol 52 Type field in the GRE header is set to the L3PID of the LSP. 53 Specifically, when the MPLS Label Stack has depth of more than one, 54 the Protocol Type field in the GRE header is set to MPLS. Of course, 55 one could observe that in terms of the overhead encoding the outer 56 label into the Key field doesn't offer any obvious advantages over 57 carrying the outer label in the MPLS "shim" header and not using the 58 Key field at all. 60 One could observe that the above approach also works between directly 61 connected nodes. In this case the encoding described in the previous 62 paragraph provides (yet another) way to carry MPLS Labels over a 63 point-to-point or Ethernet links. However, in this scenario this 64 encoding of MPLS Labels introduces additional bandwidth and 65 processing overhead relative to carrying labels just in the MPLS 66 "shim" header, and no rational benefits. And it still requires the 67 nodes to support MPLS, as forwarding is based on the MPLS Label. 69 4. Security Considerations 71 Security issues are not discussed in this document. 73 5. Acknowledgements 75 TBD. 77 6. References 79 [RFC2784] 81 [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, 82 RFC2890, August 2000 84 7. Author Information 86 Yakov Rekhter 87 Juniper Networks, Inc. 88 1194 N. Mathilda Ave. 89 Sunnyvale, CA 94089 90 Email: yakov@juniper.net 92 Dan Tappan 93 Cisco Systems, Inc. 94 250 Apollo Drive 95 Chelmsford, MA, 01824 96 e-mail: tappan@cisco.com 98 Eric Rosen 99 Cisco Systems, Inc. 100 250 Apollo Drive 101 Chelmsford, MA, 01824 102 e-mail: erosen@cisco.com