idnits 2.17.1 draft-rekhter-mpls-over-gre-03.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 36 has weird spacing: '...n cases it ma...' == Line 51 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. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Juniper Networks 4 Expiration Date: March 2002 Daniel Tappan 5 Cisco Systems 6 Eric Rosen 7 Cisco Systems 9 MPLS Label Stack Encapsulation in GRE 11 draft-rekhter-mpls-over-gre-03.txt 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 In certain cases it may be useful to carry MPLS packets through a 37 GRE tunnel. This document describes how to do that using existing 38 standards. 40 3. Encapsulation in GRE 42 If one wants to establish a Label Switched Path (LSP) over a set of 43 nodes that don't support MPLS, one could encapsulate MPLS header in 44 GRE [RFC2784] over the parts of the path that spans these nodes. The 45 protocol type field in the GRE header should be set to the Ethertype 46 value for MPLS Unicast (0x8847) or Multicast (0x8848). 48 If GRE is extended to carry the Key field [RFC2890], then in 49 principle the outer label in the MPLS header could be placed in the 50 Key field, the TTL field could be placed in the TTL field of the IP 51 header, and the value of the EXP field may be considered when 52 setting the value of the DSCP field of the IP header. The Protocol 53 Type field in the GRE header is set to the L3PID of the LSP. 54 Specifically, when the MPLS Label Stack has depth of more than one, 55 the Protocol Type field in the GRE header is set to MPLS. Of course, 56 one could observe that in terms of the overhead encoding the outer 57 label into the Key field doesn't offer any obvious advantages over 58 carrying the outer label in the MPLS "shim" header and not using the 59 Key field at all. 61 One could observe that the above approach also works between directly 62 connected nodes. In this case the encoding described in the previous 63 paragraph provides (yet another) way to carry MPLS Labels over a 64 point-to-point or Ethernet links. However, in this scenario this 65 encoding of MPLS Labels introduces additional bandwidth and 66 processing overhead relative to carrying labels just in the MPLS 67 "shim" header, and no rational benefits. And it still requires the 68 nodes to support MPLS, as forwarding is based on the MPLS Label. 70 4. Security Considerations 72 Security issues are not discussed in this document. 74 5. Acknowledgements 76 TBD. 78 6. References 80 [RFC2784] 82 [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, 83 RFC2890, August 2000 85 7. Author Information 87 Yakov Rekhter 88 Juniper Networks, Inc. 89 1194 N. Mathilda Ave. 90 Sunnyvale, CA 94089 91 Email: yakov@juniper.net 93 Dan Tappan 94 Cisco Systems, Inc. 95 250 Apollo Drive 96 Chelmsford, MA, 01824 97 e-mail: tappan@cisco.com 99 Eric Rosen 100 Cisco Systems, Inc. 101 250 Apollo Drive 102 Chelmsford, MA, 01824 103 e-mail: erosen@cisco.com