GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7387

Internet Engineering Task Force (IETF) R. Key, Ed. Request for Comments: 7387 Category: Informational L. Yong, Ed. ISSN: 2070-1721 Huawei

                                                             S. Delord
                                                               Telstra
                                                             F. Jounay
                                                             Orange CH
                                                                L. Jin
                                                          October 2014
           A Framework for Ethernet Tree (E-Tree) Service
        over a Multiprotocol Label Switching (MPLS) Network

Abstract

 This document describes an Ethernet-Tree (E-Tree) solution framework
 for supporting the Metro Ethernet Forum (MEF) E-Tree service over a
 Multiprotocol Label Switching (MPLS) network.  The objective is to
 provide a simple and effective approach to emulate E-Tree services in
 addition to Ethernet LAN (E-LAN) services on an existing MPLS
 network.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7387.

Key, et al. Informational [Page 1] RFC 7387 E-Tree Framework October 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
    1.1. Terminology ................................................3
 2. Overview ........................................................4
    2.1. Ethernet Bridge Network ....................................4
    2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree .........4
    2.3. IETF L2VPN .................................................5
         2.3.1. Virtual Private LAN Service (VPLS) ..................5
         2.3.2. Ethernet VPN (EVPN) .................................5
         2.3.3. Virtual Private Multicast Service (VPMS) ............6
 3. E-Tree Architecture Reference Model .............................6
 4. E-Tree Use Cases ................................................8
 5. L2VPN Gaps for Emulating MEF E-Tree Service .....................9
    5.1. No Differentiation on AC Role ..............................9
    5.2. No AC Role Indication or Advertisement .....................9
    5.3. Other Issues ...............................................9
 6. Security Considerations ........................................10
 7. References .....................................................11
    7.1. Normative References ......................................11
    7.2. Informative References ....................................11
 Acknowledgments ...................................................12
 Contributors ......................................................12
 Authors' Addresses ................................................13

Key, et al. Informational [Page 2] RFC 7387 E-Tree Framework October 2014

1. Introduction

 This document describes an Ethernet-Tree (E-Tree) solution framework
 for supporting the Metro Ethernet Forum (MEF) E-Tree service over a
 Multiprotocol Label Switching (MPLS) network.  The objective is to
 provide a simple and effective approach to emulate E-Tree services in
 addition to Ethernet LAN (E-LAN) services on an existing MPLS
 network.
 This document extends the existing IETF-specified Layer 2 Virtual
 Private Network (L2VPN) framework [RFC4664] to provide the emulation
 of E-Tree services over an MPLS network.  It specifies the E-Tree
 architecture reference model and describes the corresponding
 functional components.  It also points out the gaps and required
 extension areas in existing L2VPN solutions such as Virtual Private
 LAN Service (VPLS) [RFC4761] [RFC4762] and Ethernet Virtual Private
 Network (EVPN) [EVPN] for supporting E-Tree services.

1.1. Terminology

 This document adopts all the terminologies defined in RFC 4664
 [RFC4664], RFC 4761 [RFC4761], and RFC 4762 [RFC4762].  It also uses
 the following terms:
 Leaf Attachment Circuit (AC): An AC with Leaf role.  An ingress
    Ethernet frame at a Leaf AC (Ethernet frame arriving over an AC at
    the Provider Edge (PE) of an MPLS network) can only be delivered
    to one or more Root ACs in an E-Tree service instance.  An ingress
    Ethernet frame at a Leaf AC must not be delivered to any Leaf ACs
    in the E-Tree service instance.
 Root AC: An AC with Root role.  An ingress Ethernet frame at a Root
    AC can be delivered to one or more of the other ACs in the
    associated E-Tree service instance.
 E-Tree: An Ethernet VPN service in which each AC is assigned the role
    of a Root or Leaf.  The forwarding rules in an E-Tree are as
    follows:
    o  The Root AC can communicate with other Root ACs and Leaf ACs.
    o  Leaf ACs can only communicate with Root ACs.

Key, et al. Informational [Page 3] RFC 7387 E-Tree Framework October 2014

2. Overview

2.1. Ethernet Bridge Network

 In this document, "Ethernet bridge network" refers to the Ethernet
 bridge/switch network defined in IEEE 802.1Q [IEEE802.1Q].  In a
 bridge network, a data frame is an Ethernet frame; data forwarding is
 based on destination Media Access Control (MAC) address; MAC
 reachability is learned in the data plane based on the source MAC
 address and the port (or tagged port) on which the frame arrives; and
 the MAC aging mechanism is used to remove inactive MAC addresses from
 the MAC forwarding table on an Ethernet switch.
 Data frames arriving at a switch may be destined to known unicast,
 unknown unicast, multicast, or broadcast MAC destinations.  Unknown
 unicast, multicast, and broadcast frames are forwarded in a similar
 way, i.e., to every port except the ingress port on which the frame
 arrives.  Multicast forwarding can be further constrained when using
 multicast control protocol snooping or using multicast MAC
 registration protocols [IEEE802.1Q].
 An Ethernet host receiving an Ethernet frame checks the destination
 address in the frame to decide whether it is the intended
 destination.

2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree

 MEF 6.1 [MEF6.1] defines two multipoint Ethernet Service types:
 o  E-LAN (Ethernet LAN), a multipoint-to-multipoint service
 o  E-Tree (Ethernet Tree), a rooted-multipoint service
 The MEF defines User-Network Interface (UNI) in a multipoint service
 as the Ethernet interface between Customer Equipment (CE) and a
 Provider Edge (PE), i.e., the PE can send and receive Ethernet frames
 to/from the CE.  The MEF also defines UNI roles in a multipoint
 service.  One role is Root, and another is Leaf.
 Note that MEF UNI in a service is equivalent to the Attachment
 Circuit (AC) defined in L2VPN [RFC4664].  The Root AC and Leaf AC
 defined in this document are the same as the Root UNI and Leaf UNI as
 defined in MEF 10.3 [MEF10.3].  The terms "Root AC" and "Leaf AC" are
 used in the following MEF service description.

Key, et al. Informational [Page 4] RFC 7387 E-Tree Framework October 2014

 For an E-LAN service, all ACs have the Root role, which means that
 any AC can communicate with other ACs in the service.  The E-LAN
 service defined by the MEF may be implemented by IETF L2VPN solutions
 such as VPLS and EVPN [EVPN].
 An E-Tree service has one or more Root ACs and at least two Leaf ACs.
 An E-Tree service supports communication among the roots and between
 a root and a leaf but prohibits communication among the leaves.
 Existing IETF L2VPN solutions can't support the E-Tree service.  This
 document specifies the E-Tree architecture reference model that
 supports the E-Tree service defined by the MEF [MEF6.1].  Section 4
 will discuss different E-Tree use cases.

2.3. IETF L2VPN

2.3.1. Virtual Private LAN Service (VPLS)

 VPLS [RFC4761] [RFC4762] is an L2VPN solution that provides
 multipoint-to-multipoint Ethernet connectivity across IP/MPLS
 networks.  VPLS emulates traditional Ethernet Virtual LAN (VLAN)
 services in MPLS networks and may support MEF E-LAN services.
 A data frame in VPLS is an Ethernet frame.  Data forwarding in a VPLS
 instance is based on the destination MAC address and the VLAN on
 which the frame arrives.  MAC reachability learning is performed in
 the data plane based on the source address and the AC or pseudowire
 (PW) on which the frame arrives.  MAC aging is the mechanism used to
 remove inactive MAC addresses from a VPLS switching instance (VSI) on
 a PE.  VPLS supports forwarding for known unicast frames, as well as
 unknown unicast, broadcast, and multicast Ethernet frames.
 Many service providers have deployed VPLS in their networks to
 provide L2VPN services to customers.

2.3.2. Ethernet VPN (EVPN)

 Ethernet VPN [EVPN] is an enhanced L2VPN solution that emulates an
 Ethernet LAN or virtual LAN(s) across MPLS networks.
 EVPN supports active-active multihoming of CEs and uses the
 Multiprotocol Border Gateway Protocol (MP-BGP) control plane to
 advertise MAC address reachability from an ingress PE to egress PEs.
 Thus, a PE learns MAC addresses that are reachable over local ACs in
 the data plane and other MAC addresses reachable across the MPLS
 network over remote ACs via the EVPN MP-BGP control plane.  As a
 result, EVPN aims to support large-scale L2VPN with better resiliency
 compared to VPLS.

Key, et al. Informational [Page 5] RFC 7387 E-Tree Framework October 2014

 EVPN is a relatively new technique and is still under development in
 the IETF L2VPN WG.

2.3.3. Virtual Private Multicast Service (VPMS)

 VPMS [VPMS] is an L2VPN solution that provides point-to-multipoint
 connectivity across MPLS networks and supports various attachment
 circuit (AC) types, including Frame Relay, ATM, Ethernet, PPP, etc.
 In the case of Ethernet ACs, VPMS provides single coverage of
 receiver membership, i.e., there is no differentiation among
 multicast groups in one VPN.  The destination address in the Ethernet
 frame is not used in data forwarding.
 VPMS supports unidirectional point-to-multipoint transport from a
 sender to multiple receivers and may support reverse transport in a
 point-to-point manner.

3. E-Tree Architecture Reference Model

 Figure 1 illustrates the E-Tree architecture reference model.  Three
 Provider Edges -- PE1, PE2, and PE3 -- are shown in the figure.  Each
 PE has a Virtual Service Instance (VSI) associated with an E-Tree
 service instance.  A CE attaches to the VSI on a PE via an AC.  Each
 AC must be configured with a Root or Leaf role.  In Figure 1, AC1,
 AC2, AC5, AC6, AC9, and AC10 are Root ACs; AC3, AC4, AC7, AC8, AC11,
 and AC12 are Leaf ACs.  This implies that a PE (local or remote)
 processes the Ethernet frames from CE01, CE02, etc., as if they
 originated from a Root AC, and it processes the Ethernet frames from
 CE03, CE04, etc., as if they originated from a Leaf AC.
 Under this architecture model, the forwarding rules among the ACs,
 regardless of whether the sending AC and receiving AC are on the same
 PE or on different PEs, are described as follows:
 o  An egress frame (the frame to be transmitted over an AC) at an AC
    with Root role must be the result of an ingress frame at an AC
    (the frame received at an AC) that has Root or Leaf role and is
    attached to the same E-Tree service instance.
 o  An egress frame at the AC with Leaf role must be the result of an
    ingress frame at an AC that has Root role and is attached to the
    same E-Tree service instance.

Key, et al. Informational [Page 6] RFC 7387 E-Tree Framework October 2014

                   <------------E-Tree----------->
                PE1+---------+         +---------+PE2
  +----+           |  +---+  |         |  +---+  |           +----+
  |CE01+----AC1----+--+   |  |         |  |   +--+----AC5----+CE05|
  +----+ (Root AC) |  | V |  |         |  | V |  | (Root AC) +----+
  +----+           |  |   |  |         |  |   |  |           +----+
  |CE02+----AC2----+--+   |  |         |  |   +--+----AC6----+CE06|
  +----+ (Root AC) |  | S +--+---------+--+ S |  | (Root AC) +----+
  +----+           |  |   |  |         |  |   |  |           +----+
  |CE03+----AC3----+--+   |  |         |  |   +--+----AC7----+CE07|
  +----+ (Leaf AC) |  | I |  |         |  | I |  | (Leaf AC) +----+
  +----+           |  |   |  |         |  |   |  |           +----+
  |CE04+----AC4----+--+   |  |         |  |   +--+----AC8----+CE08|
  +----+ (Leaf AC) |  +-+-+  |         |  +-+-+  | (Leaf AC) +----+
                   +----+----+         +----+----+
                        |      MPLS Core    |
                        |              +----+----+
                        |              |  +-+-+  |           +----+
                        |              |  |   +--+----AC9----+CE09|
                        |              |  | V |  | (Root AC) +----+
                        |              |  |   |  |           +----+
                        |              |  |   +--+----AC10---+CE10|
                        +--------------+--+ S |  | (Root AC) +----+
                                       |  |   |  |           +----+
                                       |  |   +--+----AC11---+CE11|
                                       |  | I |  | (Leaf AC) +----+
                                       |  |   |  |           +----+
                                       |  |   +--+----AC12---+CE12|
                                       |  +---+  | (Leaf AC) +----+
                                   PE3 +---------+
                   <-------------E-Tree---------->
             Figure 1: E-Tree Architecture Reference Model
 These rules apply to all frame types, i.e., known unicast, unknown
 unicast, broadcast, and multicast.  For known unicast frames,
 forwarding in a VSI context is based on the destination MAC address.
 A VSI on a PE corresponds to an E-Tree service instance and maintains
 a MAC forwarding table that is isolated from other VSI tables on the
 PE.  It also keeps track of local AC roles.  The VSI receives a frame
 from an AC or across the MPLS core, and it forwards the frame to
 another AC over which the destination is reachable according to the
 VSI forwarding table and forwarding rules described above.  When the
 target AC is on a remote PE, the VSI forwards the frame to the remote
 PE over the MPLS core.  Forwarding over the MPLS core will be
 dependent on the E-Tree solution.  For instance, a solution may adopt
 PWs to mesh VSIs as in VPLS and to forward frames over VSIs subject

Key, et al. Informational [Page 7] RFC 7387 E-Tree Framework October 2014

 to the E-Tree forwarding rules.  Alternatively, a solution may adopt
 the EVPN forwarding paradigm constrained by the E-Tree forwarding
 rules.  Thus, solutions that satisfy the E-Tree requirements could be
 extensions to VPLS and EVPN.
 In most use cases, an E-Tree service has only a few Root ACs (root CE
 sites) but many Leaf ACs (leaf CE sites).  Furthermore, a PE may have
 only Root ACs or only Leaf ACs.  Figure 1 provides a general E-Tree
 architecture model.

4. E-Tree Use Cases

 Table 1 below presents some major use cases for E-Tree.
        +---------------------------+--------------+------------+
        | Use Case                  | Root AC      | Leaf AC    |
    +---+---------------------------+--------------+------------+
    | 1 | Hub & Spoke VPN           | Hub Site     | Spoke Site |
    +---+---------------------------+--------------+------------+
    | 2 | Wholesale Access          | Customer's   | Customer's |
    |   |                           | Interconnect | Subscriber |
    +---+---------------------------+--------------+------------+
    | 3 | Mobile Backhaul           | RAN NC       | RAN BS     |
    +---+---------------------------+--------------+------------+
    | 4 | IEEE 1588 PTPv2 [IEEE1588]| PTP Server   | PTP Client |
    |   | Clock Synchronization     |              |            |
    +---+---------------------------+--------------+------------+
    | 5 | Internet Access           | BNG Router   | Subscriber |
    |   | Reference [TR-101]        |              |            |
    +---+---------------------------+--------------+------------+
    | 6 | Broadcast Video           | Video Source | Subscriber |
    |   | (unidirectional only)     |              |            |
    +---+---------------------------+--------------+------------+
    | 7 | Broadcast/Multicast Video | Video Source | Subscriber |
    |   | plus Control Channel      |              |            |
    +---+---------------------------+--------------+------------+
    | 8 | Device Management         | Management   | Managed    |
    |   |                           | System       | Device     |
    +---+---------------------------+--------------+------------+
 Where:
    RAN: Radio Access Network       NC: Network Controller
    BS: Base Station                PTP: Precision Time Protocol
    BNG: Broadband Network Gateway
                       Table 1: E-Tree Use Cases

Key, et al. Informational [Page 8] RFC 7387 E-Tree Framework October 2014

 Common to all use cases, direct Layer 2 leaf-to-leaf communication is
 required to be prohibited.  For mobile backhaul, this may not be
 valid for Long Term Evolution (LTE) X2 interfaces; an LTE X2
 interface [LTE] enables communication between two evolved Node Bs
 (eNBs).  E-Tree service is appropriate for such use cases.
 Also common to the use cases mentioned above, there may be one or
 multiple Root ACs in one E-Tree service.  The need for multiple Root
 ACs may be driven by a redundancy requirement or by having multiple
 serving sites.  Whether a particular E-Tree service needs to support
 one or multiple Root ACs depends on the application.

5. L2VPN Gaps for Emulating MEF E-Tree Service

 The MEF E-Tree service defines special forwarding rules that prohibit
 forwarding Ethernet frames among leaves.  This poses some challenges
 to IETF L2VPN solutions such as VPLS and EVPN in emulating E-Tree
 service over an MPLS network.  There are two major issues described
 in the following subsections.

5.1. No Differentiation on AC Role

 IP/MPLS L2VPN architecture has no distinct roles on Attachment
 Circuits (ACs) and supports any-to-any connectivity among all ACs.
 It does not have any mechanism to support forwarding constraints
 based on an AC role.  However, the MEF E-Tree service defines two AC
 roles -- Root and Leaf -- and defines the forwarding rules based on
 the originating and receiving AC roles of a given frame.

5.2. No AC Role Indication or Advertisement

 In an L2VPN, when a PE, say PE2, receives a frame from another PE,
 say PE1, over the MPLS core, PE2 does not know if the frame from PE1
 is originated from a Root AC or Leaf AC.  This causes the forwarding
 issue on PE2 because the E-Tree forwarding rules require that the
 forwarder must know the role of the frame origin, i.e., from Root AC
 or Leaf AC.  This is specifically important when PE2 has both Root AC
 and Leaf AC attached to the VSI.  E-Tree forwarding rules apply to
 all types of frames (known unicast destination, unknown unicast
 destination, multicast, and broadcast).

5.3. Other Issues

 Some desirable requirements for IETF E-Tree are specific to an
 IP/MPLS L2VPN implementation such as Leaf-only PE.  A Leaf-only PE is
 a PE that only has Leaf AC(s) in an E-Tree service instance; thus,
 other PEs on the same E-Tree service instance do not necessarily
 forward the frames originated from a Leaf AC to the Leaf-only PE,

Key, et al. Informational [Page 9] RFC 7387 E-Tree Framework October 2014

 which may save some network resources.  It is also desirable for an
 E-Tree solution to work with existing PEs that support single-role
 ACs, where the role is equivalent to the root in an E-Tree service.
 These requirements are described in the E-Tree requirement document
 [RFC7152].

6. Security Considerations

 An E-Tree service may be deployed for security reasons to prohibit
 communication among sites (leaves).  An E-Tree solution must enforce
 E-Tree forwarding constraints.  The solution must also guarantee that
 Ethernet frames do not leak outside of the E-Tree service instance to
 which they belong.
 An E-Tree service prohibits communication among leaf sites but does
 not have knowledge of higher-layer security constraints.  Therefore,
 in general, higher-layer applications cannot rely on E-Tree to
 provide security protection unless all security constraints are fully
 implemented by the E-Tree service.
 Enhancing L2VPN for E-Tree services inherits the same security issues
 described in the L2VPN framework document [RFC4664].  These relate to
 both control-plane and data-plane security issues that may arise in
 the following areas:
 o  issues fully contained in the provider network
 o  issues fully contained in the customer network
 o  issues in the customer-provider interface network
 The framework document has substantial discussions on the security
 issues and potential solutions to address them.  An E-Tree solution
 must consider these issues and address them properly.  VPLS [RFC4761]
 [RFC4762] and/or EVPN [EVPN] will likely be candidate solutions for
 an E-Tree service over an MPLS network.  The security capabilities
 built into those solutions will be naturally adopted when supporting
 E-Tree.  For details, see the Security Considerations sections in
 [RFC4761], [RFC4762], and [EVPN].

Key, et al. Informational [Page 10] RFC 7387 E-Tree Framework October 2014

7. References

7.1. Normative References

 [MEF6.1]     Metro Ethernet Forum, "Ethernet Services Definitions -
              Phase 2", MEF 6.1, April 2008.
 [MEF10.3]    Metro Ethernet Forum, "Ethernet Service Attributes -
              Phase 3", MEF 10.3, October 2013.
 [RFC4664]    Andersson, L., Ed., and E. Rosen, Ed., "Framework for
              Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
              September 2006,
              <http://www.rfc-editor.org/info/rfc4664>.
 [RFC4761]    Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, January 2007,
              <http://www.rfc-editor.org/info/rfc4761>.
 [RFC4762]    Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
              Private LAN Service (VPLS) Using Label Distribution
              Protocol (LDP) Signaling", RFC 4762, January 2007,
              <http://www.rfc-editor.org/info/rfc4762>.
 [RFC7152]    Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu,
              Z., and M. Paul, "Requirements for Metro Ethernet Forum
              (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual
              Private Network (L2VPN)", RFC 7152, March 2014,
              <http://www.rfc-editor.org/info/rfc7152>.

7.2. Informative References

 [IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Media Access Control (MAC) Bridges and
              Virtual Bridged Local Area", IEEE Std 802.1Q, 2011.
 [IEEE1588]   IEEE, "IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems", IEEE Std 1588, July 2008.
 [LTE]        3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA) and Evolved Universal Terrestrial Radio Access
              Network (E-UTRAN)", 3GPP TS 36.300 v11.2.0, July 2012.
 [TR-101]     Broadband Forum, "Migration to Ethernet-Based Broadband
              Aggregation", TR-101 Issue 2, July 2011.

Key, et al. Informational [Page 11] RFC 7387 E-Tree Framework October 2014

 [VPMS]       Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
              and L. Jin, "Framework and Requirements for Virtual
              Private Multicast Service (VPMS)", Work in Progress,
              draft-ietf-l2vpn-vpms-frmwk-requirements-05,
              October 2012.
 [EVPN]       Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in
              Progress, draft-ietf-l2vpn-evpn-11, October 2014.

Acknowledgments

 The authors would like to thank Nabil Bitar and Adrian Farrel for
 their detailed review and suggestions.

Contributors

 The following people contributed significantly to this document.
 Yuji Kamite
 NTT Communications Corporation
 Granpark Tower
 3-4-1 Shibaura, Minato-ku
 Tokyo 108-8118, Japan
 EMail: y.kamite@ntt.com
 Wim Henderickx
 Alcatel-Lucent
 Copernicuslaan 50
 2018 Antwerp, Belgium
 EMail: wim.henderickx@alcatel-lucent.com

Key, et al. Informational [Page 12] RFC 7387 E-Tree Framework October 2014

Authors' Addresses

 Raymond Key (editor)
 EMail: raymond.key@ieee.org
 Lucy Yong (editor)
 Huawei USA
 EMail: lucy.yong@huawei.com
 Simon Delord
 Telstra
 EMail: simon.delord@gmail.com
 Frederic Jounay
 Orange CH
 4 rue caudray 1020 Renens
 Switzerland
 EMail: frederic.jounay@orange.ch
 Lizhong Jin
 EMail: lizho.jin@gmail.com

Key, et al. Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7387.txt · Last modified: 2014/10/23 21:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki