From DanielC@orckit.com Mon Apr 4 12:31:04 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13DD3A67A2 for ; Mon, 4 Apr 2011 12:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 922PmyOibxcY for ; Mon, 4 Apr 2011 12:31:04 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 542963A6765 for ; Mon, 4 Apr 2011 12:31:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of new L2VPN WG Charter Date: Mon, 4 Apr 2011 22:33:38 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306A2B4C5@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAkAAG8q8wDS/0aw References: From: "Daniel Cohn" To: "Giles Heron" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:31:05 -0000 Hi, I support the addition of e-tree to the charter. In line with similar concerns expressed in the list, I'm not sure = however that E-VPN needs to be explicitly mentioned in the charter, and = if so whether it cannot be addressed by extending the VPLS clause. Regards, Daniel > On 3/18/11 1:21 PM, "Giles Heron" wrote: >=20 > OK - looks like the attachment didn't come through as intended. My > apologies. >=20 > Text inline: >=20 > ---------------- >=20 > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned = Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements = driven > by cloud computing services and data centers as they apply to Layer-2 > VPN services. >=20 > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may = not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG = will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of = existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. >=20 > Layer-2 VPNs comprise the following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates > a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN). >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >=20 > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. >=20 > 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will > address two specific types of IP-only L2VPN: >=20 > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. >=20 > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, > but learns IP and MAC address bindings from ARPs and = broadcast/multicast > IP packets. >=20 > 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC = address > bindings in the VPN. E-VPN is primarily targeted to support = large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >=20 > 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides > connectivity between one or more =B3root=B2 nodes and one or more > =B3leaf=B2 nodes, with the restriction that leaves may only = communicate > with roots (and not with each other). >=20 > L2VPNs will make use of existing IETF specified mechanisms unless = there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. >=20 > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols that will = be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. >=20 > The L2VPN WG will not define new encapsulations, control, or = resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 = service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. >=20 > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. >=20 > 3. MIBs for Layer-2 VPN solutions. >=20 > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type = of > L2VPN. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. >=20 > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. >=20 > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN = control > plane solutions for achieving fast convergence after failure of an = active > path in the PSN or on the AC side. >=20 > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. >=20 > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized > L2VPNs. >=20 > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS.=20 >=20 > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that = are > chartered to do MPLS TP work. >=20 > Milestones: >=20 > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as = Informational > RFC > Done Submit L2 framework to IESG for publication as = Informational RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS > VPLS and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to = IESG > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to = IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2012 Submit E-VPN solution to IESG > Nov 2012 Submit E-VPN MIB/OAM to IESG >=20 > ----------------- >=20 > On 18/03/2011 17:41, "Giles Heron" wrote: >=20 >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >> in-scope. >>=20 >> Please find attached a draft charter for discussion both on this list = and at >> IETF 80 in Prague. >>=20 >> Nabil and Giles >>=20 >>=20 >=20 >=20 >=20 From erosen@cisco.com Mon Apr 4 13:18:17 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991A93A67CF for ; Mon, 4 Apr 2011 13:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F61o6r7oZbHL for ; Mon, 4 Apr 2011 13:18:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 302363A67B1 for ; Mon, 4 Apr 2011 13:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=26312; q=dns/txt; s=iport; t=1301948398; x=1303157998; h=to:subject:reply-to:date:message-id:from; bh=tQvUk/RjmzW7gBvpLPYJGQeKNyNDdz6olwgNckqL3yk=; b=WIAdPAl7BBXJtK47EvjTTjsolBw50/Di3sOAd9TEkR3vzmZsDXC6cN2S QA1ocfAOOcu5DcHHhJ8SZkwAsPUvKTjx9AXgZtEoEfyjKXG1XoQiPp5j7 M8urc0NvXXRYeCAdK6B9Pqx/OJnhL6tm2QGV7TSYYWBPpxt3o29NLyKgk w=; X-IronPort-AV: E=Sophos;i="4.63,299,1299456000"; d="scan'208";a="675550680" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2011 20:19:57 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34KJvJ5025103; Mon, 4 Apr 2011 20:19:57 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p34KJuWI002718; Mon, 4 Apr 2011 16:19:56 -0400 To: l2vpn@ietf.org Subject: Comments on draft-ietf-l2vpn-vpls-mcast-08 X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Mon, 04 Apr 2011 16:19:56 -0400 Message-ID: <2717.1301948396@erosen-linux> From: Eric Rosen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:18:17 -0000 Since I haven't been following this mailing list regularly, I missed the WG LC on draft-ietf-l2vpn-vpls-mcast-08. I do have a few comments to make though; fortunately IETF LC has not occurred yet. 1. "Snooped State" >From section 11.3: If as a result of IGMP or PIM snooping on the PE-CE interfaces, the PE has snooped state for at least one multicast join that matches the multicast source and group advertised in the S-PMSI A-D route. The document contains no definition of "IGMP snooping" or "PIM snooping", nor any reference to another document defining these terms. The document proceeds to freely use the term "snooped state", without any definition. Without a definition of (or normative reference to such a definition) "snooping" and "snooped state", I don't see how this document can claim to be implementable. 2. How does traffic get from a multicast source to the designated router? Consider group G. Suppose site 1 contains the DR (but no sources or receivers), site 2 contains the source S, site 3 contains a receiver R. The PE attached to site 2 might set up a selective tree for (S,G), and the PE attached to site 3 will join the selective tree, no doubt due to it's having "snooped state" indicating that there is a receiver at site 3. The PE attached to site 1 also needs to join the selective tree, or S will be cut off from its DR. However, I don't see where in the draft it provides a procedure causing the site 1 PE to join the selective tree. Presumably there has to be some "snooping" of the DR election. But this doesn't seem to be mentioned at all. 3. Applicability Restrictions The following applicability restriction is stated: These procedures are applicable when IGMP is used as the multicast routing protocol between the VPLS CEs. They are also applicable when PIM is used as the multicast routing protocol between the VPLS CEs and PIM join suppression is disabled on all the CEs. However these procedures do not apply when PIM is used as the multicast routing protocol between the VPLS CEs and it not possible to disable PIM join suppression on all the CEs This suggests, incorrectly, that PIM and IGMP will not be running on the same LAN. (Not sure whether that is the intention or not.) I think the correct statement of the applicability restriction is the following: These procedures are not applicable if any VPLS CE, or any other host or router that is bridged to the VPLS, uses a multicast control protocol that does not periodically retransmit control messages stating the set of (S,G) and (*,G) flows in which it is interested. Among such CEs are the following: - CEs that run PIM, but that have join suppression enabled (i.e., the vast majority of systems running PIM). Note that the issue is not whether it is "possible to disable PIM join suppression on all the CEs", but whether it has actually been disabled. - CEs that run the protocol specified in draft-ietf-pim-port-06.txt. - CEs that run the protocol specified in draft-ietf-l3vpn-2547bis-mcast- bgp. There should also be a clear statement to SPs that if a customer deploys such a CE, the VPLS multicast service will create black holes that are going to be difficult for the SP to troubleshoot. If the document is going to recommend that join suppression be disabled (if possible), there should be some discussion of the costs of disabling join suppression. 4. Allowable P-Tunnel Technologies It is clear that the document allows the use of RSVP-TE P2MP and allows the use of mLDP. It is very difficult to understand just what the intention is with respect to other tunneling technologies. The document claims that the architecture is flexible enough to support other technologies, but it also says that other technologies are not supported. Right now the document does not appear to make a consistent statement about this, leaving it unclear whether the document means to prohibit other technologies or not. Perhaps what it should say is just that other technologies are outside the scope of this document. 5. Options, models, variants The terminology in section 10 is very confusing. The terms "options", "models", and "variants" are not used in a consistent manner. - Section 10 mentions "options" a, b, and c, then proceeds almost immediately (section 10.2) to an option e, which is never explicitly defined. - Options a, b, and c are called "three models", and there is a requirement to support all three "models". Then the text goes on to say that options a and b use a single "model" ("where inter-AS VPLS service can be offered without requiring a single P-multicast tree to span multiple ASes".) Then there are two "variants" of this "model". - I think the intention is that there are two "variants": "VSIs on the ASBRs", and "Segmented Inter-AS Trees", and that these two variants combine with the four "options" (a, b, c, and e) to make a total of 5 models: * Model 1: Option (a) plus the variant "VSIs on the ASBRS" * Model 2: Option (e) plus the variant "VSIs on the ASBRS" * Model 3: Option (b) plus the variant "Segmented Inter-AS Trees" * Model 4: Option (c) plus the variant "Segmented Inter-AS Trees" * Model 5: Option (c) plus non-segmented Inter-AS trees but without VSIs on the ASBRs (not sure I got this one right, this seems like a hitherto unmentioned "variant"). The terminology in section 10 really needs to be cleaned up for clarity and consistency. 6. Section 11.2.1 This section is referred to multiple times, as the place where the explicit tracking procedures are specified. However, there is no section 11.2.1. I suspect the proper reference is 11.3. 6. Miscellaneous comments >From the introduction (section 4), page 5: [RFC4761] and [RFC4762] describe a solution for VPLS multicast that relies on ingress replication. "Ingress replication" should be defined; I don't think this term appears in either RFC4761 or RFC4762. Also from the introduction, page 5: It provides mechanisms that allow a single multicast distribution tree in the Service Provider (SP) network to carry all the multicast traffic from one or VPLS sites connected to a given PE, irrespective "from one or VPLS" --> "from one or more VPLS" >From the overview (section 6), page 6: This document describes procedures for using multicast trees for VPLS multicast when the provider tunneling technology is either P2MP RSVP- PE or mLDP [MLDP]. The protocol architecture described herein is considered to be flexible to support other P-tunneling technologies as well. The phrase "either P2MP RSVP-PE or mLDP" is mangled. I think what is intended is "P2MP LSPs created either by RSVP-TE or mLDP". Page 7 The ability to carry the traffic of more than one VPLS on the same tree is termed of the VPLSes that are using the tree. This "is termed of the VPLSes", looks like a cut-and-paste error of some sort. An Inclusive P-Multicast tree as defined in this document is a P2MP tree. A P2MP tree is used to carry traffic only for VPLS sites that are connected to the PE that is the root of the tree. I suggest "carry traffic only for" be replaced by "carry traffic only from", as "for" could be taken to mean either "to" or "from" or "both" in this context. Note that this paragraph seems to imply that MP2MP LSPs or PIM-BIDIR trees would not be Inclusive P-multicast trees "as defined in this document". Perhaps what it should say is "This document only defines procedures for instantiating an inclusive P-multicast tree as a P2MP LSP; other possible methods of instantiation are outside the scope of this document". This would be more consistent with the prior statement that the protocol architecture of the document is flexible enough to support other tunneling technologies. Also on page 7: 2. Selective trees. A Selective P-Multicast tree is used by a PE to send IP multicast traffic for one or IP more specific multicast streams, originated within sites connected to the PE, that belong to the same or different VPLSes, to a subset of the PEs that belong to those VPLSes. Each of the PEs in the subset should be on the path to a receiver of one or more multicast streams that are mapped onto the tree. The ability to use the same tree for multicast streams that belong to different VPLSes is termed a PE the ability to create "Is termed a PE the ability to create"? Maybe this should be "gives a PE the ability to create". I don't think it is correct to say that the traffic must have originated within a site connected to the PE; the traffic could have originated somewhere far away on the Internet, in a television studio, etc. Instead of "originated within sites connected to the PE", maybe what is meant is "received by the PE over a PE-CE interface". This error occurs in multiple places. Page 7 again: A SP can use both Inclusive P-Multicast trees and Selective P- Multicast trees or either of them for a given VPLS on a PE, based on local configuration. Inclusive P-Multicast trees can be used for both IP and non-IP data multicast traffic, while Selective P- Multicast trees can be used only for IP multicast data traffic. It might be better to say "using selective P-trees for anything other than IP multicast data traffic is outside the scope of this spec." If this is really meant to prohibit such use entirely, normative language ("MUST NOT") should be used. Once more, page 7: A variety of transport technologies may be used in the SP network. For inclusive P-Multicast trees, these transport technologies include point-to-multipoint LSPs created by RSVP-TE or mLDP. For selective P- Multicast trees, only unicast PE-PE tunnels (using MPLS or IP/GRE encapsulation) and P2MP LSPs are supported, and the supported P2MP LSP signaling protocols are RSVP-TE, and mLDP. It's not very clear what this paragraph is saying. If a technology is "not supported", does that mean it is outside the scope of this document, or that it is prohibited for some unspecified reason. (If the latter, the reason should be specified.) It's hard to understand why unicast tunnels are supported only for selective tunnels, why GRE encaps is supported only for unicast tunnels, etc. Page 8: However these procedures do not apply when PIM is used as the multicast routing protocol between the VPLS CEs and it not possible to disable PIM join suppression on all the CEs. Procedures for this case are for further study. Change "it not possible to disable PIM Join suppression on all the CEs" to "PIM Join Suppression is not disabled on all the CEs". But see also my prior comment on other multicast protocols for which every CE does not periodically retransmit every Join. Page 10: Aggregation requires a mechanism for the egresses of the P-Multicast tree to demultiplex the multicast traffic received over the P- Multicast tree. This document describes how upstream-assigned labels can be assigned and distributed by the root of aggregate P-Multicast tree and then used by the egresses to perform this demultiplexing. I think it would be clearer to replace the last sentence by "To enable the egress nodes to perform this demultiplexing, upstream-assigned labels [RFC5331] MUST be assigned and distributed by the root of the aggregate P-multicast tree". This would make it clear that upstream-assigned labels are a mandatory feature if (and only if) aggregation is used. Page 11: It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. However it is not an inherent feature of LDP-VPLS. Infact there are deployments and/or implementations of LDP-VPLS that require configuration to enable a PE in a particular VPLS to determine other PEs in the VPLS and exchange PW labels using FEC 128 [RFC4447]. The use of BGP A-D for LDP-VPLS [L2VPN-SIG], to enable automatic setup of PWs, requires FEC 129 [RFC4447]. However FEC 129 is not required in order to use BGP A-D for the setup of P-Multicast trees for LDP-VPLS as described in this document. An LDP-VPLS implementation that supports P-Multicast trees described in this document, MUST support the BGP A-D procedures to setup P-Multicast trees and it MAY support FEC 129 to automate the signaling of PWs. It's very unclear to me just what is and is not being required by this paragraph. If it's just that an LDP-VPLS implementation may support the procedures in this draft even if it doesn't support FEC 129, that seems fair enough. If it's that an LDP-VPLS implementation that uses P-multicast trees to optimize IP multicast MUST support the BGP A-D procedures described herein, that seems gratuitous. The phrase "supports P-multicast trees described in this document" is also unclear. Page 12: A PE that uses an Inclusive P-Multicast tree to instantiate the provider tunnel MAY aggregate two or more VPLSes present on the PE onto the same tree. If the PE decides to perform aggregation after it has already advertised the intra-AS VPLS auto-discovery routes for these VPLSes, then aggregation requires the PE to re-advertise these routes. Should there be some statement about when it's okay to start sending the data on the newly aggregated tunnel? Is it necessary or desirable to wait a certain amount of time? Page 12: The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the PE has not previously advertised intra-AS auto-discovery routes for these VPLSes, then the aggregation requires the PE to advertise (new) intra-AS auto-discovery routes for these VPLSes. The P-Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-Multicast tree that aggregates the VPLSes, as well as an MPLS upstream-assigned label [RFC5331]. Each re-advertised route MUST have a distinct label. For consistency, "P-Tunnel attribute" --> "PMSI Tunnel attribute" The requirement for a distinct label applies to the newly advertised routes as well as the re-advertised routes, no? Page 13: + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE P2MP LSP, the receiving PE has to establish the appropriate state to properly handle the traffic received over that LSP. The PE that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE as a leaf. This LSP MAY have been established before the local PE receives the route. Isn't a normative reference to draft-ietf-mpls-rsvp-te-no-php-oob-mapping- 05.txt needed here, for the case where the TE tunnel is established before its use has been communicated? Page 14: When a P-Multicast tree is mapped to only one VPLS, determining the tree on which the packet is received is sufficient to determine the VPLS instance on which the packet is received. The tree is determined based on the tree encapsulation. If MPLS encapsulation is used, eg: RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP (RSVP- TE P2MP LSP or LDP P2MP LSP). Doesn't this require a normative reference to draft-ietf-mpls-rsvp-te-no- php-oob-mapping-05.txt? Page 14, section 8.2: This document requires the use of upstream label assignment by the ingress PE [RFC5331]. It might be better to use 2119 language here, "If traffic from multiple VPLSes is carried on a single tree, upstream-assigned labels [RFC5331] MUST be used. Also page 14: If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the outer MPLS label and the incoming interface provides the label space of the label beneath it. This assumes that penultimate-hop-popping is disabled. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree. If the P2MP LSP is signaled before the BGP route is received, how does the egress PE know to avoid advertising NULL for that LSP? Page 15: 9. Establishing P-Multicast Trees This document does not place any fundamental restrictions on the multicast technology used to setup P-Multicast trees. However specific procedures are specified only for RSVP-TE P2MP LSPs and LDP P2MP LSPs. An implementation that supports this document MUST support RSVP-TE P2MP LSPs and LDP P2MP LSPs. The P-Multicast trees supported in this document are P2MP trees. It would be less confusing to say that "specific procedures are specified only for P2MP LSPs", otherwise it is hard to know what to make of these two paragraphs together. A P2MP tree is used to carry traffic originated in sites connected to the PE which is the root of the tree, irrespective of whether these sites belong to the same or different VPLSes. This suggests, incorrectly, that aggregation is always done. Maybe change "is used" to "MAY be used". 9.1. Common Procedures The following procedures apply to both RSVP-TE P2MP and LDP P2MP LSPs. Demultiplexing the C-multicast data packets at the egress PE requires that the PE must be able to determine the P2MP LSP that the packets are received on. This enables the egress PE to determine the VPLS that the packet belongs to. To achieve this the LSP MUST be signaled with penultimate-hop-popping (PHP) off as described in section 8. In other words an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for a P2MP LSP that is carrying traffic for one or more VPLSes. As I commented earlier, I don't think this draft explains how the egress knows to do this in the case of RSVP-TE P2MP LSPs. Page 17: 9.4. Encapsulation of Aggregate P-Multicast Trees An Aggregate Inclusive P-Multicast tree or an Aggregate Selective P- Multicast tree MUST use a MPLS encapsulation. The protocol type in the data link header is as described in [RFC5332]. Presumably the encapsulation used to send data on a certain tunnel is determined by the tunnel type. I'm not sure why this short section is needed, there is no section on encapsulation of non-aggregate trees. Page 27: These procedures are applicable when IGMP is used as the multicast routing protocol between the VPLS CEs. They are also applicable when PIM is used as the multicast routing protocol between the VPLS CEs and PIM join suppression is disabled on all the CEs. However these procedures do not apply when PIM is used as the multicast routing protocol between the VPLS CEs and it not possible to disable PIM join suppression on all the CEs. Procedures that allow the setup of Selective trees for this case are for further study. This paragraph is just repeated from earlier in the document. See my earlier comments. (Regardless of the disposition of those comments, this paragraph should probably not be repeated here.) Page 28: If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at the root of the tree MUST establish the P2MP RSVP-TE LSP to the leaves. This LSP MAY have been established before the leaves receive the Selective tree binding, or MAY be established after the leaves receives the binding. A leaf MUST not switch to the Selective tree until it receives the binding and the RSVP-TE P2MP LSP is setup to the leaf. This paragraph has already occurred before. Page 31: + If as a result of IGMP or PIM snooping on the PE-CE interfaces, the PE has snooped state for at least one multicast join that matches the multicast source and group advertised in the S-PMSI A-D route. Further if the oif (outgoing interfaces) for this state contains one or more interfaces to the locally attached CEs. As previously pointed out, "IGMP or PIM snooping" has to be defined and specified (perhaps via a normative reference). Otherwise there is no way to know what is meant below by "snooped state" how such states are created and destroyed, and exactly what states the PEs need to keep track of. Pages 31-32 The snooped state is said to "match" the S-PMSI A-D route if any of the following is true: + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is for (C-S, C-G). OR + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped state is for (C-*, C-G) OR (b) the snooped state is for at least one multicast join with the multicast group address equal to C-G and there doesn't exist another S-PMSI A-D route that carries (C- S, C-G) where C-S is the source address of the snooped state. + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped state is for at least one multicast join with the multicast source address equal to C-S, and (b) there doesn't exist another S-PMSI A-D route that carries (C-S, C-G) where C-G is the group address of the snooped state. + The S-PMSI A-D route carries (C-*, C-*) As this algorithm is specified, every "snooped state" matches an S-PMSI A-D route specifying (C-*,C-*), even if (C-*,C-*) is not the "longest match". I think what is meant is that the snooped state matches the S-PMSI A-D route that meets the first condition, if there is one; otherwise it matches the S-PMSI A-D route that meets the second condition, if there is one; otherwise it matches the S-PMSI A-D route that meets the third condition, if there is one; otherwise it matches the S-PMSI A-D route that meets the fourth condition, if there is one; otherwise there is no match. However, this is not what it says. Something should be specified to cover the case where the S-PMSI A-D route does not match any "snooped state", and the case where a newly created "snooped state" matches an S-PMSI A-D route that is already present. Page 36: 12.1. Inclusive Tree/Selective Tree Identifier Inclusive P-Multicast tree and Selective P-Multicast tree advertisements carry the P-Multicast tree identifier. This document reuses the BGP attribute, called PMSI Tunnel Attribute that is defined in [MVPN]. Only the following Tunnel Types MUST be used when PMSI Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes: + 0 - No tunnel information present + 1 - RSVP-TE P2MP LSP + 2 - LDP P2MP LSP + 6 - Ingress Replication If the protocol architecture is flexible enough to handle other tunnel types, as is stated several times earlier, this should say that the use of other tunnel types is outside the scope of the document, rather than saying that other tunnel types MUST NOT be used. (Actually, the phrase "only the following tunnel types MUST be used ..." is not really comprehensible, I'm just guessing that it means that other tunnel types MUST NOT be used.) Page 38: The Multicast Source field contains the C-S address i.e the address of the multicast source. This may be 0 to indicate a wildcard. If the Multicast Source field contains an IPv4 address, then the value of the Multicast Source Length field is 32. If the Multicast Source field contains an IPv6 address, then the value of the Multicast Source Length field is 128. The Multicast Group field contains the C-G address i.e. the address of the multicast group. This may be 0 to indicate a wildcard. If the Multicast Group field contains an IPv4 address, then the value of the Multicast Group Length field is 32. If the Multicast Group field contains an IPv6 address, then the value of the Multicast Group Length field is 128. The wildcard encoding does not appear to be consistent with that used in MVPN. It is also not clear what the length of a wildcard field is supposed to be, or whether a wildcard is a wildcard only for a particular address family. Please state how to determine the address family of the "originating router's IP address". Usage of Selective Tree auto-discovery routes is described in Section 12. Well, this is section 12! Page 38: A leaf auto-discovery route type specific MCAST-VPLS NLRI consists of the following: +-----------------------------------+ | Route Key (variable) | +-----------------------------------+ | Originating Router's IP Addr | +-----------------------------------+ Usage of Leaf auto-discovery routes is described in sections "Inter- AS Inclusive P-Multicast tree A-D/Binding" and "Optimizing Multicast Distribution via Selective trees". Please state how to determine the address family of the "originating router's IP address". Page 39: 13. Aggregation Methodology A better title would be "Aggregation Considerations", as this section contains some discussion and observations, but does not specify a methodology. Page 41: If the destination MAC address of a VPLS packet received by a PE from a VPLS site is a multicast adddress, a P-Multicast tree SHOULD be used to transport the packet, if possible. If the packet is an IP multicast packet and a Selective tree exists for that multicast stream, the Selective tree SHOULD be used. Else if an Inclusive tree exists for the VPLS, it SHOULD be used. So a transmitter is not required to use the selective tree for a given flow, even if it exists? Is that really the intention? It is not completely clear what the intention is for a packet that has an ethernet multicast DA but is not an IP multicast packet. Would it ever be sent on a selective tree (perhaps one bound to (C-*,C-*))? From ju1738@att.com Tue Apr 5 07:48:54 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6A828C15E for ; Tue, 5 Apr 2011 07:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.587 X-Spam-Level: X-Spam-Status: No, score=-105.587 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLB_Stock6=1.56, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u69PU49u96WS for ; Tue, 5 Apr 2011 07:48:53 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id BFB6928C0DE for ; Tue, 5 Apr 2011 07:48:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1302015033!4096740!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 938 invoked from network); 5 Apr 2011 14:50:33 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2011 14:50:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p35EnXNI017647; Tue, 5 Apr 2011 10:49:33 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p35EnUSv017572; Tue, 5 Apr 2011 10:49:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of new L2VPN WG Charter Date: Tue, 5 Apr 2011 10:50:29 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A92A1@misout7msgusr7e.ugd.att.com> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306A2B4C5@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acvlk6mvByfCCAJ7pEaQouOVm51qugABaMGqAoX2iAkAAG8q8wDS/0awAChxg5A= References: <44F4E579A764584EA9BDFD07D0CA081306A2B4C5@tlvmail1> From: "UTTARO, JAMES (ATTSI)" To: "Daniel Cohn" , "Giles Heron" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:48:54 -0000 I think we should expand E-Tree into a general notion of an arbitrary = topology i.e hierarcacal e-tree etc. Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Monday, April 04, 2011 3:34 PM To: Giles Heron Cc: l2vpn@ietf.org Subject: RE: Draft of new L2VPN WG Charter Hi, I support the addition of e-tree to the charter. In line with similar concerns expressed in the list, I'm not sure = however that E-VPN needs to be explicitly mentioned in the charter, and = if so whether it cannot be addressed by extending the VPLS clause. Regards, Daniel > On 3/18/11 1:21 PM, "Giles Heron" wrote: >=20 > OK - looks like the attachment didn't come through as intended. My > apologies. >=20 > Text inline: >=20 > ---------------- >=20 > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned = Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements = driven > by cloud computing services and data centers as they apply to Layer-2 > VPN services. >=20 > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may = not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG = will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of = existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. >=20 > Layer-2 VPNs comprise the following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that = emulates > a switched Ethernet (V)LAN across an MPLS Packet Switched Network = (PSN). >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >=20 > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. >=20 > 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will > address two specific types of IP-only L2VPN: >=20 > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but = also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. >=20 > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to = VPLS, > but learns IP and MAC address bindings from ARPs and = broadcast/multicast > IP packets. >=20 > 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC = address > bindings in the VPN. E-VPN is primarily targeted to support = large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN = solutions. >=20 > 6. E-Tree =AD a Layer-2 technology defined by the MEF, which provides > connectivity between one or more =B3root=B2 nodes and one or more > =B3leaf=B2 nodes, with the restriction that leaves may only = communicate > with roots (and not with each other). >=20 > L2VPNs will make use of existing IETF specified mechanisms unless = there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. >=20 > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols that will = be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. >=20 > The L2VPN WG will not define new encapsulations, control, or = resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an = L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 = service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. >=20 > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. >=20 > 3. MIBs for Layer-2 VPN solutions. >=20 > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type = of > L2VPN. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. >=20 > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. >=20 > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN = control > plane solutions for achieving fast convergence after failure of an = active > path in the PSN or on the AC side. >=20 > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. >=20 > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for = multicast-optimized > L2VPNs. >=20 > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS.=20 >=20 > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be = coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that = are > chartered to do MPLS TP work. >=20 > Milestones: >=20 > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as = Informational > RFC > Done Submit L2 framework to IESG for publication as = Informational RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and = Inter-AS > VPLS and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to = IESG > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to = IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to = IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2012 Submit E-VPN solution to IESG > Nov 2012 Submit E-VPN MIB/OAM to IESG >=20 > ----------------- >=20 > On 18/03/2011 17:41, "Giles Heron" wrote: >=20 >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >> in-scope. >>=20 >> Please find attached a draft charter for discussion both on this list = and at >> IETF 80 in Prague. >>=20 >> Nabil and Giles >>=20 >>=20 >=20 >=20 >=20 From rahul@juniper.net Tue Apr 5 19:44:25 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5743A69AA for ; Tue, 5 Apr 2011 19:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5QAEEZvyG0F for ; Tue, 5 Apr 2011 19:44:25 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id A8ED93A6849 for ; Tue, 5 Apr 2011 19:44:24 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTZvT73JGoUzimk2QokaKLEVRaLu8AcXs@postini.com; Tue, 05 Apr 2011 19:46:08 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Apr 2011 19:40:23 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p362g5v82627; Tue, 5 Apr 2011 19:42:05 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Tue, 5 Apr 2011 19:42:05 -0700 From: Rahul Aggarwal To: Giles Heron Subject: Re: Draft of new L2VPN WG Charter In-Reply-To: Message-ID: <20110405190933.C34498@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 02:44:25 -0000 Hi L2VPN WG Chairs, Here are a few comments on the proposed charter: - "It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services." To me the intent of this text is that the L2VPN WG will work on addressing data center requirements if they require layer 2 VPN services. The text leaves room for such requirements to be generated by another WG or by L2VPN WG itself. I think this text is a good addition to the charter. - The definition of Ethernet VPN: "5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service, and also supports control plane distribution of MAC addresses and IP to MAC address bindings in the VPN." I think this text is accurate and captures the definition of E-VPN. In short the proposed charter looks quite reasonable to me. rahul On Fri, 18 Mar 2011, Giles Heron wrote: > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > in-scope. > > Please find attached a draft charter for discussion both on this list and at > IETF 80 in Prague. > > Nabil and Giles > > > From jmh@joelhalpern.com Tue Apr 5 21:31:12 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104E43A6856 for ; Tue, 5 Apr 2011 21:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt1byCWbRQ21 for ; Tue, 5 Apr 2011 21:31:10 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 0AF293A6826 for ; Tue, 5 Apr 2011 21:31:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC8604300EF; Tue, 5 Apr 2011 21:32:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-71.clppva.btas.verizon.net [71.161.52.71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 951044300E1; Tue, 5 Apr 2011 21:32:52 -0700 (PDT) Message-ID: <4D9BECF0.40808@joelhalpern.com> Date: Wed, 06 Apr 2011 00:32:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: Draft of new L2VPN WG Charter References: <20110405190933.C34498@sapphire.juniper.net> In-Reply-To: <20110405190933.C34498@sapphire.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 04:31:12 -0000 I think your first proposed item is problematic in at least two regards. 1) We do not generally charter work until we know that it needs to be done. The related activities are still investigating what, if anything, needs to be done. 2) We do not generally charter undefined work. Meeting undefined requirements from undefined places is unusual and difficult. That is a recipe for an unbounded working group, which generally does not come out well for anyone. Yours, Joel On 4/5/2011 10:42 PM, Rahul Aggarwal wrote: > > Hi L2VPN WG Chairs, > > Here are a few comments on the proposed charter: > > - "It will also address requirements driven by cloud computing services > and data centers as they apply to Layer-2 VPN services." > > To me the intent of this text is that the L2VPN WG will work on > addressing data center requirements if they require layer 2 VPN > services. The text leaves room for such requirements to be generated by > another WG or by L2VPN WG itself. I think this text is a good addition > to the charter. > > - The definition of Ethernet VPN: > > "5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC > address bindings in the VPN." > > I think this text is accurate and captures the definition of E-VPN. > > In short the proposed charter looks quite reasonable to me. > > rahul > > > > > > > > > On Fri, 18 Mar 2011, Giles Heron wrote: > >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree >> in-scope. >> >> Please find attached a draft charter for discussion both on this list >> and at >> IETF 80 in Prague. >> >> Nabil and Giles >> >> >> > From jiangyuanlong@huawei.com Tue Apr 5 23:14:17 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B1928B23E for ; Tue, 5 Apr 2011 23:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkpBBo+xtmRM for ; Tue, 5 Apr 2011 23:14:15 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 965CD3A68A7 for ; Tue, 5 Apr 2011 23:14:15 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ7007CUW0H7Y@szxga05-in.huawei.com> for l2vpn@ietf.org; Wed, 06 Apr 2011 14:14:41 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ700CHAW0BTH@szxga05-in.huawei.com> for l2vpn@ietf.org; Wed, 06 Apr 2011 14:14:41 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 06 Apr 2011 14:14:35 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.159]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 06 Apr 2011 14:14:36 +0800 Date: Wed, 06 Apr 2011 06:14:35 +0000 From: Jiangyuanlong Subject: Re: Draft of new L2VPN WG Charter In-reply-to: X-Originating-IP: [10.70.40.77] To: Giles Heron Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B03723740@SZXEML514-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Draft of new L2VPN WG Charter Thread-index: AQHL9CHnRhgRQ9sq/U+S4lWOBf7Kag== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EGdr EboR GShP JZie Jb2A Lm7m LnDs LnKo MIXf NwSP OnVW RL/+ RcTx S8nh UTle UYx4; 2; ZwBpAGwAZQBzAC4AaABlAHIAbwBuAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBsADIAdgBwAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {3CB01626-F89A-4D9B-B100-9B123C4C667C}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 06 Apr 2011 06:14:32 GMT; UgBlADoAIABEAHIAYQBmAHQAIABvAGYAIABuAGUAdwAgAEwAMgBWAFAATgAgAFcARwAgAEMAaABhAHIAdABlAHIA x-cr-puzzleid: {3CB01626-F89A-4D9B-B100-9B123C4C667C} References: Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 06:14:17 -0000 Hello Giles and all, I fully support the inclusion of E-Tree into the re-charter. Just a minor proposal to bullet 6 in what Layer-2 VPNs comprise: 6. E-Tree a Layer-2 technology defined by the MEF,... Should be: 6. E-Tree a Layer-2 service defined by the MEF,... As I am aware, MEF does not define the technology for E-Tree, but defines the E-Tree service, its parameters and applications, The technologies are defined in different responsible SDOs (IEEE specified the Ethernet technology for E-Tree, ITU-T specified the transport technology for E-Tree, IETF is to specify the MPLS technology for E-Tree...) Thanks Yuanlong ------------------------------ Message: 3 Date: Fri, 18 Mar 2011 18:21:29 +0000 From: Giles Heron Subject: Re: Draft of new L2VPN WG Charter To: Message-ID: Content-Type: text/plain; charset="ISO-8859-1" OK - looks like the attachment didn't come through as intended. My apologies. Text inline: ---------------- The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across an MPLS PSN. 4. IP-only L2VPN ? An IP-only service over an MPLS PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service, and also supports control plane distribution of MAC addresses and IP to MAC address bindings in the VPN. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree ? a Layer-2 technology defined by the MEF, which provides connectivity between one or more ?root? nodes and one or more ?leaf? nodes, with the restriction that leaves may only communicate with roots (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multipathing between PEs interconnecting a Layer-2 service using an L2VPN across the MPLS PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RFC Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Jul 2011 Submit IP-only L2VPN solution documents to IESG Jul 2011 Submit OAM solutions for VPWS to IESG Jul 2011 Submit OAM solutions for VPLS to IESG Jul 2011 Submit signaling solution for multicast-optimized VPLS to IESG Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Jul 2011 Submit MIB for VPLS to IESG Jul 2011 Submit MIB for VPWS to IESG Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit MIB for IP-only L2VPN to IESG Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG Mar 2012 Submit Auto-Discovery solution for VPMS to IESG Mar 2012 Submit VPLS service convergence improvement solutions to IESG Mar 2012 Submit VPLS multi-homing solutions to IESG Mar 2012 Submit E-Tree documents to IESG Mar 2012 Submit E-VPN requirements/framework to IESG Jul 2012 Submit E-VPN solution to IESG Nov 2012 Submit E-VPN MIB/OAM to IESG ----------------- On 18/03/2011 17:41, "Giles Heron" wrote: > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > in-scope. > > Please find attached a draft charter for discussion both on this list and at > IETF 80 in Prague. > > Nabil and Giles > > ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 82, Issue 7 ************************************ From prvs=7077e305aa=hshah@ciena.com Wed Apr 6 04:27:37 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E2928C0CE for ; Wed, 6 Apr 2011 04:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0RiTTpwcP8R for ; Wed, 6 Apr 2011 04:27:36 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by core3.amsl.com (Postfix) with ESMTP id 3386C3A6912 for ; Wed, 6 Apr 2011 04:27:36 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p36BOZgP003588; Wed, 6 Apr 2011 07:29:19 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id vgp698bfp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Apr 2011 07:29:19 -0400 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server id 8.1.436.0; Wed, 6 Apr 2011 07:29:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF44D.D31C145D" Subject: RE: Draft of new L2VPN WG Charter Date: Wed, 6 Apr 2011 07:29:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acv0E7eW8x3Ss+gZTmWNNWcFCBTIvAAOTBvy References: <20110405190933.C34498@sapphire.juniper.net> <4D9BECF0.40808@joelhalpern.com> From: "Shah, Himanshu" To: "Joel M. Halpern" , "Rahul Aggarwal" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-06_04:2011-04-06, 2011-04-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104060036 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:27:37 -0000 ------_=_NextPart_001_01CBF44D.D31C145D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agreed, with same concerns. =20 Additionally for the second clause (definition part),=20 allowing active/active construct for VPLS and control plane distribution = of MAC addresses (a concept that is not new) - does not seem to justify new clause. =20 As suggested earlier, perhaps extending the VPLS charter suffice these = extensions.. =20 /himanshu ________________________________ From: l2vpn-bounces@ietf.org on behalf of Joel M. Halpern Sent: Wed 4/6/2011 12:32 AM To: Rahul Aggarwal Cc: l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter I think your first proposed item is problematic in at least two regards. 1) We do not generally charter work until we know that it needs to be done. The related activities are still investigating what, if anything, needs to be done. 2) We do not generally charter undefined work. Meeting undefined requirements from undefined places is unusual and difficult. That is a recipe for an unbounded working group, which generally does not come out well for anyone. Yours, Joel On 4/5/2011 10:42 PM, Rahul Aggarwal wrote: > > Hi L2VPN WG Chairs, > > Here are a few comments on the proposed charter: > > - "It will also address requirements driven by cloud computing = services > and data centers as they apply to Layer-2 VPN services." > > To me the intent of this text is that the L2VPN WG will work on > addressing data center requirements if they require layer 2 VPN > services. The text leaves room for such requirements to be generated = by > another WG or by L2VPN WG itself. I think this text is a good addition > to the charter. > > - The definition of Ethernet VPN: > > "5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC > address bindings in the VPN." > > I think this text is accurate and captures the definition of E-VPN. > > In short the proposed charter looks quite reasonable to me. > > rahul > > > > > > > > > On Fri, 18 Mar 2011, Giles Heron wrote: > >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree >> in-scope. >> >> Please find attached a draft charter for discussion both on this list >> and at >> IETF 80 in Prague. >> >> Nabil and Giles >> >> >> > ------_=_NextPart_001_01CBF44D.D31C145D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Draft of new L2VPN WG Charter=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Agreed, =  with same concerns.
=0A=
 
=0A=
Additionally for the second = clause (definition part),
=0A=
allowing active/active = construct for VPLS and control plane distribution of MAC = addresses
=0A=
(a concept that is not = new)  - does not seem to justify new clause.
=0A=
 
=0A=
As suggested earlier, perhaps = extending the VPLS charter suffice these extensions..
=0A=
 
=0A=
/himanshu
=0A=

=0A=
=0A= From: l2vpn-bounces@ietf.org on = behalf of Joel M. Halpern
Sent: Wed 4/6/2011 12:32 = AM
To: Rahul Aggarwal
Cc: = l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG = Charter

=0A=
=0A=

I think your first proposed item is problematic in at = least two regards.

1) We do not generally charter work until we = know that it needs to be
done.  The related activities are still = investigating what, if anything,
needs to be done.

2) We do = not generally charter undefined work.  Meeting = undefined
requirements from undefined places is unusual and = difficult.  That is a
recipe for an unbounded working group, = which generally does not come out
well for = anyone.

Yours,
Joel

On 4/5/2011 10:42 PM, Rahul = Aggarwal wrote:
>
> Hi L2VPN WG Chairs,
>
> Here = are a few comments on the proposed charter:
>
> - "It will = also address requirements driven by cloud computing services
> and = data centers as they apply to Layer-2 VPN services."
>
> To = me the intent of this text is that the L2VPN WG will work on
> = addressing data center requirements if they require layer 2 VPN
> = services. The text leaves room for such requirements to be generated = by
> another WG or by L2VPN WG itself. I think this text is a good = addition
> to the charter.
>
> - The definition of = Ethernet VPN:
>
> "5. Ethernet VPN (E-VPN) - A Layer-2 = technology that emulates an
> Ethernet (V)LAN across an MPLS PSN. = E-VPN supports load-sharing across
> multiple connections from a = Layer-2 site to an L2VPN service, and also
> supports control = plane distribution of MAC addresses and IP to MAC
> address = bindings in the VPN."
>
> I think this text is accurate and = captures the definition of E-VPN.
>
> In short the proposed = charter looks quite reasonable to me.
>
> = rahul
>
>
>
>
>
>
>
>
= > On Fri, 18 Mar 2011, Giles Heron wrote:
>
>> We plan = to re-charter the L2VPN WG - primarily to bring E-VPN and = E-Tree
>> in-scope.
>>
>> Please find = attached a draft charter for discussion both on this list
>> = and at
>> IETF 80 in Prague.
>>
>> Nabil and = Giles
>>
>>
>>
>

------_=_NextPart_001_01CBF44D.D31C145D-- From aldrin.isaac@gmail.com Wed Apr 6 05:37:30 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9D73A6938 for ; Wed, 6 Apr 2011 05:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+83vTmEH4Vf for ; Wed, 6 Apr 2011 05:37:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 4F5D328C0DD for ; Wed, 6 Apr 2011 05:37:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so1280112vxg.31 for ; Wed, 06 Apr 2011 05:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Y0E10KbAXkdjBOncWybqiHqwGsOsCwS3SmTftEPU7n8=; b=F5DUOJT6lykEN1x6xGR10MRdNdyE5AgO4wZcwX8JlgsZ2HW6BkWsiBImyGzLFgbcmh Not7bTuGqml19CuO24F8YMAYGY7Ahwh7WJwwOv5L/kHoHTAIof+spWs1ETo675bfpICb WspNdMujZpjlzDrw5VZba2KRI9Z4af0ugTXDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=q8P2VbEID48Tm6uHGGkWB+v0Pw9s/2ufFRHM+djVPdXhlNfeU1EmRo2r1JddN4LQzR Xl9qWcoMzHyuki+PCO5mR5i1Wqy2Vi8SaufCY0cYnkkF1xThFPdIp44wy+j8QJ8A63g2 41YjZGk/oGQDQSJLA5JVvt1IqMkn00VdZnXXY= MIME-Version: 1.0 Received: by 10.52.171.2 with SMTP id aq2mr1285233vdc.214.1302093552920; Wed, 06 Apr 2011 05:39:12 -0700 (PDT) Received: by 10.52.110.106 with HTTP; Wed, 6 Apr 2011 05:39:12 -0700 (PDT) In-Reply-To: <4D9BECF0.40808@joelhalpern.com> References: <20110405190933.C34498@sapphire.juniper.net> <4D9BECF0.40808@joelhalpern.com> Date: Wed, 6 Apr 2011 08:39:12 -0400 Message-ID: Subject: Re: Draft of new L2VPN WG Charter From: Aldrin Isaac To: "Joel M. Halpern" , Rahul Aggarwal , l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:37:30 -0000 Hi Joel, Is draft-sajassi-raggarwa-l2vpn-evpn-req what you are looking for? Regarding support of L2VPN services within and between data centers by the charter, note that many providers operate both WAN and data center networks. They increasingly have a need to blend the two into a larger coherent system edge-to-edge. Best. -- aldrin On 4/6/11, Joel M. Halpern wrote: > I think your first proposed item is problematic in at least two regards. > > 1) We do not generally charter work until we know that it needs to be > done. The related activities are still investigating what, if anything, > needs to be done. > > 2) We do not generally charter undefined work. Meeting undefined > requirements from undefined places is unusual and difficult. That is a > recipe for an unbounded working group, which generally does not come out > well for anyone. > > Yours, > Joel > > On 4/5/2011 10:42 PM, Rahul Aggarwal wrote: >> >> Hi L2VPN WG Chairs, >> >> Here are a few comments on the proposed charter: >> >> - "It will also address requirements driven by cloud computing services >> and data centers as they apply to Layer-2 VPN services." >> >> To me the intent of this text is that the L2VPN WG will work on >> addressing data center requirements if they require layer 2 VPN >> services. The text leaves room for such requirements to be generated by >> another WG or by L2VPN WG itself. I think this text is a good addition >> to the charter. >> >> - The definition of Ethernet VPN: >> >> "5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across >> multiple connections from a Layer-2 site to an L2VPN service, and also >> supports control plane distribution of MAC addresses and IP to MAC >> address bindings in the VPN." >> >> I think this text is accurate and captures the definition of E-VPN. >> >> In short the proposed charter looks quite reasonable to me. >> >> rahul >> >> >> >> >> >> >> >> >> On Fri, 18 Mar 2011, Giles Heron wrote: >> >>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree >>> in-scope. >>> >>> Please find attached a draft charter for discussion both on this list >>> and at >>> IETF 80 in Prague. >>> >>> Nabil and Giles >>> >>> >>> >> > -- Sent from my mobile device From jmh@joelhalpern.com Wed Apr 6 07:00:10 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBC628C0EF for ; Wed, 6 Apr 2011 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM4lvo3dlbaR for ; Wed, 6 Apr 2011 07:00:04 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 67AF228C0EA for ; Wed, 6 Apr 2011 07:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8EC174300AC; Wed, 6 Apr 2011 07:01:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-71.clppva.btas.verizon.net [71.161.52.71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B7E3943002D; Wed, 6 Apr 2011 07:01:47 -0700 (PDT) Message-ID: <4D9C7248.7070705@joelhalpern.com> Date: Wed, 06 Apr 2011 10:01:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Aldrin Isaac Subject: Re: Draft of new L2VPN WG Charter References: <20110405190933.C34498@sapphire.juniper.net> <4D9BECF0.40808@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Rahul Aggarwal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:00:11 -0000 That is a very interesting draft. If the references to virtualization and MAC scaling were split off (as those are the purview of the ARMD working group and almost incidental to the rest of the draft), the draft would be a very good start on a document for a working group milestone of evaluating the requirements. If the scope of the requirements space were spelled out in the charter, then I would be quite happy with such a milestone. I would however, defer any milestone for solving the problem, as WGs that put both in have a tendency to get the cart before the horse (I have just had a bit of that with the KARP WG, where I and my co-chair and ADs made exactly that error.) Yours, Joel On 4/6/2011 8:39 AM, Aldrin Isaac wrote: > Hi Joel, > > Is draft-sajassi-raggarwa-l2vpn-evpn-req what you are looking for? > > Regarding support of L2VPN services within and between data centers by > the charter, note that many providers operate both WAN and data center > networks. They increasingly have a need to blend the two into a > larger coherent system edge-to-edge. > > Best. -- aldrin > > On 4/6/11, Joel M. Halpern wrote: >> I think your first proposed item is problematic in at least two regards. >> >> 1) We do not generally charter work until we know that it needs to be >> done. The related activities are still investigating what, if anything, >> needs to be done. >> >> 2) We do not generally charter undefined work. Meeting undefined >> requirements from undefined places is unusual and difficult. That is a >> recipe for an unbounded working group, which generally does not come out >> well for anyone. >> >> Yours, >> Joel >> >> On 4/5/2011 10:42 PM, Rahul Aggarwal wrote: >>> >>> Hi L2VPN WG Chairs, >>> >>> Here are a few comments on the proposed charter: >>> >>> - "It will also address requirements driven by cloud computing services >>> and data centers as they apply to Layer-2 VPN services." >>> >>> To me the intent of this text is that the L2VPN WG will work on >>> addressing data center requirements if they require layer 2 VPN >>> services. The text leaves room for such requirements to be generated by >>> another WG or by L2VPN WG itself. I think this text is a good addition >>> to the charter. >>> >>> - The definition of Ethernet VPN: >>> >>> "5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across >>> multiple connections from a Layer-2 site to an L2VPN service, and also >>> supports control plane distribution of MAC addresses and IP to MAC >>> address bindings in the VPN." >>> >>> I think this text is accurate and captures the definition of E-VPN. >>> >>> In short the proposed charter looks quite reasonable to me. >>> >>> rahul >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, 18 Mar 2011, Giles Heron wrote: >>> >>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree >>>> in-scope. >>>> >>>> Please find attached a draft charter for discussion both on this list >>>> and at >>>> IETF 80 in Prague. >>>> >>>> Nabil and Giles >>>> >>>> >>>> >>> >> > From xuxh@huawei.com Thu Apr 7 21:13:28 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318EF3A6A43 for ; Thu, 7 Apr 2011 21:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJuWiG0Mie-p for ; Thu, 7 Apr 2011 21:13:27 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2C4E53A6784 for ; Thu, 7 Apr 2011 21:13:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJB00397FNKXG@szxga04-in.huawei.com> for l2vpn@ietf.org; Fri, 08 Apr 2011 12:11:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJB00JYRFNKIT@szxga04-in.huawei.com> for l2vpn@ietf.org; Fri, 08 Apr 2011 12:11:44 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJB009FDFNKZ7@szxml04-in.huawei.com> for l2vpn@ietf.org; Fri, 08 Apr 2011 12:11:44 +0800 (CST) Date: Fri, 08 Apr 2011 12:20:05 +0800 From: Xu Xiaohu Subject: About loop avoidance when using BGP best external To: raszuk@cisco.com Message-id: <002901cbf5a4$3cf3e690$60626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acv1pDybf4GWxtrWRK2CBTxtUvJ4Xw== Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 04:13:28 -0000 -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of=20 > Robert Raszuk > Sent: Sunday, April 03, 2011 2:26 AM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does=20 > PE revert back to standard label? >=20 > Hi Jakob, >=20 > > I think the draft needs to state that a received native IP packet is = > > NEVER sent using the repair label. Specifically, if the IP path to=20 > > the CE is broken, a packet received as a native IP packet shoul be=20 > > sent to the PE next hop using the regular label, not the repair=20 > > label. The repair label should only be used for packets received=20 > > from MPLS. >=20 > The draft already states this: >=20 > In a BGP free core, where traffic is tunneled between edge routers > and edge routers assign labels to prefixes, BGP speakers advertise > reachability information about prefixes and associate a local = label > with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]. >=20 > But thinking further I do not see perhaps anything wrong on attaching=20 > this attribute to unicast IPv4 and IPv6 AFIs where ASBRs and network=20 > between them are MPLS enabled. >=20 > In fact if we would explicitly permit this in=20 > draft-bashandy-idr-bgp-repair-label it will automatically address the=20 > problem as described in draft-xu-idr-best-external-loop-avoidance. Hi Robert, Sorry that I just notice this email mentioning my draft (draft-xu-idr-best-external-loop-avoidance). IMO, the repair-label draft (draft-bashandy-idr-bgp-repair-label) and my draft have many differences as listed below (here I just refer the L3VPN = CE multi-homing scenario): 1. Different target scenarios: The repair-label draft targets the scenario where the best route for the local CE site on each multi-homing PE router is pointed to the CE = router, while my draft targets the scenario of best external. =20 2. Different achievements: The repair-label draft only solves the problem of transient loop in case = the CE router is down (anyway, the CE destination is unreachable at this = time). While my draft not only solves the transient loop problem, but also = speeds up the convergence in case the best external route is still available.=20 3. Different approaches: The repair-label draft requires some changes to the BGP protocol while = my draft doesn=A1=AFt require any change to the BGP protocol. =A1=A1=A1=A1 Best wishes, Xiaohu =A1=A1=A1=A1 > Thx, > R. >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Apr 7 22:48:07 2011 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD4C3A6892 for ; Thu, 7 Apr 2011 22:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xD0nmDm9BF4 for ; Thu, 7 Apr 2011 22:48:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 328A63A69F8 for ; Thu, 7 Apr 2011 22:48:02 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p385n7fE025569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2011 00:49:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 8 Apr 2011 01:49:06 -0400 From: Jakob Heitz To: Xu Xiaohu , "raszuk@cisco.com" Date: Fri, 8 Apr 2011 01:49:06 -0400 Subject: RE: About loop avoidance when using BGP best external Thread-Topic: About loop avoidance when using BGP best external Thread-Index: Acv1pDybf4GWxtrWRK2CBTxtUvJ4XwAC+iew Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F7BBF70@EUSAACMS0701.eamcs.ericsson.se> References: <002901cbf5a4$3cf3e690$60626e0a@china.huawei.com> In-Reply-To: <002901cbf5a4$3cf3e690$60626e0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 05:48:07 -0000 Hi Xiaohu, Your draft indeed requires no protocol change. OTOH, the Bashandy draft covers the active-active case where either link to the CE can fail and be backed up by the other. -- Jakob Heitz. =20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Xu Xiaohu > Sent: Thursday, April 07, 2011 9:20 PM > To: raszuk@cisco.com > Cc: l2vpn@ietf.org > Subject: About loop avoidance when using BGP best external >=20 > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of=20 > > Robert Raszuk > > Sent: Sunday, April 03, 2011 2:26 AM > > To: Jakob Heitz > > Cc: idr > > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01:=20 > when does=20 > > PE revert back to standard label? > >=20 > > Hi Jakob, > >=20 > > > I think the draft needs to state that a received native=20 > IP packet is=20 > > > NEVER sent using the repair label. Specifically, if the=20 > IP path to=20 > > > the CE is broken, a packet received as a native IP packet=20 > shoul be=20 > > > sent to the PE next hop using the regular label, not the repair=20 > > > label. The repair label should only be used for packets received=20 > > > from MPLS. > >=20 > > The draft already states this: > >=20 > > In a BGP free core, where traffic is tunneled between=20 > edge routers > > and edge routers assign labels to prefixes, BGP=20 > speakers advertise > > reachability information about prefixes and associate a=20 > local label > > with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]. > >=20 > > But thinking further I do not see perhaps anything wrong on=20 > attaching=20 > > this attribute to unicast IPv4 and IPv6 AFIs where ASBRs=20 > and network=20 > > between them are MPLS enabled. > >=20 > > In fact if we would explicitly permit this in=20 > > draft-bashandy-idr-bgp-repair-label it will automatically=20 > address the=20 > > problem as described in draft-xu-idr-best-external-loop-avoidance. >=20 > Hi Robert, >=20 > Sorry that I just notice this email mentioning my draft > (draft-xu-idr-best-external-loop-avoidance). >=20 > IMO, the repair-label draft=20 > (draft-bashandy-idr-bgp-repair-label) and my > draft have many differences as listed below (here I just=20 > refer the L3VPN CE > multi-homing scenario): >=20 > 1. Different target scenarios: > The repair-label draft targets the scenario where the best=20 > route for the > local CE site on each multi-homing PE router is pointed to=20 > the CE router, > while my draft targets the scenario of best external. =20 >=20 > 2. Different achievements: > The repair-label draft only solves the problem of transient=20 > loop in case the > CE router is down (anyway, the CE destination is unreachable=20 > at this time). > While my draft not only solves the transient loop problem,=20 > but also speeds > up the convergence in case the best external route is still=20 > available.=20 >=20 > 3. Different approaches: > The repair-label draft requires some changes to the BGP=20 > protocol while my > draft doesn=1B$B!G=1B(Bt require any change to the BGP protocol. > =1B$B!!!!=1B(B > Best wishes, > Xiaohu > =1B$B!!!!=1B(B > > Thx, > > R. > >=20 > >=20 > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 > = From yakov@juniper.net Tue Apr 12 14:10:23 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4CE1E0906 for ; Tue, 12 Apr 2011 14:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4zGVSre4BWv for ; Tue, 12 Apr 2011 14:10:23 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfc.amsl.com (Postfix) with ESMTP id 493C5E0688 for ; Tue, 12 Apr 2011 14:10:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTaS/vSMziILSIUmwHaRHJESsJVGw0kjG@postini.com; Tue, 12 Apr 2011 14:10:23 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Apr 2011 14:06:14 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p3CL88v48519; Tue, 12 Apr 2011 14:08:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201104122108.p3CL88v48519@magenta.juniper.net> To: Subject: Re: Draft of new L2VPN WG Charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55747.1302642488.1@juniper.net> Date: Tue, 12 Apr 2011 14:08:08 -0700 From: Yakov Rekhter Cc: yakov@juniper.net X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:10:23 -0000 Nabil and Giles, > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > in-scope. > > Please find attached a draft charter for discussion both on this list and at > IETF 80 in Prague. I support this charter. Yakov. From lizhong.jin@zte.com.cn Thu Apr 14 02:23:35 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8680E066A for ; Thu, 14 Apr 2011 02:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhkiD8G4Am6p for ; Thu, 14 Apr 2011 02:23:35 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id A2E1AE0664 for ; Thu, 14 Apr 2011 02:23:34 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510577109098; Thu, 14 Apr 2011 17:19:55 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4886.683968793; Thu, 14 Apr 2011 17:21:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3E9L4eO028772; Thu, 14 Apr 2011 17:21:04 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: giles.heron@gmail.com Subject: RE: Draft of new L2VPN WG Charter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Thu, 14 Apr 2011 17:21:05 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-14 17:21:04, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-14 17:21:04, Serialize complete at 2011-04-14 17:21:04, S/MIME Sign failed at 2011-04-14 17:21:04: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-14 17:21:06, Serialize complete at 2011-04-14 17:21:06 Content-Type: multipart/alternative; boundary="=_alternative 00335E1E48257872_=" X-MAIL: mse02.zte.com.cn p3E9L4eO028772 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:23:36 -0000 This is a multipart message in MIME format. --=_alternative 00335E1E48257872_= Content-Type: text/plain; charset="US-ASCII" Hi Giles, Nabil, The re-charter looks fine for me. Lizhong > Message: 1 > Date: Thu, 31 Mar 2011 07:38:39 +1100 > From: Raymond Key > Subject: RE: Draft of new L2VPN WG Charter > To: , > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > I support the re-charter. > Raymond Key > > > Date: Fri, 18 Mar 2011 17:41:08 +0000 > > Subject: Draft of new L2VPN WG Charter > > From: giles.heron@gmail.com > > To: l2vpn@ietf.org > > > > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > > in-scope. > > > > Please find attached a draft charter for discussion both on this list and at > > IETF 80 in Prague. > > > > Nabil and Giles > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00335E1E48257872_= Content-Type: text/html; charset="US-ASCII"
Hi Giles, Nabil,
The re-charter looks fine for me.

Lizhong


> Message: 1
> Date: Thu, 31 Mar 2011 07:38:39 +1100
> From: Raymond Key <raymond.key@ieee.org>
> Subject: RE: Draft of new L2VPN WG Charter
> To: <giles.heron@gmail.com>, <l2vpn@ietf.org>
> Message-ID: <SNT123-W52757872E60FD76BB6F9C1F4BC0@phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> I support the re-charter.
> Raymond Key
>  
> > Date: Fri, 18 Mar 2011 17:41:08 +0000
> > Subject: Draft of new L2VPN WG Charter
> > From: giles.heron@gmail.com
> > To: l2vpn@ietf.org
> >
> > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree
> > in-scope.
> >
> > Please find attached a draft charter for discussion both on this list and at
> > IETF 80 in Prague.
> >
> > Nabil and Giles
> >
> >
>                      
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.htm>
>
> ------------------------------
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00335E1E48257872_=-- From wim.henderickx@alcatel-lucent.com Thu Apr 14 02:27:09 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9222AE0664 for ; Thu, 14 Apr 2011 02:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL7r7K31PHDs for ; Thu, 14 Apr 2011 02:27:08 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfc.amsl.com (Postfix) with ESMTP id 68289E0669 for ; Thu, 14 Apr 2011 02:27:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3E9Pxcx005874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Apr 2011 11:27:05 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 14 Apr 2011 11:26:57 +0200 From: "Henderickx, Wim (Wim)" To: "giles.heron@gmail.com" Date: Thu, 14 Apr 2011 11:26:55 +0200 Subject: RE: Draft of new L2VPN WG Charter Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: Acv6ha1kJKz8DOBeSyCeDYaiQ+aVywAAEYaQ Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6718445F8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6718445F8CFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:27:09 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6718445F8CFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Giles, I believe the charter looks good. Both E-TREE and E-VPN are very important = technologies we need to support in L2VPN. Cheers, Wim > Message: 1 > Date: Thu, 31 Mar 2011 07:38:39 +1100 > From: Raymond Key > Subject: RE: Draft of new L2VPN WG Charter > To: , > Message-ID: > Content-Type: text/plain; charset=3D"iso-8859-1" > > > I support the re-charter. > Raymond Key > > > Date: Fri, 18 Mar 2011 17:41:08 +0000 > > Subject: Draft of new L2VPN WG Charter > > From: giles.heron@gmail.com > > To: l2vpn@ietf.org > > > > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tre= e > > in-scope. > > > > Please find attached a draft charter for discussion both on this list a= nd at > > IETF 80 in Prague. > > > > Nabil and Giles > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_14C7F4F06DB5814AB0DE29716C4F6D6718445F8CFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Giles= ,

 <= /span>

I believe the charter looks goo= d. Both E-TREE and E-VPN are very important technologies we need to support= in L2VPN.

&nbs= p;

Cheers,

Wim

> Message: 1
= > Date: Thu, 31 Mar 2011 07:38:39 +1100
> From: Raymo= nd Key <raymond.key@ieee.org>
> Subject: RE: Draft of = new L2VPN WG Charter
> To: <giles.heron@gmail.com>, &l= t;l2vpn@ietf.org>
> Message-ID: <SNT123-W52757872E60FD= 76BB6F9C1F4BC0@phx.gbl>
> Content-Type: text/plain; chars= et=3D"iso-8859-1"
>
>
> I support the re-charter.
> Raymond Key
&g= t;  
> > Date: Fri, 18 Mar 2011 17:41:08 +0000<= br>> > Subject: Draft of new L2VPN WG Charter
> &g= t; From: giles.heron@gmail.com
> > To: l2vpn@ietf.org
> >
> > We plan to re-charter the L2VPN W= G - primarily to bring E-VPN and E-Tree
> > in-scope.
> >
> > Please find attached a draft char= ter for discussion both on this list and at
> > IETF 80 i= n Prague.
> >
> > Nabil and Giles=
> >
> >
>     &n= bsp;                
&= gt; -------------- next part --------------
> An HTML attach= ment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.h= tm>
>
> ------------------------------
> 

 
=
--------------------------------------------------------
ZTE Information Security Notice: The informatio= n contained in this mail is solely prope= rty of the sender's organization. This mail&n= bsp;communication is confidential. Recipients named&nbs= p;above are obligated to maintain secrecy and=  are not permitted to disclose the conte= nts of this communication to others.
This email and any files transmitted =
with it are confidential and intended solely&=
nbsp;for the use of the individual or en=
tity to whom they are addressed. If you&=
nbsp;have received this email in error please=
 notify the originator of the message. A=
ny views expressed in this message are t=
hose of the individual sender.
Thi=
s message has been scanned for viruses a=
nd Spam by ZTE Anti-Spam system.
<= /div>= --_000_14C7F4F06DB5814AB0DE29716C4F6D6718445F8CFRMRSSXCHMBSB1d_-- From giles.heron@gmail.com Thu Apr 14 05:12:05 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13D1FE08AD for ; Thu, 14 Apr 2011 05:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXYafxFDpiSp for ; Thu, 14 Apr 2011 05:12:03 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id 97548E08A6 for ; Thu, 14 Apr 2011 05:12:03 -0700 (PDT) Received: by wwk4 with SMTP id 4so5924412wwk.1 for ; Thu, 14 Apr 2011 05:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=LGssyznCbhbMhV9xME7Edcs1lGE2m4SVXZA5fGXiacQ=; b=T49G709rn4YDUDHgAwLi+BNu+1tRfPbg3LWUkHbnsTP+OZfnqiZV4xCLnM1rCRC0MZ LcBM1/QDzmWpJt79v2MnVwxVsCl162GOsslTsDVHGBgT4hUsQi0XFj1dSee3m5EpSecw Z7OSqN8ThGHrFpFAn5Fh8rACLxceWKBinRnis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=YppK5WksuF4ENiIxD8PvjZGPnyaGpEDN2JrtnYW4f8aLBzsQbHHej+azYZlKtjoiXF OBcflIiXyNSrjCLdEeitu/8dKwkYjKfDJ9y6bht6grJT7niflydEwoSSgu3nqzHvECIB WbuiT2OT+ZPqSqCc13WEVRIU7+hSnHksKlvtc= Received: by 10.216.152.193 with SMTP id d43mr727707wek.53.1302783122955; Thu, 14 Apr 2011 05:12:02 -0700 (PDT) Received: from [144.254.149.199] (dhcp-144-254-149-199.cisco.com [144.254.149.199]) by mx.google.com with ESMTPS id f30sm772773wef.31.2011.04.14.05.12.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2011 05:12:01 -0700 (PDT) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 14 Apr 2011 13:12:50 +0100 Subject: Re: Draft of new L2VPN WG Charter From: Giles Heron To: Jiangyuanlong Message-ID: Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AQHL9CHnRhgRQ9sq/U+S4lWOBf7KapRdUkho In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B03723740@SZXEML514-MBS.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:12:05 -0000 Good catch Yuanlong, thanks! Giles On 06/04/2011 07:14, "Jiangyuanlong" wrote: > Hello Giles and all, > > I fully support the inclusion of E-Tree into the re-charter. > > Just a minor proposal to bullet 6 in what Layer-2 VPNs comprise: > > 6. E-Tree a Layer-2 technology defined by the MEF,... > Should be: > 6. E-Tree a Layer-2 service defined by the MEF,... > > As I am aware, MEF does not define the technology for E-Tree, > but defines the E-Tree service, its parameters and applications, > The technologies are defined in different responsible SDOs (IEEE > specified the Ethernet technology for E-Tree, ITU-T specified > the transport technology for E-Tree, IETF is to specify the MPLS > technology for E-Tree...) > > Thanks > Yuanlong > > > ------------------------------ > > Message: 3 > Date: Fri, 18 Mar 2011 18:21:29 +0000 > From: Giles Heron > Subject: Re: Draft of new L2VPN WG Charter > To: > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > OK - looks like the attachment didn't come through as intended. My > apologies. > > Text inline: > > ---------------- > > The L2VPN working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned Layer-2 > Virtual Private Networks (L2VPNs). It will also address requirements driven > by cloud computing services and data centers as they apply to Layer-2 > VPN services. > > Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as > defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a > "native" service over a PSN that is adequately faithful to, but may not > be entirely indistinguishable from the native service itself. Further, > following in the "edge-to-edge" nature of the service, the L2VPN WG will > not define any mechanisms which exert control over the underlying PSN. > When necessary it may, however, recommend or require the use of existing > PSN QoS and path control mechanisms between the PEs which provide the > L2VPN connectivity. > > Layer-2 VPNs comprise the following: > > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates > a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN). > > 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that > provides point-to-point connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. > > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that > provides point-to-multipoint connectivity for a variety of link > layers across an MPLS PSN. > > 4. IP-only L2VPN ? An IP-only service over an MPLS PSN. The WG will > address two specific types of IP-only L2VPN: > > a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also > supports heterogenous Attachment Circuits at either end of a single > point-to-point service. > > b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, > but learns IP and MAC address bindings from ARPs and broadcast/multicast > IP packets. > > 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across > multiple connections from a Layer-2 site to an L2VPN service, and also > supports control plane distribution of MAC addresses and IP to MAC address > bindings in the VPN. E-VPN is primarily targeted to support large-scale > L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. > > 6. E-Tree ? a Layer-2 technology defined by the MEF, which provides > connectivity between one or more ?root? nodes and one or more > ?leaf? nodes, with the restriction that leaves may only communicate > with roots (and not with each other). > > L2VPNs will make use of existing IETF specified mechanisms unless there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. > > The L2VPN WG is responsible for specification of the discovery and > membership of PEs participating in a Layer-2 VPN as well as the > membership of CE devices for a specific instance of an L2VPN. > > The L2VPN WG will provide extensions of existing protocols that will be > discussed in protocol-specific WGs. In particular, the L2VPN WG > may define extensions to pseudowire management mechanisms for VPLS. > Those extensions will be reviewed by the PWE3 WG to ensure they are > aligned with the overall design/architecture of PWE3. > > The L2VPN WG will not define new encapsulations, control, or resiliency > mechanisms specifically related to pseudowires. Furthermore, when the > L2VPN solution is based on PWs, the L2VPN WG will not define protocol > inter-working between an L2VPN and native service Layer-2 OAM or > resiliency mechanisms. The L2VPN WG may define how to operate native > service-layer control, OAM or resiliency mechanisms on top of an L2VPN. > In addition, it may define native data plane and/or control plane > interworking between an L2VPN and an associated native Layer-2 service. > > The L2VPN WG scope includes the following: > > 1. Discovery of PEs participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN > service. > > 2. Signaling of information related to the discovery and membership of > PEs within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN, when the L2VPN operates over > PWs. Once those requirements have been reviewed by the L2VPN WG, they > should be provided to the PWE3 WG to derive solutions. > > 3. MIBs for Layer-2 VPN solutions. > > 4. Specification of requirements, framework and solutions that > facilitate Operations Administration and Management (OAM) of any type of > L2VPN. > > 5. Mechanisms to permit optimization of multicast data traffic within > an L2VPN. > > 6. If transport does not involve PWs, mechanisms that support > load-balancing/multipathing between PEs interconnecting a Layer-2 > service using an L2VPN across the MPLS PSN. > > 7. requirements for the multi-homing of CEs to several VPLS or > E-VPN PEs, inclusive of active/backup and active/active (load-sharing) > configurations. Based on these requirements define VPLS or E-VPN control > plane solutions for achieving fast convergence after failure of an active > path in the PSN or on the AC side. > > 8. Enhancements to increase the scalability of the Control Plane and > Data Plane of L2VPN PE nodes, and of core nodes that provide transport > services for L2VPN. > > 9. Requirements and solutions for Auto-Discovery and Signaling of > Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized > L2VPNs. > > 10. Requirements and solutions for supporting "E-Tree" services using > VPLS. > > 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS > Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated > between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are > chartered to do MPLS TP work. > > Milestones: > > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit L2 requirements to IESG for publication as Informational > RFC > Done Submit L2 framework to IESG for publication as Informational RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS > VPLS and VPWS Layer-2 VPNs > Jul 2011 Submit IP-only L2VPN solution documents to IESG > Jul 2011 Submit OAM solutions for VPWS to IESG > Jul 2011 Submit OAM solutions for VPLS to IESG > Jul 2011 Submit signaling solution for multicast-optimized VPLS to IESG > Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG > Jul 2011 Submit MIB for VPLS to IESG > Jul 2011 Submit MIB for VPWS to IESG > Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG > Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG > Mar 2012 Submit MIB for IP-only L2VPN to IESG > Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG > Mar 2012 Submit Auto-Discovery solution for VPMS to IESG > Mar 2012 Submit VPLS service convergence improvement solutions to IESG > Mar 2012 Submit VPLS multi-homing solutions to IESG > Mar 2012 Submit E-Tree documents to IESG > Mar 2012 Submit E-VPN requirements/framework to IESG > Jul 2012 Submit E-VPN solution to IESG > Nov 2012 Submit E-VPN MIB/OAM to IESG > > ----------------- > > On 18/03/2011 17:41, "Giles Heron" wrote: > >> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree >> in-scope. >> >> Please find attached a draft charter for discussion both on this list and at >> IETF 80 in Prague. >> >> Nabil and Giles >> >> > > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 82, Issue 7 > ************************************ From yuqun.cao@gmail.com Fri Apr 15 07:25:09 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A3294E07FF for ; Fri, 15 Apr 2011 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYBQVPCInGLW for ; Fri, 15 Apr 2011 07:25:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2CB21E066A for ; Fri, 15 Apr 2011 07:25:06 -0700 (PDT) Received: by pzk30 with SMTP id 30so1233548pzk.31 for ; Fri, 15 Apr 2011 07:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:x-mimeole; bh=C5UA96bd34FTIGbm/LywhSuAzkhAs0amRxg/u+g32KM=; b=KqLuc1K/8tinl/8vb0kIW283e7ikyy+a0PM9FXHPo5rK+i911cDy+HWDt1szBRiY/k N/to8NLJ/CUkn7p8vW9b+n998/HbzaqakRAhcR5wQqPL69Ea9tmzvN0IDPLWsAJAOM82 Ha254/LBhQn5MnO1mjqocvT3px2LASGOF5bs0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:x-mimeole; b=dap6+kc7Huy4szw3vCc0Pwsu7gSOdoeUMZ1VZovPGXHdN/FSRd06IbxrL/UWEEAASk cxO1onaB6E1Z7NlZxwHjY/Q7pWOQZXhYgOYrb9iz1GEGgSeiGM0ALMzbkYEMzW43EJUe gTa6pQDV1qhJWeHJ4Yek2GDyU/wN6cLRfk2xU= Received: by 10.68.43.4 with SMTP id s4mr2086935pbl.61.1302877505567; Fri, 15 Apr 2011 07:25:05 -0700 (PDT) Received: from vvcom ([175.42.34.10]) by mx.google.com with ESMTPS id t6sm467797pbc.21.2011.04.15.07.25.01 (version=SSLv3 cipher=OTHER); Fri, 15 Apr 2011 07:25:04 -0700 (PDT) From: "Sam Cao" To: Subject: I-D:Extension to BGP-VPLS for E-Tree Date: Fri, 15 Apr 2011 22:25:09 +0800 Message-ID: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01CBFBBB.FDF8D3B0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acv7eOxjLA5yV4aKQQ6I0T3lK4AKpw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: yortion@hotmail.com, chenxb@ruijie.com.cn X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:25:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01CBFBBB.FDF8D3B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi L2VPN working group, I have just updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf.org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service using BGP for auto-discovery and signaling [RFC4761], and I believe that these solution concepts can be applied to both LDP-VPLS and BGP-VPLS, but the implementation may be a little different. Grateful if you could review and collaborate on the mailing list, or direct to the author. Looking forward to your feedback. Many thanks to Raymond for his comments on initial version. And thank you in advance for your time, Regards, Yuqun(Sam) Cao ------=_NextPart_000_0000_01CBFBBB.FDF8D3B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi L2VPN working = group,

 

I have just updated "Extension to BGP-VPLS = for E-Tree" (htt= p://www.ietf.org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an approach to support Metro Ethernet Forum (MEF) = Ethernet Tree (E-Tree) in Virtual Private LAN Service using BGP for = auto-discovery and signaling [RFC4761], and I believe that these solution concepts can be = applied to both LDP-VPLS and BGP-VPLS, but the implementation may be a little different.

 

Grateful if you could review and collaborate on = the mailing list, or direct to the author. Looking forward to your = feedback.

 

Many thanks to Raymond for = his comments on initial version. And thank you in advance for = your time,

 

Regards,

 

Yuqun(Sam) Cao

------=_NextPart_000_0000_01CBFBBB.FDF8D3B0-- From simon.delord@gmail.com Sat Apr 16 15:52:54 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 64DB2E073A for ; Sat, 16 Apr 2011 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2yYjnSD73cr for ; Sat, 16 Apr 2011 15:52:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3C4BEE0674 for ; Sat, 16 Apr 2011 15:52:53 -0700 (PDT) Received: by fxm15 with SMTP id 15so2800287fxm.31 for ; Sat, 16 Apr 2011 15:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bQKXEP6qL2fGHSpaWArXVASoITQJWarvF+VdjH0Hq9E=; b=VPwsfiFI+RU2g1IpqDFMpe26uyC0LLyOfIpQ/jUQk5iUuGEcQ5paBmnjXWg38wQ37s ZbYOBMmdQDvB+jv9l0Bw6C49yxvsuuE/P3iVxzUqxDEaI+7hQlISotUgh1PD1/0ZLIbZ CTF+2VR3qwLwD3S6L6FnRJeWIxl4Da0PmZJug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dfUAHye2gFsaPH6gQU1/ol/AeVGqmHWWe8aZrFCD/ZnOV4rpGPGJwKAXa13U/9TCio SZbKdIzK9Rjtz2Mp3zktBOK+olkO/aFL2i92usTaexRZggYeXTNVErXadVHI6zfSZ+t4 WpyAtx1+dRbKSdzpReZpweH9uOKqzZXeqklEw= MIME-Version: 1.0 Received: by 10.223.95.138 with SMTP id d10mr3509864fan.21.1302994370932; Sat, 16 Apr 2011 15:52:50 -0700 (PDT) Received: by 10.223.113.15 with HTTP; Sat, 16 Apr 2011 15:52:50 -0700 (PDT) In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6718445F8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6718445F8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Sun, 17 Apr 2011 06:52:50 +0800 Message-ID: Subject: Re: Draft of new L2VPN WG Charter From: Simon Delord To: l2vpn@ietf.org Content-Type: multipart/alternative; boundary=00151747b6fa9fafdd04a11104e4 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 22:52:54 -0000 --00151747b6fa9fafdd04a11104e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support the re-charter. Simon 2011/4/14 Henderickx, Wim (Wim) > *Giles,* > > * * > > *I believe the charter looks good. Both E-TREE and E-VPN are very > important technologies we need to support in L2VPN.* > > * * > > *Cheers,* > > *Wim* > > > > Message: 1 > > Date: Thu, 31 Mar 2011 07:38:39 +1100 > > From: Raymond Key > > Subject: RE: Draft of new L2VPN WG Charter > > To: , > > Message-ID: > > Content-Type: text/plain; charset=3D"iso-8859-1" > > > > > > I support the re-charter. > > Raymond Key > > > > > Date: Fri, 18 Mar 2011 17:41:08 +0000 > > > Subject: Draft of new L2VPN WG Charter > > > From: giles.heron@gmail.com > > > To: l2vpn@ietf.org > > > > > > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and > E-Tree > > > in-scope. > > > > > > Please find attached a draft charter for discussion both on this list > and at > > > IETF 80 in Prague. > > > > > > Nabil and Giles > > > > > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.htm> > > > > ------------------------------ > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --00151747b6fa9fafdd04a11104e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support the re-charter.
Simon

2011/= 4/14 Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com>=

Giles,

= =A0

I believe the charter looks good. Both E-TREE and E-VPN are= very important technologies we need to support in L2VPN.

= =A0

Cheers,

Wim



> Message: 1
> Da= te: Thu, 31 Mar 2011 07:38:39 +1100
> From: Raymond Key <= raymond.key@ieee.= org>
> Subject: RE: Draft of new L2VPN WG Charter
> To: &l= t;giles.heron@gm= ail.com>, <l2= vpn@ietf.org>
> Message-ID: <SNT123-W52757872E60FD76BB6F9C1F4BC0@phx.gbl>
> Content-Type: text/plain; charset=3D"iso-8859-1"
>
>
> I support the re-charte= r.
> Raymond Key
> =A0
> > Date: Fri, = 18 Mar 2011 17:41:08 +0000
> > Subject: Draft of new L2VP= N WG Charter
> > From: giles.heron@gmail.com
> > To: l2vpn= @ietf.org
> >
> > We plan to re-ch= arter the L2VPN WG - primarily to bring E-VPN and E-Tree
> &= gt; in-scope.
> >
> > Please find attached a draft charter f= or discussion both on this list and at
> > IETF 80 in Pra= gue.
> >
> > Nabil and Giles
> >
> >
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0
> -------------- next part --------= ------
> An HTML attachment was scrubbed...
>= URL: <http://ww= w.ietf.org/mail-
> archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.htm>=
>
> ------------------------------
= > 

=A0
--------------------------------------------------------=

ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0con=
tained=A0in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender'=
s=A0organization.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Reci=
pients=A0named=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0=
are=A0not=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0commun=
ication=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0con=
fidential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individu=
al=A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0=
received=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=
=A0of=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0ar=
e=A0those=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0b=
y=A0ZTE=A0Anti-Spam=A0system.

--00151747b6fa9fafdd04a11104e4-- From xuxh@huawei.com Tue Apr 19 03:05:13 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A06EE0665 for ; Tue, 19 Apr 2011 03:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[AWL=2.847, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge6eqwcUtEEN for ; Tue, 19 Apr 2011 03:05:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 719DAE06FD for ; Tue, 19 Apr 2011 03:05:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJW00CQY9A0TI@szxga04-in.huawei.com> for l2vpn@ietf.org; Tue, 19 Apr 2011 18:03:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJW00JJP9A01S@szxga04-in.huawei.com> for l2vpn@ietf.org; Tue, 19 Apr 2011 18:03:36 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJW007D299Z3O@szxml06-in.huawei.com> for l2vpn@ietf.org; Tue, 19 Apr 2011 18:03:36 +0800 (CST) Date: Tue, 19 Apr 2011 18:12:15 +0800 From: Xu Xiaohu Subject: Simplified multicast in IS-IS VPLS To: l2vpn@ietf.org Message-id: <005101cbfe7a$42037860$c60a6920$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwA== x-cr-hashedpuzzle: BC/f BIG6 Bape CJvZ Cz0e DgzR Eocz ExsJ FVDo F+Si Geui Grlp G1WN Huwh H7d3 I5Kk; 1; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B4B60245-EA5B-47BF-8762-7A2AB8ACF8B1}; eAB1AHgAaABAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 19 Apr 2011 10:12:13 GMT; UwBpAG0AcABsAGkAZgBpAGUAZAAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAaQBuACAASQBTAC0ASQBTACAAVgBQAEwAUwA= x-cr-puzzleid: {B4B60245-EA5B-47BF-8762-7A2AB8ACF8B1} X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 10:05:13 -0000 Hi all, I just noticed from Eric's recent comments on draft-ietf-l2vpn-vpls-mcast-08 as follows (see the thread: http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) that VPLS-MCAST doesn't support IP-based provider multicast distribution tree. Therefore, I would like to reiterate that multicast in IS-IS VPLS could use IP-based provider multicast distribution tree. Details are as follows: *************************************************************************** 5.1.2. Multicast/Broadcast There are two major multicast modes for IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The encapsulation corresponding to each mode is described in the following sub-sections. 5.1.2.1. Ingress Replication Mode In the ingress replication mode, an ingress PE router forward the CE multicast/broadcast frames received via its attachment circuits towards each remote PE router of the same VPLS instance in the separate IP based tunnels destined for each remote PE router. Hence, the encapsulation in this mode has no difference from that for unicast. 5.1.2.2. P-Multicast Tree Mode In the non-aggregative P-Multicast tree mode where a single P-Multicast distribution tree in the backbone is exclusively used by one VPLS instance, the MAC-in-IP encapsulation is used directly since the destination IP address (i.e., multicast address) contained in the IP-based tunnel header is enough for the egress PE routers to determine which VPLS instance the encapsulated CE packets received from a remote PE router belongs to. For aggregative P-Multicast tree mode in which a single P-Multicast tree is shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation SHOULD be used. The MPLS label contained in the inner MPLS header would be used by the egress PE routers to identify the particular VPLS instance that the received CE data packets belong to. To avoid introducing the complex upstream label assignment mechanism [RFC5331], it is strongly suggested that the globally unique VPLS label SHOULD be used in this particular case. Thus, the value of the VPN ID filed could be directly copied to the VPLS Label field. **************************************************************************** In addition, you may notice that IS-IS VPLS also allows using the globally unique VPLS label so as to avoid using the complex upstream label assignment mechanism when implementing aggregative P-Multicast tree mode. Any comments are welcome. Best wishes, Xiaohu From Internet-Drafts@ietf.org Tue Apr 19 04:15:04 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0E6EE0665; Tue, 19 Apr 2011 04:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b780ADeBAVac; Tue, 19 Apr 2011 04:15:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0B9EE06C8; Tue, 19 Apr 2011 04:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110419111502.30510.88124.idtracker@ietfc.amsl.com> Date: Tue, 19 Apr 2011 04:15:02 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Extension to LDP-VPLS for Ethernet Broadcast and Multicast Author(s) : S. Delord, et al. Filename : draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt Pages : 20 Date : 2011-04-19 This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-19040506.I-D@ietf.org> --NextPart-- From thomas.morin@orange-ftgroup.com Tue Apr 19 04:21:18 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0129E06C8 for ; Tue, 19 Apr 2011 04:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkXoBhfkM3MQ for ; Tue, 19 Apr 2011 04:21:18 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfc.amsl.com (Postfix) with ESMTP id 1C562E0732 for ; Tue, 19 Apr 2011 04:21:18 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A25DFFC4006 for ; Tue, 19 Apr 2011 13:21:24 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9A51BFC4001 for ; Tue, 19 Apr 2011 13:21:24 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 13:21:16 +0200 Received: from [10.193.71.121] ([10.193.71.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 13:21:15 +0200 Message-ID: <4DAD702A.6040405@orange-ftgroup.com> Date: Tue, 19 Apr 2011 13:21:14 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: l2vpn@ietf.org Subject: Draft of new L2VPN WG Charter References: In-Reply-To: X-TagToolbar-Keys: D20110419132059814 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Apr 2011 11:21:15.0974 (UTC) FILETIME=[E5CC6660:01CBFE83] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:21:19 -0000 I support this charter update. -Thomas Giles Heron a écrit : > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > in-scope. > > Please find attached a draft charter for discussion both on this list and at > IETF 80 in Prague. > > Nabil and Giles > > From florin.balus@alcatel-lucent.com Tue Apr 19 08:41:40 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3A00E0700 for ; Tue, 19 Apr 2011 08:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUkgOhhgnKNZ for ; Tue, 19 Apr 2011 08:41:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id EF146E0691 for ; Tue, 19 Apr 2011 08:41:39 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3JFeugm019655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 10:40:56 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3JFekDa014430 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 10:40:56 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 19 Apr 2011 10:40:49 -0500 From: "Balus, Florin Stelian (Florin)" To: Xu Xiaohu , "l2vpn@ietf.org" Date: Tue, 19 Apr 2011 10:40:42 -0500 Subject: RE: Simplified multicast in IS-IS VPLS Thread-Topic: Simplified multicast in IS-IS VPLS Thread-Index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwAAK3jAA Message-ID: <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <005101cbfe7a$42037860$c60a6920$@com> In-Reply-To: <005101cbfe7a$42037860$c60a6920$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:41:41 -0000 Hi Xiaohu, During the working group session in Prague there was feedback from the room= we should not introduce yet another solution in this space.=20 If this is indeed a requirement we should focus on extending the existing I= S-IS based technologies developed by IEEE or IETF: i.e. IEEE 802.1aq/SPB or= IETF TRILL. If you want to stay in the context of solutions addressed already by L2VPN = WG I suggest you go for the SPB option as it is based on IEEE Ethernet enca= psulations (QinQ/802.1ad and PBB/802.1ah) that we already considered/addres= sed in terms of both VPWS and VPLS solution contexts - we put a lot of work= already in a number of VPLS and PBB-VPLS RFCs/WG drafts on the subject, in= cluding interop ones. I hope this helps. Florin > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Xu Xiaohu > Sent: Tuesday, April 19, 2011 3:12 AM > To: l2vpn@ietf.org > Subject: Simplified multicast in IS-IS VPLS >=20 > Hi all, >=20 > I just noticed from Eric's recent comments on draft-ietf-l2vpn-vpls- > mcast-08 > as follows (see the thread: > http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) that > VPLS-MCAST doesn't support IP-based provider multicast distribution > tree. >=20 > Therefore, I would like to reiterate that multicast in IS-IS VPLS could > use > IP-based provider multicast distribution tree. Details are as follows: >=20 > *********************************************************************** > **** > 5.1.2. Multicast/Broadcast > There are two major multicast modes for IS-IS VPLS: ingress replication > mode > and P-Multicast tree mode. > The encapsulation corresponding to each mode is described in the > following > sub-sections. >=20 > 5.1.2.1. Ingress Replication Mode > In the ingress replication mode, an ingress PE router forward the CE > multicast/broadcast frames received via its attachment circuits towards > each > remote PE router of the same VPLS instance in the separate IP based > tunnels > destined for each remote PE router. Hence, the encapsulation in this > mode > has no difference from that for unicast. >=20 > 5.1.2.2. P-Multicast Tree Mode > In the non-aggregative P-Multicast tree mode where a single P-Multicast > distribution tree in the backbone is exclusively used by one VPLS > instance, > the MAC-in-IP encapsulation is used directly since the destination IP > address (i.e., multicast address) contained in the IP-based tunnel > header is > enough for the egress PE routers to determine which VPLS instance the > encapsulated CE packets received from a remote PE router belongs to. > For aggregative P-Multicast tree mode in which a single P-Multicast > tree is > shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation > SHOULD > be used. The MPLS label contained in the inner MPLS header would be > used by > the egress PE routers to identify the particular VPLS instance that the > received CE data packets belong to. To avoid introducing the complex > upstream label assignment mechanism [RFC5331], it is strongly suggested > that > the globally unique VPLS label SHOULD be used in this particular case. > Thus, > the value of the VPN ID filed could be directly copied to the VPLS > Label > field. > *********************************************************************** > ***** >=20 > In addition, you may notice that IS-IS VPLS also allows using the > globally > unique VPLS label so as to avoid using the complex upstream label > assignment > mechanism when implementing aggregative P-Multicast tree mode. >=20 > Any comments are welcome. >=20 > Best wishes, > Xiaohu From prvs=7090958063=hshah@ciena.com Tue Apr 19 09:25:31 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5DCAE07CF for ; Tue, 19 Apr 2011 09:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyInhiI7l-Si for ; Tue, 19 Apr 2011 09:25:31 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfc.amsl.com (Postfix) with ESMTP id EA813E07C0 for ; Tue, 19 Apr 2011 09:25:30 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p3JGJFFp013319; Tue, 19 Apr 2011 12:25:21 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id vsd1hr7wh-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Apr 2011 12:25:21 -0400 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server id 8.1.436.0; Tue, 19 Apr 2011 12:25:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Simplified multicast in IS-IS VPLS Date: Tue, 19 Apr 2011 12:24:52 -0400 Message-ID: In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Simplified multicast in IS-IS VPLS Thread-Index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwAAK3jAAAACvFvA= References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> From: "Shah, Himanshu" To: "Balus, Florin Stelian (Florin)" , "Xu Xiaohu" , X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-19_05:2011-04-19, 2011-04-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104190053 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:25:32 -0000 Hi Florin - Not sure I completely agree with you. The concept of using ISIS based VPLS solution did intrigue me a little bit. The aspect I am little concerned about this proposal is needing P routers to participate in=20 VPLS DB population (as far as I understand).=20 IS-IS based solutions on customer facing networks is not same as what is proposed in this solution. Let us investigate further (and not use legacy based argument) before punting it. IMO, himanshu -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balus, Florin Stelian (Florin) Sent: Tuesday, April 19, 2011 11:41 AM To: Xu Xiaohu; l2vpn@ietf.org Subject: RE: Simplified multicast in IS-IS VPLS Hi Xiaohu, During the working group session in Prague there was feedback from the room we should not introduce yet another solution in this space.=20 If this is indeed a requirement we should focus on extending the existing IS-IS based technologies developed by IEEE or IETF: i.e. IEEE 802.1aq/SPB or IETF TRILL. If you want to stay in the context of solutions addressed already by L2VPN WG I suggest you go for the SPB option as it is based on IEEE Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we already considered/addressed in terms of both VPWS and VPLS solution contexts - we put a lot of work already in a number of VPLS and PBB-VPLS RFCs/WG drafts on the subject, including interop ones. I hope this helps. Florin > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Xu Xiaohu > Sent: Tuesday, April 19, 2011 3:12 AM > To: l2vpn@ietf.org > Subject: Simplified multicast in IS-IS VPLS >=20 > Hi all, >=20 > I just noticed from Eric's recent comments on draft-ietf-l2vpn-vpls- > mcast-08 > as follows (see the thread: > http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) that > VPLS-MCAST doesn't support IP-based provider multicast distribution > tree. >=20 > Therefore, I would like to reiterate that multicast in IS-IS VPLS could > use > IP-based provider multicast distribution tree. Details are as follows: >=20 > *********************************************************************** > **** > 5.1.2. Multicast/Broadcast > There are two major multicast modes for IS-IS VPLS: ingress replication > mode > and P-Multicast tree mode. > The encapsulation corresponding to each mode is described in the > following > sub-sections. >=20 > 5.1.2.1. Ingress Replication Mode > In the ingress replication mode, an ingress PE router forward the CE > multicast/broadcast frames received via its attachment circuits towards > each > remote PE router of the same VPLS instance in the separate IP based > tunnels > destined for each remote PE router. Hence, the encapsulation in this > mode > has no difference from that for unicast. >=20 > 5.1.2.2. P-Multicast Tree Mode > In the non-aggregative P-Multicast tree mode where a single P-Multicast > distribution tree in the backbone is exclusively used by one VPLS > instance, > the MAC-in-IP encapsulation is used directly since the destination IP > address (i.e., multicast address) contained in the IP-based tunnel > header is > enough for the egress PE routers to determine which VPLS instance the > encapsulated CE packets received from a remote PE router belongs to. > For aggregative P-Multicast tree mode in which a single P-Multicast > tree is > shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation > SHOULD > be used. The MPLS label contained in the inner MPLS header would be > used by > the egress PE routers to identify the particular VPLS instance that the > received CE data packets belong to. To avoid introducing the complex > upstream label assignment mechanism [RFC5331], it is strongly suggested > that > the globally unique VPLS label SHOULD be used in this particular case. > Thus, > the value of the VPN ID filed could be directly copied to the VPLS > Label > field. > *********************************************************************** > ***** >=20 > In addition, you may notice that IS-IS VPLS also allows using the > globally > unique VPLS label so as to avoid using the complex upstream label > assignment > mechanism when implementing aggregative P-Multicast tree mode. >=20 > Any comments are welcome. >=20 > Best wishes, > Xiaohu From raszuk@cisco.com Tue Apr 19 09:44:44 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AFDBEE07A3 for ; Tue, 19 Apr 2011 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgTPUpRZOqkP for ; Tue, 19 Apr 2011 09:44:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 81FEAE07D1 for ; Tue, 19 Apr 2011 09:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4911; q=dns/txt; s=iport; t=1303231483; x=1304441083; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ODVtzW3WJW8H4kWY7Xy3qzFv+33YQoGR/L2XZ3n2Hek=; b=OOTZFTQCXC5LHa3qR9QKVoJHkrIG5jCy65PknKVBMEjRzV56IEaDpsH2 ifmkqqtWy5CvgQxWw+FcBk69It8FNuf9FKdP4dq6ZojEaHpkCqW1D7VZg Q2+7TpS0PnFUsHyXtNy6LarRYq++XUzz1fUai9hThp5Uz69HnaOjMELsb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAAW7rU2rRDoI/2dsb2JhbACXI44Jd4hvnyOCdw4BmWKCf4JyBI4Hg3w X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="683966215" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 16:44:42 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3JGieur002572; Tue, 19 Apr 2011 16:44:41 GMT Message-ID: <4DADBBF8.8040701@cisco.com> Date: Tue, 19 Apr 2011 18:44:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Balus, Florin Stelian (Florin)" Subject: Re: Simplified multicast in IS-IS VPLS References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:44:44 -0000 Hi Florin, > During the working group session in Prague there was feedback from > the room we should not introduce yet another solution in this space. Having feedback on the WG mic is good, but having a good and optimal solution to the problem is even better. To deliver efficient multicast you need to be topology aware of a given network. And nothing is closer to accomplish this goal then link state IGP. Clearly along the lines of separation from routing which in BGP usually is accomplished by defining new SAFI in the ISIS one could easily utilize multi-instance ISIS approach as defined in http://tools.ietf.org/html/draft-ietf-isis-mi-04. Concerns reg P routers state should be analyzed against multicast distribution optimality. Some multicast types of traffic carrying large amount of traffic truly deserve to have efficient distribution patterns and their replication sweet spot is to happen within the network. That on the other hand is very hard to do using some overlay like BGP. For the choice of transport it seems that both native IP as well as mLDP would work very well with ISIS VPLS instance. Many thx, R. > Hi Xiaohu, > > During the working group session in Prague there was feedback from > the room we should not introduce yet another solution in this space. > > If this is indeed a requirement we should focus on extending the > existing IS-IS based technologies developed by IEEE or IETF: i.e. > IEEE 802.1aq/SPB or IETF TRILL. > > If you want to stay in the context of solutions addressed already by > L2VPN WG I suggest you go for the SPB option as it is based on IEEE > Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we > already considered/addressed in terms of both VPWS and VPLS solution > contexts - we put a lot of work already in a number of VPLS and > PBB-VPLS RFCs/WG drafts on the subject, including interop ones. > > I hope this helps. > > Florin > >> -----Original Message----- From: l2vpn-bounces@ietf.org >> [mailto:l2vpn-bounces@ietf.org] On Behalf Of Xu Xiaohu Sent: >> Tuesday, April 19, 2011 3:12 AM To: l2vpn@ietf.org Subject: >> Simplified multicast in IS-IS VPLS >> >> Hi all, >> >> I just noticed from Eric's recent comments on >> draft-ietf-l2vpn-vpls- mcast-08 as follows (see the thread: >> http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) >> that VPLS-MCAST doesn't support IP-based provider multicast >> distribution tree. >> >> Therefore, I would like to reiterate that multicast in IS-IS VPLS >> could use IP-based provider multicast distribution tree. Details >> are as follows: >> >> *********************************************************************** >> >> **** >> 5.1.2. Multicast/Broadcast There are two major multicast modes for >> IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The >> encapsulation corresponding to each mode is described in the >> following sub-sections. >> >> 5.1.2.1. Ingress Replication Mode In the ingress replication mode, >> an ingress PE router forward the CE multicast/broadcast frames >> received via its attachment circuits towards each remote PE router >> of the same VPLS instance in the separate IP based tunnels destined >> for each remote PE router. Hence, the encapsulation in this mode >> has no difference from that for unicast. >> >> 5.1.2.2. P-Multicast Tree Mode In the non-aggregative P-Multicast >> tree mode where a single P-Multicast distribution tree in the >> backbone is exclusively used by one VPLS instance, the MAC-in-IP >> encapsulation is used directly since the destination IP address >> (i.e., multicast address) contained in the IP-based tunnel header >> is enough for the egress PE routers to determine which VPLS >> instance the encapsulated CE packets received from a remote PE >> router belongs to. For aggregative P-Multicast tree mode in which a >> single P-Multicast tree is shared by more than one VPLS instance, >> MAC-in-MPLS-IP encapsulation SHOULD be used. The MPLS label >> contained in the inner MPLS header would be used by the egress PE >> routers to identify the particular VPLS instance that the received >> CE data packets belong to. To avoid introducing the complex >> upstream label assignment mechanism [RFC5331], it is strongly >> suggested that the globally unique VPLS label SHOULD be used in >> this particular case. Thus, the value of the VPN ID filed could be >> directly copied to the VPLS Label field. >> *********************************************************************** >> >> ***** >> >> In addition, you may notice that IS-IS VPLS also allows using the >> globally unique VPLS label so as to avoid using the complex >> upstream label assignment mechanism when implementing aggregative >> P-Multicast tree mode. >> >> Any comments are welcome. >> >> Best wishes, Xiaohu > > From florin.balus@alcatel-lucent.com Tue Apr 19 09:59:19 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BCBD9E0758 for ; Tue, 19 Apr 2011 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4RERJFE16xD for ; Tue, 19 Apr 2011 09:59:18 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id AC25BE0712 for ; Tue, 19 Apr 2011 09:59:18 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3JGxBkb025427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 11:59:11 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3JGx9fR021763 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 11:59:11 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 19 Apr 2011 11:59:10 -0500 From: "Balus, Florin Stelian (Florin)" To: "raszuk@cisco.com" Date: Tue, 19 Apr 2011 11:58:56 -0500 Subject: RE: Simplified multicast in IS-IS VPLS Thread-Topic: Simplified multicast in IS-IS VPLS Thread-Index: Acv+sRfWk4XcOZv7RJiqg4kXiwHUQAAAJTxA Message-ID: <2073A6C5467C99478898544C6EBA3F4602B8B89610@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <4DADBBF8.8040701@cisco.com> In-Reply-To: <4DADBBF8.8040701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {D8F4E76C-4C46-4A7D-8637-A09E258F984A} x-cr-hashedpuzzle: Hshz ID/H KtKg K0XK OGf4 O9og QI/E RPzP SZxy Tkp2 UXXN UdzS WGe6 aFlq adtl f+TC; 3; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcgBhAHMAegB1AGsAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHgAdQB4AGgAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {D8F4E76C-4C46-4A7D-8637-A09E258F984A}; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA=; Tue, 19 Apr 2011 16:58:56 GMT; UgBFADoAIABTAGkAbQBwAGwAaQBmAGkAZQBkACAAbQB1AGwAdABpAGMAYQBzAHQAIABpAG4AIABJAFMALQBJAFMAIABWAFAATABTAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:59:19 -0000 Hi Robert, I was not saying we should not consider using IS-IS in this context. I sugg= ested we consider what is missing in the existing IS-IS based solutions dev= eloped already for this space in two SDOs (e.g. both have provisions for ha= ndling mcast as far as I know).=20 Thanks, Florin > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Tuesday, April 19, 2011 9:45 AM > To: Balus, Florin Stelian (Florin) > Cc: Xu Xiaohu; l2vpn@ietf.org > Subject: Re: Simplified multicast in IS-IS VPLS >=20 > Hi Florin, >=20 > > During the working group session in Prague there was feedback from > > the room we should not introduce yet another solution in this space. >=20 > Having feedback on the WG mic is good, but having a good and optimal > solution to the problem is even better. >=20 > To deliver efficient multicast you need to be topology aware of a given > network. And nothing is closer to accomplish this goal then link state > IGP. >=20 > Clearly along the lines of separation from routing which in BGP usually > is accomplished by defining new SAFI in the ISIS one could easily > utilize multi-instance ISIS approach as defined in > http://tools.ietf.org/html/draft-ietf-isis-mi-04. >=20 > Concerns reg P routers state should be analyzed against multicast > distribution optimality. Some multicast types of traffic carrying large > amount of traffic truly deserve to have efficient distribution patterns > and their replication sweet spot is to happen within the network. That > on the other hand is very hard to do using some overlay like BGP. >=20 > For the choice of transport it seems that both native IP as well as > mLDP > would work very well with ISIS VPLS instance. >=20 > Many thx, > R. >=20 > > Hi Xiaohu, > > > > During the working group session in Prague there was feedback from > > the room we should not introduce yet another solution in this space. > > > > If this is indeed a requirement we should focus on extending the > > existing IS-IS based technologies developed by IEEE or IETF: i.e. > > IEEE 802.1aq/SPB or IETF TRILL. > > > > If you want to stay in the context of solutions addressed already by > > L2VPN WG I suggest you go for the SPB option as it is based on IEEE > > Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we > > already considered/addressed in terms of both VPWS and VPLS solution > > contexts - we put a lot of work already in a number of VPLS and > > PBB-VPLS RFCs/WG drafts on the subject, including interop ones. > > > > I hope this helps. > > > > Florin > > > >> -----Original Message----- From: l2vpn-bounces@ietf.org > >> [mailto:l2vpn-bounces@ietf.org] On Behalf Of Xu Xiaohu Sent: > >> Tuesday, April 19, 2011 3:12 AM To: l2vpn@ietf.org Subject: > >> Simplified multicast in IS-IS VPLS > >> > >> Hi all, > >> > >> I just noticed from Eric's recent comments on > >> draft-ietf-l2vpn-vpls- mcast-08 as follows (see the thread: > >> http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) > >> that VPLS-MCAST doesn't support IP-based provider multicast > >> distribution tree. > >> > >> Therefore, I would like to reiterate that multicast in IS-IS VPLS > >> could use IP-based provider multicast distribution tree. Details > >> are as follows: > >> > >> > *********************************************************************** > >> > >> > **** > >> 5.1.2. Multicast/Broadcast There are two major multicast modes for > >> IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The > >> encapsulation corresponding to each mode is described in the > >> following sub-sections. > >> > >> 5.1.2.1. Ingress Replication Mode In the ingress replication mode, > >> an ingress PE router forward the CE multicast/broadcast frames > >> received via its attachment circuits towards each remote PE router > >> of the same VPLS instance in the separate IP based tunnels destined > >> for each remote PE router. Hence, the encapsulation in this mode > >> has no difference from that for unicast. > >> > >> 5.1.2.2. P-Multicast Tree Mode In the non-aggregative P-Multicast > >> tree mode where a single P-Multicast distribution tree in the > >> backbone is exclusively used by one VPLS instance, the MAC-in-IP > >> encapsulation is used directly since the destination IP address > >> (i.e., multicast address) contained in the IP-based tunnel header > >> is enough for the egress PE routers to determine which VPLS > >> instance the encapsulated CE packets received from a remote PE > >> router belongs to. For aggregative P-Multicast tree mode in which a > >> single P-Multicast tree is shared by more than one VPLS instance, > >> MAC-in-MPLS-IP encapsulation SHOULD be used. The MPLS label > >> contained in the inner MPLS header would be used by the egress PE > >> routers to identify the particular VPLS instance that the received > >> CE data packets belong to. To avoid introducing the complex > >> upstream label assignment mechanism [RFC5331], it is strongly > >> suggested that the globally unique VPLS label SHOULD be used in > >> this particular case. Thus, the value of the VPN ID filed could be > >> directly copied to the VPLS Label field. > >> > *********************************************************************** > >> > >> > ***** > >> > >> In addition, you may notice that IS-IS VPLS also allows using the > >> globally unique VPLS label so as to avoid using the complex > >> upstream label assignment mechanism when implementing aggregative > >> P-Multicast tree mode. > >> > >> Any comments are welcome. > >> > >> Best wishes, Xiaohu > > > > From florin.balus@alcatel-lucent.com Tue Apr 19 10:12:29 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2A178E0817 for ; Tue, 19 Apr 2011 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km6b3mBXYKVD for ; Tue, 19 Apr 2011 10:12:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id 1FDD0E07B2 for ; Tue, 19 Apr 2011 10:12:28 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3JHCLre005364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 12:12:21 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3JHCKai006951 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 12:12:21 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 19 Apr 2011 12:12:20 -0500 From: "Balus, Florin Stelian (Florin)" To: "Shah, Himanshu" , Xu Xiaohu , "l2vpn@ietf.org" Date: Tue, 19 Apr 2011 12:12:15 -0500 Subject: RE: Simplified multicast in IS-IS VPLS Thread-Topic: Simplified multicast in IS-IS VPLS Thread-Index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwAAK3jAAAACvFvAAAqtFYA== Message-ID: <2073A6C5467C99478898544C6EBA3F4602B8B8961F@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:12:29 -0000 Hi Himanshu, To move forward it will be helpful for the next IETF to define the space fo= r this proposal by explaining in a few slides/in the draft text the differe= nces from existing IS-IS based approaches.=20 Thanks, Florin > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Tuesday, April 19, 2011 9:25 AM > To: Balus, Florin Stelian (Florin); Xu Xiaohu; l2vpn@ietf.org > Subject: RE: Simplified multicast in IS-IS VPLS >=20 > Hi Florin - >=20 > Not sure I completely agree with you. >=20 > The concept of using ISIS based VPLS solution did intrigue me a little > bit. > The aspect I am little concerned about this proposal is needing P > routers to participate in > VPLS DB population (as far as I understand). >=20 > IS-IS based solutions on customer facing networks is not same as what > is > proposed in this solution. Let us investigate further (and not use > legacy based argument) > before punting it. >=20 > IMO, > himanshu >=20 >=20 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Balus, Florin Stelian (Florin) > Sent: Tuesday, April 19, 2011 11:41 AM > To: Xu Xiaohu; l2vpn@ietf.org > Subject: RE: Simplified multicast in IS-IS VPLS >=20 > Hi Xiaohu, >=20 > During the working group session in Prague there was feedback from the > room we should not introduce yet another solution in this space. >=20 > If this is indeed a requirement we should focus on extending the > existing IS-IS based technologies developed by IEEE or IETF: i.e. IEEE > 802.1aq/SPB or IETF TRILL. >=20 > If you want to stay in the context of solutions addressed already by > L2VPN WG I suggest you go for the SPB option as it is based on IEEE > Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we already > considered/addressed in terms of both VPWS and VPLS solution contexts - > we put a lot of work already in a number of VPLS and PBB-VPLS RFCs/WG > drafts on the subject, including interop ones. >=20 > I hope this helps. >=20 > Florin >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Xu Xiaohu > > Sent: Tuesday, April 19, 2011 3:12 AM > > To: l2vpn@ietf.org > > Subject: Simplified multicast in IS-IS VPLS > > > > Hi all, > > > > I just noticed from Eric's recent comments on draft-ietf-l2vpn-vpls- > > mcast-08 > > as follows (see the thread: > > http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) > that > > VPLS-MCAST doesn't support IP-based provider multicast distribution > > tree. > > > > Therefore, I would like to reiterate that multicast in IS-IS VPLS > could > > use > > IP-based provider multicast distribution tree. Details are as > follows: > > > > > *********************************************************************** > > **** > > 5.1.2. Multicast/Broadcast > > There are two major multicast modes for IS-IS VPLS: ingress > replication > > mode > > and P-Multicast tree mode. > > The encapsulation corresponding to each mode is described in the > > following > > sub-sections. > > > > 5.1.2.1. Ingress Replication Mode > > In the ingress replication mode, an ingress PE router forward the CE > > multicast/broadcast frames received via its attachment circuits > towards > > each > > remote PE router of the same VPLS instance in the separate IP based > > tunnels > > destined for each remote PE router. Hence, the encapsulation in this > > mode > > has no difference from that for unicast. > > > > 5.1.2.2. P-Multicast Tree Mode > > In the non-aggregative P-Multicast tree mode where a single > P-Multicast > > distribution tree in the backbone is exclusively used by one VPLS > > instance, > > the MAC-in-IP encapsulation is used directly since the destination IP > > address (i.e., multicast address) contained in the IP-based tunnel > > header is > > enough for the egress PE routers to determine which VPLS instance the > > encapsulated CE packets received from a remote PE router belongs to. > > For aggregative P-Multicast tree mode in which a single P-Multicast > > tree is > > shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation > > SHOULD > > be used. The MPLS label contained in the inner MPLS header would be > > used by > > the egress PE routers to identify the particular VPLS instance that > the > > received CE data packets belong to. To avoid introducing the complex > > upstream label assignment mechanism [RFC5331], it is strongly > suggested > > that > > the globally unique VPLS label SHOULD be used in this particular > case. > > Thus, > > the value of the VPN ID filed could be directly copied to the VPLS > > Label > > field. > > > *********************************************************************** > > ***** > > > > In addition, you may notice that IS-IS VPLS also allows using the > > globally > > unique VPLS label so as to avoid using the complex upstream label > > assignment > > mechanism when implementing aggregative P-Multicast tree mode. > > > > Any comments are welcome. > > > > Best wishes, > > Xiaohu From paul@unbehagen.net Tue Apr 19 10:20:09 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5F40DE082F for ; Tue, 19 Apr 2011 10:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7TMf-iw43Bt for ; Tue, 19 Apr 2011 10:20:08 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 2658AE082A for ; Tue, 19 Apr 2011 10:20:08 -0700 (PDT) Received: by pxi20 with SMTP id 20so4234820pxi.27 for ; Tue, 19 Apr 2011 10:20:04 -0700 (PDT) Received: by 10.68.56.8 with SMTP id w8mr2721648pbp.334.1303233604539; Tue, 19 Apr 2011 10:20:04 -0700 (PDT) Received: from [10.0.240.199] ([166.205.139.176]) by mx.google.com with ESMTPS id f1sm56317pbm.93.2011.04.19.10.20.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 10:20:03 -0700 (PDT) References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <4DADBBF8.8040701@cisco.com> <2073A6C5467C99478898544C6EBA3F4602B8B89610@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602B8B89610@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <618006FD-32B6-4988-B955-95F9046778C6@unbehagen.net> X-Mailer: iPhone Mail (8F190) From: Paul Unbehagen Subject: Re: Simplified multicast in IS-IS VPLS Date: Tue, 19 Apr 2011 10:19:21 -0700 To: "Balus, Florin Stelian (Florin)" Cc: "raszuk@cisco.com" , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:20:09 -0000 To that point the IEEE did tremendous amount of study on efficient multicast= management when designing the algorithms behind the IS-IS topology.=20 -- Paul Unbehagen from my iPhone=20 On Apr 19, 2011, at 9:58 AM, "Balus, Florin Stelian (Florin)" wrote: > Hi Robert, >=20 > I was not saying we should not consider using IS-IS in this context. I sug= gested we consider what is missing in the existing IS-IS based solutions dev= eloped already for this space in two SDOs (e.g. both have provisions for han= dling mcast as far as I know).=20 >=20 > Thanks, > Florin >=20 >> -----Original Message----- >> From: Robert Raszuk [mailto:raszuk@cisco.com] >> Sent: Tuesday, April 19, 2011 9:45 AM >> To: Balus, Florin Stelian (Florin) >> Cc: Xu Xiaohu; l2vpn@ietf.org >> Subject: Re: Simplified multicast in IS-IS VPLS >>=20 >> Hi Florin, >>=20 >>> During the working group session in Prague there was feedback from >>> the room we should not introduce yet another solution in this space. >>=20 >> Having feedback on the WG mic is good, but having a good and optimal >> solution to the problem is even better. >>=20 >> To deliver efficient multicast you need to be topology aware of a given >> network. And nothing is closer to accomplish this goal then link state >> IGP. >>=20 >> Clearly along the lines of separation from routing which in BGP usually >> is accomplished by defining new SAFI in the ISIS one could easily >> utilize multi-instance ISIS approach as defined in >> http://tools.ietf.org/html/draft-ietf-isis-mi-04. >>=20 >> Concerns reg P routers state should be analyzed against multicast >> distribution optimality. Some multicast types of traffic carrying large >> amount of traffic truly deserve to have efficient distribution patterns >> and their replication sweet spot is to happen within the network. That >> on the other hand is very hard to do using some overlay like BGP. >>=20 >> For the choice of transport it seems that both native IP as well as >> mLDP >> would work very well with ISIS VPLS instance. >>=20 >> Many thx, >> R. >>=20 >>> Hi Xiaohu, >>>=20 >>> During the working group session in Prague there was feedback from >>> the room we should not introduce yet another solution in this space. >>>=20 >>> If this is indeed a requirement we should focus on extending the >>> existing IS-IS based technologies developed by IEEE or IETF: i.e. >>> IEEE 802.1aq/SPB or IETF TRILL. >>>=20 >>> If you want to stay in the context of solutions addressed already by >>> L2VPN WG I suggest you go for the SPB option as it is based on IEEE >>> Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we >>> already considered/addressed in terms of both VPWS and VPLS solution >>> contexts - we put a lot of work already in a number of VPLS and >>> PBB-VPLS RFCs/WG drafts on the subject, including interop ones. >>>=20 >>> I hope this helps. >>>=20 >>> Florin >>>=20 >>>> -----Original Message----- From: l2vpn-bounces@ietf.org >>>> [mailto:l2vpn-bounces@ietf.org] On Behalf Of Xu Xiaohu Sent: >>>> Tuesday, April 19, 2011 3:12 AM To: l2vpn@ietf.org Subject: >>>> Simplified multicast in IS-IS VPLS >>>>=20 >>>> Hi all, >>>>=20 >>>> I just noticed from Eric's recent comments on >>>> draft-ietf-l2vpn-vpls- mcast-08 as follows (see the thread: >>>> http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) >>>> that VPLS-MCAST doesn't support IP-based provider multicast >>>> distribution tree. >>>>=20 >>>> Therefore, I would like to reiterate that multicast in IS-IS VPLS >>>> could use IP-based provider multicast distribution tree. Details >>>> are as follows: >>>>=20 >>>>=20 >> *********************************************************************** >>>>=20 >>>>=20 >> **** >>>> 5.1.2. Multicast/Broadcast There are two major multicast modes for >>>> IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The >>>> encapsulation corresponding to each mode is described in the >>>> following sub-sections. >>>>=20 >>>> 5.1.2.1. Ingress Replication Mode In the ingress replication mode, >>>> an ingress PE router forward the CE multicast/broadcast frames >>>> received via its attachment circuits towards each remote PE router >>>> of the same VPLS instance in the separate IP based tunnels destined >>>> for each remote PE router. Hence, the encapsulation in this mode >>>> has no difference from that for unicast. >>>>=20 >>>> 5.1.2.2. P-Multicast Tree Mode In the non-aggregative P-Multicast >>>> tree mode where a single P-Multicast distribution tree in the >>>> backbone is exclusively used by one VPLS instance, the MAC-in-IP >>>> encapsulation is used directly since the destination IP address >>>> (i.e., multicast address) contained in the IP-based tunnel header >>>> is enough for the egress PE routers to determine which VPLS >>>> instance the encapsulated CE packets received from a remote PE >>>> router belongs to. For aggregative P-Multicast tree mode in which a >>>> single P-Multicast tree is shared by more than one VPLS instance, >>>> MAC-in-MPLS-IP encapsulation SHOULD be used. The MPLS label >>>> contained in the inner MPLS header would be used by the egress PE >>>> routers to identify the particular VPLS instance that the received >>>> CE data packets belong to. To avoid introducing the complex >>>> upstream label assignment mechanism [RFC5331], it is strongly >>>> suggested that the globally unique VPLS label SHOULD be used in >>>> this particular case. Thus, the value of the VPN ID filed could be >>>> directly copied to the VPLS Label field. >>>>=20 >> *********************************************************************** >>>>=20 >>>>=20 >> ***** >>>>=20 >>>> In addition, you may notice that IS-IS VPLS also allows using the >>>> globally unique VPLS label so as to avoid using the complex >>>> upstream label assignment mechanism when implementing aggregative >>>> P-Multicast tree mode. >>>>=20 >>>> Any comments are welcome. >>>>=20 >>>> Best wishes, Xiaohu >>>=20 >>>=20 >=20 From raszuk@cisco.com Tue Apr 19 11:05:31 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5C62E082F for ; Tue, 19 Apr 2011 11:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH9S0upEF4xM for ; Tue, 19 Apr 2011 11:05:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 1F704E0702 for ; Tue, 19 Apr 2011 11:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=372; q=dns/txt; s=iport; t=1303236331; x=1304445931; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vpAtQDKukVKdRlRrK42hCiH3eCmanRzscYXzmrZ7gOw=; b=KC+QSEHCQlD7fMxJrfY+20ZGedYT9UjxfeDUU3N7ycfQTxg5v1XHUbb9 iVfy8x7iKq7KLV3FPj+2danPMyf+tHogk+/ahGR12sfE3UwIrLK8dmwnZ NPGu0YsxvlKlYdfaXqRmm9qDTOnkEvdBPOHCjp7OHN7IZyL/moGlbNa1I w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADTOrU2rRDoI/2dsb2JhbAClLHeIb59mgncOAZlmhXEEjgeDfA X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="684019805" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 18:05:30 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3JI5TeB019862; Tue, 19 Apr 2011 18:05:29 GMT Message-ID: <4DADCEF5.6000505@cisco.com> Date: Tue, 19 Apr 2011 20:05:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Balus, Florin Stelian (Florin)" Subject: Re: Simplified multicast in IS-IS VPLS References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <4DADBBF8.8040701@cisco.com> <2073A6C5467C99478898544C6EBA3F4602B8B89610@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602B8B89610@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:05:32 -0000 Then I think we are all in agreement. Thx for clarification, R. > Hi Robert, > > I was not saying we should not consider using IS-IS in this context. I suggested we consider what is missing in the existing IS-IS based solutions developed already for this space in two SDOs (e.g. both have provisions for handling mcast as far as I know). > > Thanks, > Florin From xuxh@huawei.com Tue Apr 19 19:03:54 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47359E07C6 for ; Tue, 19 Apr 2011 19:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=-1.496, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQhEIS7zvhfn for ; Tue, 19 Apr 2011 19:03:53 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 045EBE06F5 for ; Tue, 19 Apr 2011 19:03:53 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00BSBHOT1S@szxga05-in.huawei.com> for l2vpn@ietf.org; Wed, 20 Apr 2011 10:02:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX0004MHOTQH@szxga05-in.huawei.com> for l2vpn@ietf.org; Wed, 20 Apr 2011 10:02:53 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJX00MNOHOSEI@szxml04-in.huawei.com> for l2vpn@ietf.org; Wed, 20 Apr 2011 10:02:53 +0800 (CST) Date: Wed, 20 Apr 2011 10:11:32 +0800 From: Xu Xiaohu Subject: re: Simplified multicast in IS-IS VPLS In-reply-to: <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> To: "'Balus, Florin Stelian (Florin)'" , l2vpn@ietf.org Message-id: <002301cbff00$44dabd60$ce903820$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwAAK3jAAABQu2IA= References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:03:54 -0000 Hi Florin, Thanks for your suggestion. Please see my reply inline. > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C219=C8=D5 23:41 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu; l2vpn@ietf.org > =D6=F7=CC=E2: RE: Simplified multicast in IS-IS VPLS >=20 > Hi Xiaohu, >=20 > During the working group session in Prague there was feedback from the room > we should not introduce yet another solution in this space. >=20 > If this is indeed a requirement we should focus on extending the = existing IS-IS > based technologies developed by IEEE or IETF: i.e. IEEE 802.1aq/SPB or IETF > TRILL. Could you please give your reason why we should focus on extending the existing IS-IS based technologies developed by IEEE or IETF: i.e. IEEE 802.1aq/SPB or IETF TRILL, rather than extending the existing proven and familiar VPLS technology a little bit?=20 I agree that TRILL and SPB have many charming characters. However, IMHO, there is still a long way to go for both TRILL and SPB before they are comparable to IP and VPLS on the aspect of technology stability and maturation. e.g., breaking 4096 VLANs limit, OAM tools for TRILL, Adding = TTL and simplifying the ECMP algorithm for SPB.=20 Before a piece of delicious cake being baked, could somebody be allowed = to heat his existing bread to allay his hunger? I think people could make = their wise choices depending on their starvation status. > If you want to stay in the context of solutions addressed already by = L2VPN WG I > suggest you go for the SPB option as it is based on IEEE Ethernet > encapsulations (QinQ/802.1ad and PBB/802.1ah) that we already > considered/addressed in terms of both VPWS and VPLS solution contexts = - we > put a lot of work already in a number of VPLS and PBB-VPLS RFCs/WG = drafts on > the subject, including interop ones. Good point. The intention of IS-IS VPLS is just to reuse the existing = VPLS and IP technologies, since we have put a lot of work already in a number = of VPLS and PBB-VPLS RFCs/WG drafts, without mentioning numerous IP RFCs/WG drafts. As you know, from the perspective of data plane, IS-IS VPLS = could reuse the existing VPLS encapsulation (e.g., VPLS over IP/GRE) and forwarding mechanisms WITHOUT ANY CHANGE. Thanks again for your comments. Best wishes, Xiaohu > I hope this helps. >=20 > Florin >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf > > Of Xu Xiaohu > > Sent: Tuesday, April 19, 2011 3:12 AM > > To: l2vpn@ietf.org > > Subject: Simplified multicast in IS-IS VPLS > > > > Hi all, > > > > I just noticed from Eric's recent comments on draft-ietf-l2vpn-vpls- > > mcast-08 > > as follows (see the thread: > > http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) = that > > VPLS-MCAST doesn't support IP-based provider multicast distribution > > tree. > > > > Therefore, I would like to reiterate that multicast in IS-IS VPLS = could > > use > > IP-based provider multicast distribution tree. Details are as = follows: > > > > > **************************************************************** > ******* > > **** > > 5.1.2. Multicast/Broadcast > > There are two major multicast modes for IS-IS VPLS: ingress = replication > > mode > > and P-Multicast tree mode. > > The encapsulation corresponding to each mode is described in the > > following > > sub-sections. > > > > 5.1.2.1. Ingress Replication Mode > > In the ingress replication mode, an ingress PE router forward the CE > > multicast/broadcast frames received via its attachment circuits = towards > > each > > remote PE router of the same VPLS instance in the separate IP based > > tunnels > > destined for each remote PE router. Hence, the encapsulation in this > > mode > > has no difference from that for unicast. > > > > 5.1.2.2. P-Multicast Tree Mode > > In the non-aggregative P-Multicast tree mode where a single = P-Multicast > > distribution tree in the backbone is exclusively used by one VPLS > > instance, > > the MAC-in-IP encapsulation is used directly since the destination = IP > > address (i.e., multicast address) contained in the IP-based tunnel > > header is > > enough for the egress PE routers to determine which VPLS instance = the > > encapsulated CE packets received from a remote PE router belongs to. > > For aggregative P-Multicast tree mode in which a single P-Multicast > > tree is > > shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation > > SHOULD > > be used. The MPLS label contained in the inner MPLS header would be > > used by > > the egress PE routers to identify the particular VPLS instance that = the > > received CE data packets belong to. To avoid introducing the complex > > upstream label assignment mechanism [RFC5331], it is strongly = suggested > > that > > the globally unique VPLS label SHOULD be used in this particular = case. > > Thus, > > the value of the VPN ID filed could be directly copied to the VPLS > > Label > > field. > > > **************************************************************** > ******* > > ***** > > > > In addition, you may notice that IS-IS VPLS also allows using the > > globally > > unique VPLS label so as to avoid using the complex upstream label > > assignment > > mechanism when implementing aggregative P-Multicast tree mode. > > > > Any comments are welcome. > > > > Best wishes, > > Xiaohu From xuxh@huawei.com Tue Apr 19 19:44:13 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9112E0703 for ; Tue, 19 Apr 2011 19:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPXDYRd1XSCt for ; Tue, 19 Apr 2011 19:44:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 4EFA8E0670 for ; Tue, 19 Apr 2011 19:44:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00GP8JJ7Z8@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 20 Apr 2011 10:42:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00KKDJJ7UH@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 20 Apr 2011 10:42:43 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJX009QUJJ6EW@szxml06-in.huawei.com> for l2vpn@ietf.org; Wed, 20 Apr 2011 10:42:43 +0800 (CST) Date: Wed, 20 Apr 2011 10:51:22 +0800 From: Xu Xiaohu Subject: re: Simplified multicast in IS-IS VPLS In-reply-to: <4DADBBF8.8040701@cisco.com> To: raszuk@cisco.com, "'Balus, Florin Stelian (Florin)'" Message-id: <002401cbff05$d5820b20$80862160$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acv+sRerE7LF1CfgQ+qEPzu1SbJmkwAVJnmg x-cr-puzzleid: {D5EA816A-2AA9-4D30-B6EE-4082A9D4424D} x-cr-hashedpuzzle: BADF BQsO GYll HV2n H3On NVHI P8kT QGWT RFWF Sq5O TiLT VlCq Ybtu c5Jd eIeg fCrO; 3; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AHIAYQBzAHoAdQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {D5EA816A-2AA9-4D30-B6EE-4082A9D4424D}; eAB1AHgAaABAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 20 Apr 2011 02:51:16 GMT; cgBlADoAIABTAGkAbQBwAGwAaQBmAGkAZQBkACAAbQB1AGwAdABpAGMAYQBzAHQAIABpAG4AIABJAFMALQBJAFMAIABWAFAATABTAA== References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <4DADBBF8.8040701@cisco.com> Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:44:13 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Robert Raszuk [mailto:raszuk@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C220=C8=D5 0:45 > =CA=D5=BC=FE=C8=CB: Balus, Florin Stelian (Florin) > =B3=AD=CB=CD: Xu Xiaohu; l2vpn@ietf.org > =D6=F7=CC=E2: Re: Simplified multicast in IS-IS VPLS >=20 > Hi Florin, >=20 > > During the working group session in Prague there was feedback from > > the room we should not introduce yet another solution in this = space. >=20 > Having feedback on the WG mic is good, but having a good and optimal > solution to the problem is even better. >=20 > To deliver efficient multicast you need to be topology aware of a = given > network. And nothing is closer to accomplish this goal then link state IGP. >=20 > Clearly along the lines of separation from routing which in BGP = usually > is accomplished by defining new SAFI in the ISIS one could easily > utilize multi-instance ISIS approach as defined in > http://tools.ietf.org/html/draft-ietf-isis-mi-04. >=20 > Concerns reg P routers state should be analyzed against multicast > distribution optimality. Some multicast types of traffic carrying = large > amount of traffic truly deserve to have efficient distribution = patterns > and their replication sweet spot is to happen within the network. That > on the other hand is very hard to do using some overlay like BGP. >=20 > For the choice of transport it seems that both native IP as well as = mLDP > would work very well with ISIS VPLS instance. Hi Robert, Yes, your observation is correct. Best wishes, Xiaohu > Many thx, > R. >=20 > > Hi Xiaohu, > > > > During the working group session in Prague there was feedback from > > the room we should not introduce yet another solution in this space. > > > > If this is indeed a requirement we should focus on extending the > > existing IS-IS based technologies developed by IEEE or IETF: i.e. > > IEEE 802.1aq/SPB or IETF TRILL. > > > > If you want to stay in the context of solutions addressed already by > > L2VPN WG I suggest you go for the SPB option as it is based on IEEE > > Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we > > already considered/addressed in terms of both VPWS and VPLS solution > > contexts - we put a lot of work already in a number of VPLS and > > PBB-VPLS RFCs/WG drafts on the subject, including interop ones. > > > > I hope this helps. > > > > Florin > > > >> -----Original Message----- From: l2vpn-bounces@ietf.org > >> [mailto:l2vpn-bounces@ietf.org] On Behalf Of Xu Xiaohu Sent: > >> Tuesday, April 19, 2011 3:12 AM To: l2vpn@ietf.org Subject: > >> Simplified multicast in IS-IS VPLS > >> > >> Hi all, > >> > >> I just noticed from Eric's recent comments on > >> draft-ietf-l2vpn-vpls- mcast-08 as follows (see the thread: > >> http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) > >> that VPLS-MCAST doesn't support IP-based provider multicast > >> distribution tree. > >> > >> Therefore, I would like to reiterate that multicast in IS-IS VPLS > >> could use IP-based provider multicast distribution tree. Details > >> are as follows: > >> > >> > **************************************************************** > ******* > >> > >> > **** > >> 5.1.2. Multicast/Broadcast There are two major multicast modes for > >> IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The > >> encapsulation corresponding to each mode is described in the > >> following sub-sections. > >> > >> 5.1.2.1. Ingress Replication Mode In the ingress replication mode, > >> an ingress PE router forward the CE multicast/broadcast frames > >> received via its attachment circuits towards each remote PE router > >> of the same VPLS instance in the separate IP based tunnels destined > >> for each remote PE router. Hence, the encapsulation in this mode > >> has no difference from that for unicast. > >> > >> 5.1.2.2. P-Multicast Tree Mode In the non-aggregative P-Multicast > >> tree mode where a single P-Multicast distribution tree in the > >> backbone is exclusively used by one VPLS instance, the MAC-in-IP > >> encapsulation is used directly since the destination IP address > >> (i.e., multicast address) contained in the IP-based tunnel header > >> is enough for the egress PE routers to determine which VPLS > >> instance the encapsulated CE packets received from a remote PE > >> router belongs to. For aggregative P-Multicast tree mode in which a > >> single P-Multicast tree is shared by more than one VPLS instance, > >> MAC-in-MPLS-IP encapsulation SHOULD be used. The MPLS label > >> contained in the inner MPLS header would be used by the egress PE > >> routers to identify the particular VPLS instance that the received > >> CE data packets belong to. To avoid introducing the complex > >> upstream label assignment mechanism [RFC5331], it is strongly > >> suggested that the globally unique VPLS label SHOULD be used in > >> this particular case. Thus, the value of the VPN ID filed could be > >> directly copied to the VPLS Label field. > >> > **************************************************************** > ******* > >> > >> > ***** > >> > >> In addition, you may notice that IS-IS VPLS also allows using the > >> globally unique VPLS label so as to avoid using the complex > >> upstream label assignment mechanism when implementing aggregative > >> P-Multicast tree mode. > >> > >> Any comments are welcome. > >> > >> Best wishes, Xiaohu > > > > From simon.delord@gmail.com Wed Apr 20 18:19:32 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55C8EE06E2 for ; Wed, 20 Apr 2011 18:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtZrUBqrHMUC for ; Wed, 20 Apr 2011 18:19:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 1533AE06DB for ; Wed, 20 Apr 2011 18:19:30 -0700 (PDT) Received: by fxm15 with SMTP id 15so848513fxm.31 for ; Wed, 20 Apr 2011 18:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=/0iR/H70tJx+cu40ih06EECqFA2yJ76+JXONRCzEym4=; b=sZLni8kTPhsb+CjIyPuc5k9+FEvz8LW4TTIMOgBXn/zx5UT26Wjrq7s+aM1IkP+7K5 VeCpkkD8NhqVbEPCafS73HvCjeaJBdzibkxFHn8pcJ/z55e45eg1DEKmyTjRf1yTMZ59 g9LcxfXsephu54ij2NxfKHp4/qrDrhb1SrSCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c9BQMcVFyurTeKlA+8u6An24QDp32W0fIhgOp+ELOhQAAvF6g/2/4LGPo88Nwzkepn ebRbrEBpBNGzMOgPfKJVBGNr4PUBu3IlMQdR0K8CSNZczsjH7usNOu08TqlNwLaj2guv TkQj3WM+vTzQ2CEtMDM8wjjIStDHGaUDKFLu8= MIME-Version: 1.0 Received: by 10.223.101.87 with SMTP id b23mr516946fao.97.1303348770222; Wed, 20 Apr 2011 18:19:30 -0700 (PDT) Received: by 10.223.113.15 with HTTP; Wed, 20 Apr 2011 18:19:30 -0700 (PDT) Date: Thu, 21 Apr 2011 09:19:30 +0800 Message-ID: Subject: draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt From: Simon Delord To: l2vpn@ietf.org Content-Type: multipart/alternative; boundary=00151744800e77b43b04a163882e X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 01:19:32 -0000 --00151744800e77b43b04a163882e Content-Type: text/plain; charset=ISO-8859-1 Dear L2VPN WG members, we have now updated the draft, which is available at http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt Comments on the list or to the authors are welcome. Thanks, Simon 2011/4/19 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Layer 2 Virtual Private Networks Working > Group of the IETF. > > > Title : Extension to LDP-VPLS for Ethernet Broadcast and > Multicast > Author(s) : S. Delord, et al. > Filename : draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt > Pages : 20 > Date : 2011-04-19 > > This document proposes a simple extension to LDP-VPLS to improve > bandwidth efficiency for Ethernet broadcast/multicast traffic > within a carrier's network. It makes use of unidirectional > point-to-multipoint PseudoWires to minimise payload frame duplication > on physical links. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > --00151744800e77b43b04a163882e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear L2VPN WG members,

we have now updated the draft, which is available at
http://www.ietf.org/internet-d= rafts/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-01.txt

Comments = on the list or to the authors are welcome.
Thanks,

Simon


2011/4/19 <Internet-Drafts@ietf.org>
A New Internet-Draft is availabl= e from the on-line Internet-Drafts directories.
This draft is a work ite= m of the Layer 2 Virtual Private Networks Working Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Extension to LDP-VPLS fo= r Ethernet Broadcast and Multicast
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 = : S. Delord, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-= l2vpn-ldp-vpls-broadcast-exten-01.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 = =A0 =A0 : 20
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-19

This documen= t proposes a simple extension to LDP-VPLS to improve
bandwidth efficienc= y for Ethernet broadcast/multicast traffic
within a carrier's networ= k. It makes use of unidirectional
point-to-multipoint PseudoWires to minimise payload frame duplication
on= physical links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2= vpn-ldp-vpls-broadcast-exten-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/in= ternet-drafts/

Below is the data which will enable a MIME compli= ant mail reader
implementation to automatically retrieve the ASCII version of the
Intern= et-Draft.



--00151744800e77b43b04a163882e-- From lucy.yong@huawei.com Thu Apr 21 07:55:51 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F11CE078A for ; Thu, 21 Apr 2011 07:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IijDn2ZuNXcW for ; Thu, 21 Apr 2011 07:55:50 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfc.amsl.com (Postfix) with ESMTP id 5F6CCE065C for ; Thu, 21 Apr 2011 07:55:50 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK000GM6C51O4@usaga02-in.huawei.com> for l2vpn@ietf.org; Thu, 21 Apr 2011 07:55:49 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LK00033KC510E@usaga02-in.huawei.com> for l2vpn@ietf.org; Thu, 21 Apr 2011 07:55:49 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 07:55:43 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 21 Apr 2011 07:55:48 -0700 Date: Thu, 21 Apr 2011 14:55:48 +0000 From: Lucy yong Subject: RE: Draft of new L2VPN WG Charter In-reply-to: <14C7F4F06DB5814AB0DE29716C4F6D6718445F8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-Originating-IP: [10.192.11.56] To: "Henderickx, Wim (Wim)" , "giles.heron@gmail.com" Message-id: <2691CE0099834E4A9C5044EEC662BB9D04965586@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_j0AnmLBBnCrBF2wCWD4wCw)" Content-language: en-US Accept-Language: en-US Thread-topic: Draft of new L2VPN WG Charter Thread-index: AQHL+oVHByfCCAJ7pEaQouOVm51qupRdjH6AgArmp+A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <14C7F4F06DB5814AB0DE29716C4F6D6718445F8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:55:51 -0000 --Boundary_(ID_j0AnmLBBnCrBF2wCWD4wCw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I support the re-charter. Cheers, Lucy ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 14, 2011 4:27 AM To: giles.heron@gmail.com Cc: l2vpn@ietf.org Subject: RE: Draft of new L2VPN WG Charter Giles, I believe the charter looks good. Both E-TREE and E-VPN are very important technologies we need to support in L2VPN. Cheers, Wim > Message: 1 > Date: Thu, 31 Mar 2011 07:38:39 +1100 > From: Raymond Key > Subject: RE: Draft of new L2VPN WG Charter > To: , > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > I support the re-charter. > Raymond Key > > > Date: Fri, 18 Mar 2011 17:41:08 +0000 > > Subject: Draft of new L2VPN WG Charter > > From: giles.heron@gmail.com > > To: l2vpn@ietf.org > > > > We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree > > in-scope. > > > > Please find attached a draft charter for discussion both on this list and at > > IETF 80 in Prague. > > > > Nabil and Giles > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/l2vpn/attachments/20110331/6521b5c4/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --Boundary_(ID_j0AnmLBBnCrBF2wCWD4wCw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

I support the re-charter.

Cheers,

Lucy

 

From: l2vp= n-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, April 14, 20= 11 4:27 AM
To: giles.heron@gmail.com Cc: l2vpn@ietf.org
Subject: RE: Draft of new L2= VPN WG Charter

 

Giles,

 

I believe the charter looks good. Both E-TREE and E-VPN are very = important technologies we need to support in L2VPN.

 

Cheers,

Wim

> Message: 1
> Date: Thu, 31 Mar 2011 07:38:39 +11= 00
> From: Raymond Key <raymond.key@ieee.= org>
> Subject: RE: Draft of new L2VPN WG Char= ter
> To: <giles.heron@gmail.com>, <= l2vpn@ietf.org>
> Message-ID: <SNT123-W52757872E60FD76= BB6F9C1F4BC0@phx.gbl>
> Content-Type: text/plain; charset=3D&qu= ot;iso-8859-1"
>
>
> I support the re-charter. > Raymond Key
>  
> > Date: Fri, 18 Mar 2011 17:41:08 &#= 43;0000
> > Subject: Draft of new L2VPN WG Cha= rter
> > From: giles.heron@gmail.com=
> > To: l2vpn@ietf.org
> >
> > We plan to re-charter the L2VPN WG= - primarily to bring E-VPN and E-Tree
> > in-scope.
> >
> > Please find attached a draft chart= er for discussion both on this list and at
> > IETF 80 in <= st1:place w:st=3D"on">Prague.
> >
> > Nabil and Giles
> >
> >
>           &nbs= p;          
> -------------- next part --------------=
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/l2vpn/attachments/20110331/= 6521b5c4/attachment.htm>
>
> ------------------------------
> 

 
--------------------------------------------------------=

ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely propert=
y of the sender's organization. This mail&nbs=
p;communication is confidential. Recipients named =
above are obligated to maintain secrecy and&n=
bsp;are not permitted to disclose the content=
s of this communication to others.
This email and any files transmitted with&nb=
sp;it are confidential and intended solely fo=
r the use of the individual or entity&nb=
sp;to whom they are addressed. If you ha=
ve received this email in error please n=
otify the originator of the message. Any =
;views expressed in this message are those&nb=
sp;of the individual sender.
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.
--Boundary_(ID_j0AnmLBBnCrBF2wCWD4wCw)-- From josh.rogers@twcable.com Fri Apr 22 13:32:30 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3961E080D for ; Fri, 22 Apr 2011 13:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuoykSigU-h1 for ; Fri, 22 Apr 2011 13:32:29 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfc.amsl.com (Postfix) with ESMTP id 7E5BCE073E for ; Fri, 22 Apr 2011 13:32:29 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.64,255,1301889600"; d="scan'208";a="205091927" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2011 16:33:10 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 22 Apr 2011 16:32:28 -0400 From: "Rogers, Josh" To: Sam Cao Date: Fri, 22 Apr 2011 16:32:27 -0400 Subject: Re: I-D:Extension to BGP-VPLS for E-Tree Thread-Topic: I-D:Extension to BGP-VPLS for E-Tree Thread-Index: AcwBLGV6kzBwCgwZT6K94GD++1wM6g== Message-ID: References: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom> In-Reply-To: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org org" , "yortion@hotmail.com" , "chenxb@ruijie.com.cn" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 20:32:30 -0000 Sam, Thanks so much for your work on this draft. Some points below: + 3.2 - Maybe you can rephrase this? I'm having trouble following it. 3.1= mentions a method that uses a 'tag' for each frame that denotes it is sour= ced from a leaf, and 3.2 (in contrast) uses a different method. If I under= stand correctly, you want the router to be aware of what the endpoints are = and decide whether to forward to other PE's/AC's, rather than send it, and = decide after it arrives (as in 3.1). An alternate way of phrasing this tha= t you may consider is: 3. Terminology 2. The decision to forward a frame to another AC or across a PW is based= on foreknowledge of the local AC type and the remote AC type. If a frame = comes from a local Leaf-AC, then it will not forward to any other local Lea= f-AC's, and will only forward across PW(s) to a PE which has a Root-AC. In= this way, we restrict the communication between Leafs by building a partia= l mesh of PW's, intentionally excluding PW's between Leaf-AC's. Additional= PWs will need to be created to/from PE's that contain both Root and Leaf A= Cs. The purposed solution in this document prefers to the second. Two terms= are introduced, o Root-endpoint. One endpoint which connects only Root-ACs, one or more Root-ACs. o Leaf-endpoint. One endpoint which connects only Leaf-ACs, one or more Leaf-ACs. There is no endpoint which connects both Root-ACs and Leaf-ACs in the second solution, however a PE may have one of each endpoint configured i= n the same vpls instance. + Is 'endpoint' defined somewhere else? I can gather (from figure 2) that = you mean a pseudowire endpoint, but I'm not sure that is very clear here. Regarding figure 2, I at first thought there should only be one PW between = PE1 and PE3, and there should be two PW's between PE1 (since both AC1 and A= C2 can/should talk to both AC5 and AC6) In fact, I believe with the topolo= gy drawn, there should be three PW's total, however PE1 should have two VE-= ID's, and PW's terminating to each, rather than one VE-ID's terminating two= PW's as the other two PE's, which is what allows unique forwarding decisio= ns based on the source VE-ID type, root or leaf). After looking through it a second time, I realized that your intention is t= o terminate PW per 'endpoint' (this goes back to the earlier comment about = whether this is already defined somewhere) on each PE, almost segmenting th= e PE into behaving as though it was two PE's (one for the root AC's and one= for the leaf AC's) participating in the instance. While I believe that th= e additional PW may be unnecessary in this particular example, I believe yo= ur approach of using one 'endpoint' per AC type should scale with any scena= rio. It may be a good idea to try and represent the 'endpoints' in figure= 2, maybe in place of the VSI box, place two endpoint boxes on PE1, and one= box on each of the other PE's? Put an R in the root endpoints and L in th= e leaf ones, like this: |<-----------E-Tree------------>| | | V V +----------+ +---------+ Root endpoint-- PE1 | | PE2 | /Leaf endpoint +---+ |\ +---+ | | +---+ | /\ +---+ |CE1+-------AC1-+--+ R +---|---PW12---+--+ +--+-|--- --AC3----+CE3| +---+ (Root AC)| +---+-+ | | | V | | | |(Leaf AC) +---+ | | | | | S | | | | +---+ | +---+ | | | | I | | | | +---+ |CE2+----AC2----+--+ L | | | | | +--+-|------AC4----+CE4| +---+ (Leaf AC)| /++--+ | | | +-+-+ | \/ (Leaf AC) +---+ /---|----|-+ +----+----+ Leaf endpoint +^ | | | | | |PW13-2 |PW23 | | | | PW13-1| | +----+----+ /Root endpoint | | | | +-+-+ | /\ +---+ | | | | | V +--+-|--------AC5-+CE5| | | +-----------+--+ S | | | |(Root AC)+---+ | | | | I | | | | +---+ | +----------------+ | +--+-|------AC6---+CE6| | | +---+ | \/ (Root AC)+---+ | | PE3 | | +---------+ | ^ | <-----------E-Tree---------->| There is a small typo in 5.3, I believe Foex should be For. Is 5.7 a duplicate of 5.6? Regarding signaling, under the existing standards (no defined 'endpoints'),= we use opposing target communities (one for root sites, and one for leaf s= ites) successfully today to accomplish ETREE services. In the topology out= lined in figure 2, we'd configure like this: PE export import Add'l knobs PE1 target:123:1 target:123:2 (core-facing) PE2 target:123:2 target:123:1 (No local-switching) PE3 target:123:1 target:123:2 The two primary problems that we face with this method are: 1) Root to root communication is not possible. Root-Leaf and Leaf-Root are= the only possible combinations. 2) the 'core facing' knob available on the Juniper platform will cause AC2 = to communicate with AC1, but NOT communicate with any other AC's, including= AC5 and AC6. Both of these problems break the ETREE requirements draft Raymond worked on= earlier, and both are addressed with the draft you are working on now. I = look forward to seeing section 5.7 completed/extended. To recap, the primary problem we need to solve with this topology is 1) AC3= and AC4 cannot be allowed to communicate (no local switching), and 2) AC2 = cannot be allowed to communicate with AC3 and AC4 and vice versa. I believ= e what you are trying to convey is that PE1 will forward traffic from AC2 t= o PE3, but not PE2, and PE2 will forward to PE3 but not PE2, while still al= lowing AC1 to forward to PE2. Sam, this is a very good start, and I look forward to seeing it through. R= eally appreciate your efforts here, as this is a very relevant draft. Plea= se let me know if I can help. -Josh On Apr 15, 2011, at 9:25 AM, Sam Cao wrote: > Hi L2VPN working group, > > I have just updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf.o= rg/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an approa= ch to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual = Private LAN Service using BGP for auto-discovery and signaling [RFC4761], a= nd I believe that these solution concepts can be applied to both LDP-VPLS a= nd BGP-VPLS, but the implementation may be a little different. > > Grateful if you could review and collaborate on the mailing list, or dire= ct to the author. Looking forward to your feedback. > > Many thanks to Raymond for his comments on initial version. And thank you= in advance for your time, > > Regards, > > Yuqun(Sam) Cao This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From raymond.key@hotmail.com Sat Apr 23 01:10:41 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82C32E0693 for ; Sat, 23 Apr 2011 01:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeNKG0Ec3Y1z for ; Sat, 23 Apr 2011 01:10:39 -0700 (PDT) Received: from snt0-omc2-s23.snt0.hotmail.com (snt0-omc2-s23.snt0.hotmail.com [65.55.90.98]) by ietfc.amsl.com (Postfix) with ESMTP id 7C418E0690 for ; Sat, 23 Apr 2011 01:10:39 -0700 (PDT) Received: from SNT123-W53 ([65.55.90.72]) by snt0-omc2-s23.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 23 Apr 2011 01:10:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_24e967e8-ddb0-4178-a561-715e3ea3b02f_" X-Originating-IP: [122.107.153.185] From: Raymond Key Sender: To: , Subject: RE: I-D:Extension to BGP-VPLS for E-Tree Date: Sat, 23 Apr 2011 18:40:38 +1030 Importance: Normal In-Reply-To: References: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom>, MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2011 08:10:39.0300 (UTC) FILETIME=[EEA97040:01CC018D] Cc: l2vpn@ietf.org, yortion@hotmail.com, chenxb@ruijie.com.cn X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 08:10:41 -0000 --_24e967e8-ddb0-4178-a561-715e3ea3b02f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A comment on Figure 2 under Section 4. Reference Model (extracted below) =20 |<----------E-Tree------------>| | | V V +---------+ +---------+ | PE1 | | PE2 | /Leaf endpoint +---+ | +---+ | | +---+ | /\ +---+ |CE1+-------AC1-+--+ V | | | | V +--+-|--- --AC3----+CE3| +---+ (Root AC)| | S +--+---PW12---+--+ S | | | |(Leaf AC) +---+ +---+ | | I | | | | I | | | | +---+ |CE2+----AC2----+--+ | | | | +--+-|------AC4----+CE4| +---+ (Leaf AC)| +-+-+ | | +-+-+ | \/ (Leaf AC) +---+ +---+-+---+ +----+----+ ^ | | | | | |PW13-2 |PW23 | | | | PW13-1| | +----+----+ /Root endpoint | | | | +-+-+ | /\ +---+ | | | | | v +--+-|--------AC5-+CE5| | | +--------------+--+ s | | | |(Root AC)+---+ | | | | I | | | | +---+ | +----------------+ | +--+-|------AC6---+CE6| | | +---+ | \/ (Root AC)+---+ | | PE3 | | +---------+ | ^ | <-----------E-Tree---------->| =20 =20 As PE3 has Root ACs only=2C communication between an AC on PE1 and an AC on= PE3 is always allowed. This scenario seems not really need extension to c= urrent VPLS. =20 IMO it may be better if you add a Leaf AC (called it AC7) on PE3 and explai= n how your proposed solution prohibits communication between AC2 (Leaf AC o= n PE1) and AC7 (Leaf AC on PE3).=20 =20 Regards=2C Raymond Key=20 =20 =20 > From: josh.rogers@twcable.com > To: yuqun.cao@gmail.com > Date: Fri=2C 22 Apr 2011 16:32:27 -0400 > Subject: Re: I-D:Extension to BGP-VPLS for E-Tree > CC: l2vpn@ietf.org=3B yortion@hotmail.com=3B chenxb@ruijie.com.cn >=20 > Sam=2C >=20 > Thanks so much for your work on this draft. Some points below: >=20 >=20 > + 3.2 - Maybe you can rephrase this? I'm having trouble following it. 3.1= mentions a method that uses a 'tag' for each frame that denotes it is sour= ced from a leaf=2C and 3.2 (in contrast) uses a different method. If I unde= rstand correctly=2C you want the router to be aware of what the endpoints a= re and decide whether to forward to other PE's/AC's=2C rather than send it= =2C and decide after it arrives (as in 3.1). An alternate way of phrasing t= his that you may consider is: >=20 >=20 > 3. Terminology >=20 > >=20 > 2. The decision to forward a frame to another AC or across a PW is based = on foreknowledge of the local AC type and the remote AC type. If a frame co= mes from a local Leaf-AC=2C then it will not forward to any other local Lea= f-AC's=2C and will only forward across PW(s) to a PE which has a Root-AC. I= n this way=2C we restrict the communication between Leafs by building a par= tial mesh of PW's=2C intentionally excluding PW's between Leaf-AC's. Additi= onal PWs will need to be created to/from PE's that contain both Root and Le= af ACs. >=20 > The purposed solution in this document prefers to the second. Two terms a= re introduced=2C >=20 > o Root-endpoint. One endpoint which connects only Root-ACs=2C one or > more Root-ACs. >=20 > o Leaf-endpoint. One endpoint which connects only Leaf-ACs=2C one or > more Leaf-ACs. >=20 > There is no endpoint which connects both Root-ACs and Leaf-ACs in the > second solution=2C however a PE may have one of each endpoint configured = in the same vpls instance. >=20 > + Is 'endpoint' defined somewhere else? I can gather (from figure 2) that= you mean a pseudowire endpoint=2C but I'm not sure that is very clear here= . >=20 > Regarding figure 2=2C I at first thought there should only be one PW betw= een PE1 and PE3=2C and there should be two PW's between PE1 (since both AC1= and AC2 can/should talk to both AC5 and AC6) In fact=2C I believe with the= topology drawn=2C there should be three PW's total=2C however PE1 should h= ave two VE-ID's=2C and PW's terminating to each=2C rather than one VE-ID's = terminating two PW's as the other two PE's=2C which is what allows unique f= orwarding decisions based on the source VE-ID type=2C root or leaf). >=20 > After looking through it a second time=2C I realized that your intention = is to terminate PW per 'endpoint' (this goes back to the earlier comment ab= out whether this is already defined somewhere) on each PE=2C almost segment= ing the PE into behaving as though it was two PE's (one for the root AC's a= nd one for the leaf AC's) participating in the instance. While I believe th= at the additional PW may be unnecessary in this particular example=2C I bel= ieve your approach of using one 'endpoint' per AC type should scale with an= y scenario. It may be a good idea to try and represent the 'endpoints' in f= igure 2=2C maybe in place of the VSI box=2C place two endpoint boxes on PE1= =2C and one box on each of the other PE's? Put an R in the root endpoints a= nd L in the leaf ones=2C like this: >=20 > |<-----------E-Tree------------>| > | | > V V > +----------+ +---------+ > Root endpoint-- PE1 | | PE2 | /Leaf endpoint > +---+ |\ +---+ | | +---+ | /\ +---+ > |CE1+-------AC1-+--+ R +---|---PW12---+--+ +--+-|--- --AC3----+CE3| > +---+ (Root AC)| +---+-+ | | | V | | | |(Leaf AC) +---+ > | | | | | S | | | | > +---+ | +---+ | | | | I | | | | +---+ > |CE2+----AC2----+--+ L | | | | | +--+-|------AC4----+CE4| > +---+ (Leaf AC)| /++--+ | | | +-+-+ | \/ (Leaf AC) +---+ > /---|----|-+ +----+----+ > Leaf endpoint +^ | | | > | | |PW13-2 |PW23 > | | | | > PW13-1| | +----+----+ /Root endpoint > | | | | +-+-+ | /\ +---+ > | | | | | V +--+-|--------AC5-+CE5| > | | +-----------+--+ S | | | |(Root AC)+---+ > | | | | I | | | | +---+ > | +----------------+ | +--+-|------AC6---+CE6| > | | +---+ | \/ (Root AC)+---+ > | | PE3 | > | +---------+ > | ^ > | <-----------E-Tree---------->| >=20 > There is a small typo in 5.3=2C I believe Foex should be For. >=20 > Is 5.7 a duplicate of 5.6? >=20 > Regarding signaling=2C under the existing standards (no defined 'endpoint= s')=2C we use opposing target communities (one for root sites=2C and one fo= r leaf sites) successfully today to accomplish ETREE services. In the topol= ogy outlined in figure 2=2C we'd configure like this: >=20 > PE export import Add'l knobs > PE1 target:123:1 target:123:2 (core-facing) > PE2 target:123:2 target:123:1 (No local-switching) > PE3 target:123:1 target:123:2 >=20 > The two primary problems that we face with this method are: > 1) Root to root communication is not possible. Root-Leaf and Leaf-Root ar= e the only possible combinations. > 2) the 'core facing' knob available on the Juniper platform will cause AC= 2 to communicate with AC1=2C but NOT communicate with any other AC's=2C inc= luding AC5 and AC6. >=20 > Both of these problems break the ETREE requirements draft Raymond worked = on earlier=2C and both are addressed with the draft you are working on now.= I look forward to seeing section 5.7 completed/extended. >=20 >=20 > To recap=2C the primary problem we need to solve with this topology is 1)= AC3 and AC4 cannot be allowed to communicate (no local switching)=2C and 2= ) AC2 cannot be allowed to communicate with AC3 and AC4 and vice versa. I b= elieve what you are trying to convey is that PE1 will forward traffic from = AC2 to PE3=2C but not PE2=2C and PE2 will forward to PE3 but not PE2=2C whi= le still allowing AC1 to forward to PE2. >=20 > Sam=2C this is a very good start=2C and I look forward to seeing it throu= gh. Really appreciate your efforts here=2C as this is a very relevant draft= . Please let me know if I can help. >=20 > -Josh >=20 >=20 >=20 >=20 > On Apr 15=2C 2011=2C at 9:25 AM=2C Sam Cao wrote: >=20 > > Hi L2VPN working group=2C > > > > I have just updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf= .org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an appr= oach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtua= l Private LAN Service using BGP for auto-discovery and signaling [RFC4761]= =2C and I believe that these solution concepts can be applied to both LDP-V= PLS and BGP-VPLS=2C but the implementation may be a little different. > > > > Grateful if you could review and collaborate on the mailing list=2C or = direct to the author. Looking forward to your feedback. > > > > Many thanks to Raymond for his comments on initial version. And thank y= ou in advance for your time=2C > > > > Regards=2C > > > > Yuqun(Sam) Cao >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information=2C which is privileged=2C confidential=2C or subject to= copyright belonging to Time Warner Cable. This E-mail is intended solely f= or the use of the individual or entity to which it is addressed. If you are= not the intended recipient of this E-mail=2C you are hereby notified that = any dissemination=2C distribution=2C copying=2C or action taken in relation= to the contents of and attachments to this E-mail is strictly prohibited a= nd may be unlawful. If you have received this E-mail in error=2C please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. = --_24e967e8-ddb0-4178-a561-715e3ea3b02f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A comment on =3BFigure 2 under Section 4. Reference Model (extracted be= low)
 =3B
 =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B |<=3B----------E-Tree------------>=3B|
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B | =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= |
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= V =3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B V
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B +---------+ =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B +---------+
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B | =3B =3B PE1 =3B =3B |&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B |&nbs= p=3B =3B PE2 =3B =3B | =3B =3B =3B /Leaf endpoint =3B =3B +---+ =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B | =3B +---+ =3B | =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B | =3B +---+ = =3B | =3B /\ =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B +---+
 =3B =3B |CE1+-------AC1-+--+ V |&nb= sp=3B | =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B | =3B | V +--+-|--- --AC3----+CE3|
 =3B =3B +---+ = =3B (Root AC)| =3B | S +--+---PW12---+--+ S | =3B | | =3B |(Lea= f AC) +---+
 =3B =3B +---+ =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B | =3B | I | =3B | = =3B =3B =3B =3B =3B =3B =3B =3B =3B | = =3B | I | =3B | | =3B | =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B +---+
 =3B =3B |CE2+----AC2----+--+=  =3B =3B | =3B | =3B =3B =3B =3B =3B = =3B =3B =3B =3B | =3B | =3B =3B +--+-|------AC4----= +CE4|
 =3B =3B +---+ =3B (Leaf AC)| =3B +-+-+ =3B |&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B |&n= bsp=3B +-+-+ =3B | =3B \/ (Leaf AC) +---+
 =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B +---+-+---+ =3B = =3B =3B =3B =3B =3B =3B =3B =3B +----+----+
=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B ^&nbs= p=3B =3B | | =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B |
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B | =3B =3B | |PW13-2 =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B |PW23
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B | =3B&= nbsp=3B | | =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B |
 =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B PW13-1| |&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B +----+----+ =3B =3B =3B /Root endp= oint
 =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B | =3B =3B | | =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B | =3B +-+-+ = =3B | =3B /\ =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B +---+
 =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B | =3B =3B | | =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B |&nb= sp=3B | v +--+-|--------AC5-+CE5|
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B | =3B =3B | +--------------+--+ s = | =3B | | =3B |(Root AC)+---+
 =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B | =3B =3B | =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B | =3B | I | =3B | | =3B | =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B +---+
 =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B | =3B = =3B +----------------+ =3B | =3B =3B +--+-|------AC6---+CE6| =3B =3B =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B |&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= | =3B +---+ =3B | =3B \/ (Root AC)+---+
 =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B | =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B | =3B =3B = PE3 =3B =3B |
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B | =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B +---------+
 =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B | =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B ^
 =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B | <=3B-----------E-Tree----= ------>=3B|
 =3B
 =3B
As PE3 has Root ACs only=2C communication =3Bbetween an AC on PE1 and a= n AC on PE3 is always allowed. =3B This scenario =3Bseems not reall= y need extension to current VPLS.
 =3B
IMO it may =3Bbe better if =3Byou add a Leaf AC =3B(called it A= C7) on PE3 and explain how your proposed solution prohibits communication b= etween AC2 (Leaf AC on PE1) and AC7 (Leaf AC on PE3). =3B
 =3B
Regards=2C
Raymond Key =3B
 =3B
 =3B
>=3B From: josh.rogers@twcable.com
>=3B To: yuqun.cao@gmail.com
&= gt=3B Date: Fri=2C 22 Apr 2011 16:32:27 -0400
>=3B Subject: Re: I-D:Ex= tension to BGP-VPLS for E-Tree
>=3B CC: l2vpn@ietf.org=3B yortion@hotm= ail.com=3B chenxb@ruijie.com.cn
>=3B
>=3B Sam=2C
>=3B
&= gt=3B Thanks so much for your work on this draft. Some points below:
>= =3B
>=3B
>=3B + 3.2 - Maybe you can rephrase this? I'm having t= rouble following it. 3.1 mentions a method that uses a 'tag' for each frame= that denotes it is sourced from a leaf=2C and 3.2 (in contrast) uses a dif= ferent method. If I understand correctly=2C you want the router to be aware= of what the endpoints are and decide whether to forward to other PE's/AC's= =2C rather than send it=2C and decide after it arrives (as in 3.1). An alte= rnate way of phrasing this that you may consider is:
>=3B
>=3B <= BR>>=3B 3. Terminology
>=3B
>=3B <=3Bsnip>=3B
>=3B >=3B 2. The decision to forward a frame to another AC or across a PW is= based on foreknowledge of the local AC type and the remote AC type. If a f= rame comes from a local Leaf-AC=2C then it will not forward to any other lo= cal Leaf-AC's=2C and will only forward across PW(s) to a PE which has a Roo= t-AC. In this way=2C we restrict the communication between Leafs by buildin= g a partial mesh of PW's=2C intentionally excluding PW's between Leaf-AC's.= Additional PWs will need to be created to/from PE's that contain both Root= and Leaf ACs.
>=3B
>=3B The purposed solution in this document = prefers to the second. Two terms are introduced=2C
>=3B
>=3B o R= oot-endpoint. One endpoint which connects only Root-ACs=2C one or
>=3B= more Root-ACs.
>=3B
>=3B o Leaf-endpoint. One endpoint which co= nnects only Leaf-ACs=2C one or
>=3B more Leaf-ACs.
>=3B
>= =3B There is no endpoint which connects both Root-ACs and Leaf-ACs in the>=3B second solution=2C however a PE may have one of each endpoint conf= igured in the same vpls instance.
>=3B
>=3B + Is 'endpoint' defi= ned somewhere else? I can gather (from figure 2) that you mean a pseudowire= endpoint=2C but I'm not sure that is very clear here.
>=3B
>=3B= Regarding figure 2=2C I at first thought there should only be one PW betwe= en PE1 and PE3=2C and there should be two PW's between PE1 (since both AC1 = and AC2 can/should talk to both AC5 and AC6) In fact=2C I believe with the = topology drawn=2C there should be three PW's total=2C however PE1 should ha= ve two VE-ID's=2C and PW's terminating to each=2C rather than one VE-ID's t= erminating two PW's as the other two PE's=2C which is what allows unique fo= rwarding decisions based on the source VE-ID type=2C root or leaf).
>= =3B
>=3B After looking through it a second time=2C I realized that yo= ur intention is to terminate PW per 'endpoint' (this goes back to the earli= er comment about whether this is already defined somewhere) on each PE=2C a= lmost segmenting the PE into behaving as though it was two PE's (one for th= e root AC's and one for the leaf AC's) participating in the instance. While= I believe that the additional PW may be unnecessary in this particular exa= mple=2C I believe your approach of using one 'endpoint' per AC type should = scale with any scenario. It may be a good idea to try and represent the 'en= dpoints' in figure 2=2C maybe in place of the VSI box=2C place two endpoint= boxes on PE1=2C and one box on each of the other PE's? Put an R in the roo= t endpoints and L in the leaf ones=2C like this:
>=3B
>=3B |<= =3B-----------E-Tree------------>=3B|
>=3B | |
>=3B V V
>= =3B +----------+ +---------+
>=3B Root endpoint-- PE1 | | PE2 | /Leaf = endpoint
>=3B +---+ |\ +---+ | | +---+ | /\ +---+
>=3B |CE1+-----= --AC1-+--+ R +---|---PW12---+--+ +--+-|--- --AC3----+CE3|
>=3B +---+ (= Root AC)| +---+-+ | | | V | | | |(Leaf AC) +---+
>=3B | | | | | S | | = | |
>=3B +---+ | +---+ | | | | I | | | | +---+
>=3B |CE2+----AC2-= ---+--+ L | | | | | +--+-|------AC4----+CE4|
>=3B +---+ (Leaf AC)| /++= --+ | | | +-+-+ | \/ (Leaf AC) +---+
>=3B /---|----|-+ +----+----+
= >=3B Leaf endpoint +^ | | |
>=3B | | |PW13-2 |PW23
>=3B | | | |=
>=3B PW13-1| | +----+----+ /Root endpoint
>=3B | | | | +-+-+ | /= \ +---+
>=3B | | | | | V +--+-|--------AC5-+CE5|
>=3B | | +------= -----+--+ S | | | |(Root AC)+---+
>=3B | | | | I | | | | +---+
>= =3B | +----------------+ | +--+-|------AC6---+CE6|
>=3B | | +---+ | \/= (Root AC)+---+
>=3B | | PE3 |
>=3B | +---------+
>=3B | ^>=3B | <=3B-----------E-Tree---------->=3B|
>=3B
>=3B Th= ere is a small typo in 5.3=2C I believe Foex should be For.
>=3B
&= gt=3B Is 5.7 a duplicate of 5.6?
>=3B
>=3B Regarding signaling= =2C under the existing standards (no defined 'endpoints')=2C we use opposin= g target communities (one for root sites=2C and one for leaf sites) success= fully today to accomplish ETREE services. In the topology outlined in figur= e 2=2C we'd configure like this:
>=3B
>=3B PE export import Add'= l knobs
>=3B PE1 target:123:1 target:123:2 (core-facing)
>=3B PE2= target:123:2 target:123:1 (No local-switching)
>=3B PE3 target:123:1 = target:123:2
>=3B
>=3B The two primary problems that we face wit= h this method are:
>=3B 1) Root to root communication is not possible.= Root-Leaf and Leaf-Root are the only possible combinations.
>=3B 2) t= he 'core facing' knob available on the Juniper platform will cause AC2 to c= ommunicate with AC1=2C but NOT communicate with any other AC's=2C including= AC5 and AC6.
>=3B
>=3B Both of these problems break the ETREE r= equirements draft Raymond worked on earlier=2C and both are addressed with = the draft you are working on now. I look forward to seeing section 5.7 comp= leted/extended.
>=3B
>=3B
>=3B To recap=2C the primary pro= blem we need to solve with this topology is 1) AC3 and AC4 cannot be allowe= d to communicate (no local switching)=2C and 2) AC2 cannot be allowed to co= mmunicate with AC3 and AC4 and vice versa. I believe what you are trying to= convey is that PE1 will forward traffic from AC2 to PE3=2C but not PE2=2C = and PE2 will forward to PE3 but not PE2=2C while still allowing AC1 to forw= ard to PE2.
>=3B
>=3B Sam=2C this is a very good start=2C and I = look forward to seeing it through. Really appreciate your efforts here=2C a= s this is a very relevant draft. Please let me know if I can help.
>= =3B
>=3B -Josh
>=3B
>=3B
>=3B
>=3B
>=3B = On Apr 15=2C 2011=2C at 9:25 AM=2C Sam Cao wrote:
>=3B
>=3B >= =3B Hi L2VPN working group=2C
>=3B >=3B
>=3B >=3B I have just= updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf.org/id/draft-c= ao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an approach to support= Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN S= ervice using BGP for auto-discovery and signaling [RFC4761]=2C and I believ= e that these solution concepts can be applied to both LDP-VPLS and BGP-VPLS= =2C but the implementation may be a little different.
>=3B >=3B
&= gt=3B >=3B Grateful if you could review and collaborate on the mailing li= st=2C or direct to the author. Looking forward to your feedback.
>=3B = >=3B
>=3B >=3B Many thanks to Raymond for his comments on initial = version. And thank you in advance for your time=2C
>=3B >=3B
>= =3B >=3B Regards=2C
>=3B >=3B
>=3B >=3B Yuqun(Sam) Cao
&= gt=3B
>=3B
>=3B This E-mail and any of its attachments may cont= ain Time Warner Cable proprietary information=2C which is privileged=2C con= fidential=2C or subject to copyright belonging to Time Warner Cable. This E= -mail is intended solely for the use of the individual or entity to which i= t is addressed. If you are not the intended recipient of this E-mail=2C you= are hereby notified that any dissemination=2C distribution=2C copying=2C o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-m= ail in error=2C please notify the sender immediately and permanently delete= the original and any copy of this E-mail and any printout.
= = --_24e967e8-ddb0-4178-a561-715e3ea3b02f_-- From josh.rogers@twcable.com Sat Apr 23 08:04:54 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4A98CE0713 for ; Sat, 23 Apr 2011 08:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq1EMawV66ar for ; Sat, 23 Apr 2011 08:04:53 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfc.amsl.com (Postfix) with ESMTP id F11ADE069D for ; Sat, 23 Apr 2011 08:04:52 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.64,259,1301889600"; d="scan'208";a="217815181" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Apr 2011 11:32:40 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Sat, 23 Apr 2011 11:04:52 -0400 From: "Rogers, Josh" To: Raymond Key Date: Sat, 23 Apr 2011 11:04:50 -0400 Subject: Re: I-D:Extension to BGP-VPLS for E-Tree Thread-Topic: I-D:Extension to BGP-VPLS for E-Tree Thread-Index: AcwBx8viA/KvPB0ZQNmBJtI5bGOXqA== Message-ID: <834AC633-47CE-4729-9D05-DCB5AD4275E6@twcable.com> References: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , "yortion@hotmail.com" , "yuqun.cao@gmail.com" , "chenxb@ruijie.com.cn" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 15:04:54 -0000 Yes, I agree. A leaf and root PE to another leaf and root PE would have cleared this up f= or me as well. Either include a 7th AC as Ray recommended, or add a fourth= PE configured just like PE1. Also, regarding the target communities... I've often thought that if I had= the ability to import more than one community, it would address the curren= t inability to have root-root communication that I experience today. It wo= uld not, however, address a root/leaf to root/leaf communication. -Josh On Apr 23, 2011, at 3:10 AM, Raymond Key wrote: A comment on Figure 2 under Section 4. Reference Model (extracted below) |<----------E-Tree------------>| | | V V +---------+ +---------+ | PE1 | | PE2 | /Leaf endpoint +---+ | +---+ | | +---+ | /\ +---+ |CE1+-------AC1-+--+ V | | | | V +--+-|--- --AC3----+CE3| +---+ (Root AC)| | S +--+---PW12---+--+ S | | | |(Leaf AC) +---+ +---+ | | I | | | | I | | | | +---+ |CE2+----AC2----+--+ | | | | +--+-|------AC4----+CE4| +---+ (Leaf AC)| +-+-+ | | +-+-+ | \/ (Leaf AC) +---+ +---+-+---+ +----+----+ ^ | | | | | |PW13-2 |PW23 | | | | PW13-1| | +----+----+ /Root endpoint | | | | +-+-+ | /\ +---+ | | | | | v +--+-|--------AC5-+CE5| | | +--------------+--+ s | | | |(Root AC)+---+ | | | | I | | | | +---+ | +----------------+ | +--+-|------AC6---+CE6| | | +---+ | \/ (Root AC)+---+ | | PE3 | | +---------+ | ^ | <-----------E-Tree---------->| As PE3 has Root ACs only, communication between an AC on PE1 and an AC on P= E3 is always allowed. This scenario seems not really need extension to cur= rent VPLS. IMO it may be better if you add a Leaf AC (called it AC7) on PE3 and explai= n how your proposed solution prohibits communication between AC2 (Leaf AC o= n PE1) and AC7 (Leaf AC on PE3). Regards, Raymond Key > From: josh.rogers@twcable.com > To: yuqun.cao@gmail.com > Date: Fri, 22 Apr 2011 16:32:27 -0400 > Subject: Re: I-D:Extension to BGP-VPLS for E-Tree > CC: l2vpn@ietf.org; yortion@hotmail.com; chenxb@ruijie.com.cn > > Sam, > > Thanks so much for your work on this draft. Some points below: > > > + 3.2 - Maybe you can rephrase this? I'm having trouble following it. 3.1= mentions a method that uses a 'tag' for each frame that denotes it is sour= ced from a leaf, and 3.2 (in contrast) uses a different method. If I unders= tand correctly, you want the router to be aware of what the endpoints are a= nd decide whether to forward to other PE's/AC's, rather than send it, and d= ecide after it arrives (as in 3.1). An alternate way of phrasing this that = you may consider is: > > > 3. Terminology > > > > 2. The decision to forward a frame to another AC or across a PW is based = on foreknowledge of the local AC type and the remote AC type. If a frame co= mes from a local Leaf-AC, then it will not forward to any other local Leaf-= AC's, and will only forward across PW(s) to a PE which has a Root-AC. In th= is way, we restrict the communication between Leafs by building a partial m= esh of PW's, intentionally excluding PW's between Leaf-AC's. Additional PWs= will need to be created to/from PE's that contain both Root and Leaf ACs. > > The purposed solution in this document prefers to the second. Two terms a= re introduced, > > o Root-endpoint. One endpoint which connects only Root-ACs, one or > more Root-ACs. > > o Leaf-endpoint. One endpoint which connects only Leaf-ACs, one or > more Leaf-ACs. > > There is no endpoint which connects both Root-ACs and Leaf-ACs in the > second solution, however a PE may have one of each endpoint configured in= the same vpls instance. > > + Is 'endpoint' defined somewhere else? I can gather (from figure 2) that= you mean a pseudowire endpoint, but I'm not sure that is very clear here. > > Regarding figure 2, I at first thought there should only be one PW betwee= n PE1 and PE3, and there should be two PW's between PE1 (since both AC1 and= AC2 can/should talk to both AC5 and AC6) In fact, I believe with the topol= ogy drawn, there should be three PW's total, however PE1 should have two VE= -ID's, and PW's terminating to each, rather than one VE-ID's terminating tw= o PW's as the other two PE's, which is what allows unique forwarding decisi= ons based on the source VE-ID type, root or leaf). > > After looking through it a second time, I realized that your intention is= to terminate PW per 'endpoint' (this goes back to the earlier comment abou= t whether this is already defined somewhere) on each PE, almost segmenting = the PE into behaving as though it was two PE's (one for the root AC's and o= ne for the leaf AC's) participating in the instance. While I believe that t= he additional PW may be unnecessary in this particular example, I believe y= our approach of using one 'endpoint' per AC type should scale with any scen= ario. It may be a good idea to try and represent the 'endpoints' in figure = 2, maybe in place of the VSI box, place two endpoint boxes on PE1, and one = box on each of the other PE's? Put an R in the root endpoints and L in the = leaf ones, like this: > > |<-----------E-Tree------------>| > | | > V V > +----------+ +---------+ > Root endpoint-- PE1 | | PE2 | /Leaf endpoint > +---+ |\ +---+ | | +---+ | /\ +---+ > |CE1+-------AC1-+--+ R +---|---PW12---+--+ +--+-|--- --AC3----+CE3| > +---+ (Root AC)| +---+-+ | | | V | | | |(Leaf AC) +---+ > | | | | | S | | | | > +---+ | +---+ | | | | I | | | | +---+ > |CE2+----AC2----+--+ L | | | | | +--+-|------AC4----+CE4| > +---+ (Leaf AC)| /++--+ | | | +-+-+ | \/ (Leaf AC) +---+ > /---|----|-+ +----+----+ > Leaf endpoint +^ | | | > | | |PW13-2 |PW23 > | | | | > PW13-1| | +----+----+ /Root endpoint > | | | | +-+-+ | /\ +---+ > | | | | | V +--+-|--------AC5-+CE5| > | | +-----------+--+ S | | | |(Root AC)+---+ > | | | | I | | | | +---+ > | +----------------+ | +--+-|------AC6---+CE6| > | | +---+ | \/ (Root AC)+---+ > | | PE3 | > | +---------+ > | ^ > | <-----------E-Tree---------->| > > There is a small typo in 5.3, I believe Foex should be For. > > Is 5.7 a duplicate of 5.6? > > Regarding signaling, under the existing standards (no defined 'endpoints'= ), we use opposing target communities (one for root sites, and one for leaf= sites) successfully today to accomplish ETREE services. In the topology ou= tlined in figure 2, we'd configure like this: > > PE export import Add'l knobs > PE1 target:123:1 target:123:2 (core-facing) > PE2 target:123:2 target:123:1 (No local-switching) > PE3 target:123:1 target:123:2 > > The two primary problems that we face with this method are: > 1) Root to root communication is not possible. Root-Leaf and Leaf-Root ar= e the only possible combinations. > 2) the 'core facing' knob available on the Juniper platform will cause AC= 2 to communicate with AC1, but NOT communicate with any other AC's, includi= ng AC5 and AC6. > > Both of these problems break the ETREE requirements draft Raymond worked = on earlier, and both are addressed with the draft you are working on now. I= look forward to seeing section 5.7 completed/extended. > > > To recap, the primary problem we need to solve with this topology is 1) A= C3 and AC4 cannot be allowed to communicate (no local switching), and 2) AC= 2 cannot be allowed to communicate with AC3 and AC4 and vice versa. I belie= ve what you are trying to convey is that PE1 will forward traffic from AC2 = to PE3, but not PE2, and PE2 will forward to PE3 but not PE2, while still a= llowing AC1 to forward to PE2. > > Sam, this is a very good start, and I look forward to seeing it through. = Really appreciate your efforts here, as this is a very relevant draft. Plea= se let me know if I can help. > > -Josh > > > > > On Apr 15, 2011, at 9:25 AM, Sam Cao wrote: > > > Hi L2VPN working group, > > > > I have just updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf= .org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an appr= oach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtua= l Private LAN Service using BGP for auto-discovery and signaling [RFC4761],= and I believe that these solution concepts can be applied to both LDP-VPLS= and BGP-VPLS, but the implementation may be a little different. > > > > Grateful if you could review and collaborate on the mailing list, or di= rect to the author. Looking forward to your feedback. > > > > Many thanks to Raymond for his comments on initial version. And thank y= ou in advance for your time, > > > > Regards, > > > > Yuqun(Sam) Cao > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. From yuqun.cao@gmail.com Sat Apr 23 16:21:44 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8EEDE0613 for ; Sat, 23 Apr 2011 16:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.263 X-Spam-Level: * X-Spam-Status: No, score=1.263 tagged_above=-999 required=5 tests=[AWL=-3.372, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY-y2pBm2axc for ; Sat, 23 Apr 2011 16:21:42 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0F48AE0611 for ; Sat, 23 Apr 2011 16:21:41 -0700 (PDT) Received: by pwi5 with SMTP id 5so1055137pwi.31 for ; Sat, 23 Apr 2011 16:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:in-reply-to:x-mimeole; bh=me9RuUDgFgF36CeUrX1Jlt3QOnRh6Z4nOhZdBGQqpR0=; b=Ae2fAgrHYBqCki4/isXABN0qSav+u4Mw6edFXB6TuiL/1PrD5d0AbENY4WAlov77P8 YxGIXBLQnnncv1ofynpqVXoXFYVUU8NSiCYkaT45vB1I774eBWag4zXGHVIAI52Yq/l2 jX+s2LLqo8eKJa6Oy8ne25KDjGJ+hen04XokY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; b=izpFnvDkGWgXvfD4lL2gIqB5TtjEoFckWYf2n5FPSb83sPq/APuqzcBg58KZMa0QoK n+EC9t7LDlxAOPqSjDnp0y/yg69bQTybbJRSMIrmYrTmZ6a7UosQVHDPSQL0Qc+ufHE1 kqh/OfHHmN4n1dotBtrl1MvO92xXPzEIfjkHk= Received: by 10.68.65.233 with SMTP id a9mr3874842pbt.187.1303600901358; Sat, 23 Apr 2011 16:21:41 -0700 (PDT) Received: from vvcom ([175.42.34.10]) by mx.google.com with ESMTPS id m6sm697144pbl.85.2011.04.23.16.21.36 (version=SSLv3 cipher=OTHER); Sat, 23 Apr 2011 16:21:39 -0700 (PDT) From: "Sam Cao" To: "'Rogers, Josh'" , "'Raymond Key'" References: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom>, <834AC633-47CE-4729-9D05-DCB5AD4275E6@twcable.com> Subject: =?gb2312?B?tPC4tDogSS1EOkV4dGVuc2lvbiB0byBCR1AtVlBMUyBmb3IgRS1UcmVl?= Date: Sun, 24 Apr 2011 07:21:49 +0800 Message-ID: <6E9666F8A6954016B8D7DFC43661F973@vvcom> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwBx8viA/KvPB0ZQNmBJtI5bGOXqAAQ5qIg In-Reply-To: <834AC633-47CE-4729-9D05-DCB5AD4275E6@twcable.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: l2vpn@ietf.org, yortion@hotmail.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 23:21:44 -0000 Hi Josh, Thank you very much for your comments. Yes, we can import/export route targets, one for Root endpoint and one for Leaf endpoint (Refer to RFC = 4761 and 6074), but for communication between 2 root-leaf-mixed PEs, maybe we need some changes, so maybe it is not good solution. That is why are = working on new E-Tree drafts. Luca shared his expert opinion with me through = Email before. Thank you very much for your time and your help. I will review your = points case by case, and then update the draft. Sam -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C223=C8=D5 23:05 =CA=D5=BC=FE=C8=CB: Raymond Key =B3=AD=CB=CD: yuqun.cao@gmail.com; l2vpn@ietf.org; yortion@hotmail.com; chenxb@ruijie.com.cn =D6=F7=CC=E2: Re: I-D:Extension to BGP-VPLS for E-Tree Yes, I agree. A leaf and root PE to another leaf and root PE would have cleared this = up for me as well. Either include a 7th AC as Ray recommended, or add a = fourth PE configured just like PE1. Also, regarding the target communities... I've often thought that if I = had the ability to import more than one community, it would address the = current inability to have root-root communication that I experience today. It = would not, however, address a root/leaf to root/leaf communication. -Josh On Apr 23, 2011, at 3:10 AM, Raymond Key wrote: A comment on Figure 2 under Section 4. Reference Model (extracted below) |<----------E-Tree------------>| | | V V +---------+ +---------+ | PE1 | | PE2 | /Leaf endpoint +---+ | +---+ | | +---+ | /\ +---+ |CE1+-------AC1-+--+ V | | | | V +--+-|--- --AC3----+CE3| +---+ (Root AC)| | S +--+---PW12---+--+ S | | | |(Leaf AC) +---+ +---+ | | I | | | | I | | | | +---+ |CE2+----AC2----+--+ | | | | +--+-|------AC4----+CE4| +---+ (Leaf AC)| +-+-+ | | +-+-+ | \/ (Leaf AC) +---+ +---+-+---+ +----+----+ ^ | | | | | |PW13-2 |PW23 | | | | PW13-1| | +----+----+ /Root endpoint | | | | +-+-+ | /\ +---+ | | | | | v +--+-|--------AC5-+CE5| | | +--------------+--+ s | | | |(Root AC)+---+ | | | | I | | | | +---+ | +----------------+ | +--+-|------AC6---+CE6| | | +---+ | \/ (Root AC)+---+ | | PE3 | | +---------+ | ^ | <-----------E-Tree---------->| As PE3 has Root ACs only, communication between an AC on PE1 and an AC = on PE3 is always allowed. This scenario seems not really need extension to current VPLS. IMO it may be better if you add a Leaf AC (called it AC7) on PE3 and = explain how your proposed solution prohibits communication between AC2 (Leaf AC = on PE1) and AC7 (Leaf AC on PE3). Regards, Raymond Key > From: josh.rogers@twcable.com > To: yuqun.cao@gmail.com > Date: Fri, 22 Apr 2011 16:32:27 -0400 > Subject: Re: I-D:Extension to BGP-VPLS for E-Tree > CC: l2vpn@ietf.org; yortion@hotmail.com; chenxb@ruijie.com.cn > > Sam, > > Thanks so much for your work on this draft. Some points below: > > > + 3.2 - Maybe you can rephrase this? I'm having trouble following it. = 3.1 mentions a method that uses a 'tag' for each frame that denotes it is sourced from a leaf, and 3.2 (in contrast) uses a different method. If I understand correctly, you want the router to be aware of what the = endpoints are and decide whether to forward to other PE's/AC's, rather than send = it, and decide after it arrives (as in 3.1). An alternate way of phrasing = this that you may consider is: > > > 3. Terminology > > > > 2. The decision to forward a frame to another AC or across a PW is = based on foreknowledge of the local AC type and the remote AC type. If a frame comes from a local Leaf-AC, then it will not forward to any other local Leaf-AC's, and will only forward across PW(s) to a PE which has a = Root-AC. In this way, we restrict the communication between Leafs by building a partial mesh of PW's, intentionally excluding PW's between Leaf-AC's. Additional PWs will need to be created to/from PE's that contain both = Root and Leaf ACs. > > The purposed solution in this document prefers to the second. Two = terms are introduced, > > o Root-endpoint. One endpoint which connects only Root-ACs, one or > more Root-ACs. > > o Leaf-endpoint. One endpoint which connects only Leaf-ACs, one or > more Leaf-ACs. > > There is no endpoint which connects both Root-ACs and Leaf-ACs in the > second solution, however a PE may have one of each endpoint configured = in the same vpls instance. > > + Is 'endpoint' defined somewhere else? I can gather (from figure 2) = that you mean a pseudowire endpoint, but I'm not sure that is very clear = here. > > Regarding figure 2, I at first thought there should only be one PW = between PE1 and PE3, and there should be two PW's between PE1 (since both AC1 = and AC2 can/should talk to both AC5 and AC6) In fact, I believe with the topology drawn, there should be three PW's total, however PE1 should = have two VE-ID's, and PW's terminating to each, rather than one VE-ID's terminating two PW's as the other two PE's, which is what allows unique forwarding decisions based on the source VE-ID type, root or leaf). > > After looking through it a second time, I realized that your intention = is to terminate PW per 'endpoint' (this goes back to the earlier comment = about whether this is already defined somewhere) on each PE, almost segmenting = the PE into behaving as though it was two PE's (one for the root AC's and = one for the leaf AC's) participating in the instance. While I believe that = the additional PW may be unnecessary in this particular example, I believe = your approach of using one 'endpoint' per AC type should scale with any = scenario. It may be a good idea to try and represent the 'endpoints' in figure 2, maybe in place of the VSI box, place two endpoint boxes on PE1, and one = box on each of the other PE's? Put an R in the root endpoints and L in the = leaf ones, like this: > > |<-----------E-Tree------------>| > | | > V V > +----------+ +---------+ > Root endpoint-- PE1 | | PE2 | /Leaf endpoint > +---+ |\ +---+ | | +---+ | /\ +---+ > |CE1+-------AC1-+--+ R +---|---PW12---+--+ +--+-|--- --AC3----+CE3| > +---+ (Root AC)| +---+-+ | | | V | | | |(Leaf AC) +---+ > | | | | | S | | | | > +---+ | +---+ | | | | I | | | | +---+ > |CE2+----AC2----+--+ L | | | | | +--+-|------AC4----+CE4| > +---+ (Leaf AC)| /++--+ | | | +-+-+ | \/ (Leaf AC) +---+ > /---|----|-+ +----+----+ > Leaf endpoint +^ | | | > | | |PW13-2 |PW23 > | | | | > PW13-1| | +----+----+ /Root endpoint > | | | | +-+-+ | /\ +---+ > | | | | | V +--+-|--------AC5-+CE5| > | | +-----------+--+ S | | | |(Root AC)+---+ > | | | | I | | | | +---+ > | +----------------+ | +--+-|------AC6---+CE6| > | | +---+ | \/ (Root AC)+---+ > | | PE3 | > | +---------+ > | ^ > | <-----------E-Tree---------->| > > There is a small typo in 5.3, I believe Foex should be For. > > Is 5.7 a duplicate of 5.6? > > Regarding signaling, under the existing standards (no defined 'endpoints'), we use opposing target communities (one for root sites, = and one for leaf sites) successfully today to accomplish ETREE services. In = the topology outlined in figure 2, we'd configure like this: > > PE export import Add'l knobs > PE1 target:123:1 target:123:2 (core-facing) > PE2 target:123:2 target:123:1 (No local-switching) > PE3 target:123:1 target:123:2 > > The two primary problems that we face with this method are: > 1) Root to root communication is not possible. Root-Leaf and Leaf-Root = are the only possible combinations. > 2) the 'core facing' knob available on the Juniper platform will cause = AC2 to communicate with AC1, but NOT communicate with any other AC's, = including AC5 and AC6. > > Both of these problems break the ETREE requirements draft Raymond = worked on earlier, and both are addressed with the draft you are working on = now. I look forward to seeing section 5.7 completed/extended. > > > To recap, the primary problem we need to solve with this topology is = 1) AC3 and AC4 cannot be allowed to communicate (no local switching), and = 2) AC2 cannot be allowed to communicate with AC3 and AC4 and vice versa. I believe what you are trying to convey is that PE1 will forward traffic = from AC2 to PE3, but not PE2, and PE2 will forward to PE3 but not PE2, while still allowing AC1 to forward to PE2. > > Sam, this is a very good start, and I look forward to seeing it = through. Really appreciate your efforts here, as this is a very relevant draft. Please let me know if I can help. > > -Josh > > > > > On Apr 15, 2011, at 9:25 AM, Sam Cao wrote: > > > Hi L2VPN working group, > > > > I have just updated "Extension to BGP-VPLS for E-Tree" = (http://www.ietf. org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service using BGP for auto-discovery and signaling [RFC4761], and I believe that these solution concepts can be applied to = both LDP-VPLS and BGP-VPLS, but the implementation may be a little different. > > > > Grateful if you could review and collaborate on the mailing list, or direct to the author. Looking forward to your feedback. > > > > Many thanks to Raymond for his comments on initial version. And = thank you in advance for your time, > > > > Regards, > > > > Yuqun(Sam) Cao > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended solely = for the use of the individual or entity to which it is addressed. If you are = not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of = this E-mail and any printout. From florin.balus@alcatel-lucent.com Mon Apr 25 10:26:28 2011 Return-Path: X-Original-To: l2vpn@ietfc.amsl.com Delivered-To: l2vpn@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F57CE06E1 for ; Mon, 25 Apr 2011 10:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g89WMOasXNNp for ; Mon, 25 Apr 2011 10:26:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id 02F2CE0699 for ; Mon, 25 Apr 2011 10:26:26 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3PHQDQv028055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2011 12:26:13 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3PHQCYP010960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 25 Apr 2011 12:26:13 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 25 Apr 2011 12:26:13 -0500 From: "Balus, Florin Stelian (Florin)" To: Xu Xiaohu , "l2vpn@ietf.org" Date: Mon, 25 Apr 2011 12:26:05 -0500 Subject: RE: Simplified multicast in IS-IS VPLS Thread-Topic: Simplified multicast in IS-IS VPLS Thread-Index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwAAK3jAAABQu2IABG4ZoMA== Message-ID: <2073A6C5467C99478898544C6EBA3F4602B9449F83@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <002301cbff00$44dabd60$ce903820$@com> In-Reply-To: <002301cbff00$44dabd60$ce903820$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:26:28 -0000 DQpIaSBYaWFvaHUsDQpTb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UuIEkgdG9vayBzb21l IHZhY2F0aW9uIGRheXMuDQoNClNlZSB0aGUgYW5zd2VycyB0byB5b3VyIHF1ZXN0aW9ucyBiZWxv dywgZm9jdXNpbmcgb24gdGhlIElFRUUgaW50ZXJvcCwgdGhlIGZvY3VzIHVwIHRvIG5vdyBpbiBM MlZQTiBXRy4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFh1IFhp YW9odSBbbWFpbHRvOnh1eGhAaHVhd2VpLmNvbV0NCj4gU2VudDogVHVlc2RheSwgQXByaWwgMTks IDIwMTEgNzoxMiBQTQ0KPiBUbzogQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBsMnZw bkBpZXRmLm9yZw0KPiBTdWJqZWN0OiByZTogU2ltcGxpZmllZCBtdWx0aWNhc3QgaW4gSVMtSVMg VlBMUw0KPiANCj4gSGkgRmxvcmluLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24u IFBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5lLg0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4gPiC3orz+yMs6IEJhbHVzLCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKQ0KPiBbbWFpbHRvOmZs b3Jpbi5iYWx1c0BhbGNhdGVsLWx1Y2VudC5jb21dDQo+ID4gt6LLzcqxvOQ6IDIwMTHE6jTUwjE5 yNUgMjM6NDENCj4gPiDK1bz+yMs6IFh1IFhpYW9odTsgbDJ2cG5AaWV0Zi5vcmcNCj4gPiDW98zi OiBSRTogU2ltcGxpZmllZCBtdWx0aWNhc3QgaW4gSVMtSVMgVlBMUw0KPiA+DQo+ID4gSGkgWGlh b2h1LA0KPiA+DQo+ID4gRHVyaW5nIHRoZSB3b3JraW5nIGdyb3VwIHNlc3Npb24gaW4gUHJhZ3Vl IHRoZXJlIHdhcyBmZWVkYmFjayBmcm9tDQo+IHRoZQ0KPiByb29tDQo+ID4gd2Ugc2hvdWxkIG5v dCBpbnRyb2R1Y2UgeWV0IGFub3RoZXIgc29sdXRpb24gaW4gdGhpcyBzcGFjZS4NCj4gPg0KPiA+ IElmIHRoaXMgaXMgaW5kZWVkIGEgcmVxdWlyZW1lbnQgd2Ugc2hvdWxkIGZvY3VzIG9uIGV4dGVu ZGluZyB0aGUNCj4gZXhpc3RpbmcNCj4gSVMtSVMNCj4gPiBiYXNlZCB0ZWNobm9sb2dpZXMgZGV2 ZWxvcGVkIGJ5IElFRUUgb3IgSUVURjogaS5lLiBJRUVFIDgwMi4xYXEvU1BCDQo+IG9yDQo+IElF VEYNCj4gPiBUUklMTC4NCj4gDQo+IENvdWxkIHlvdSBwbGVhc2UgZ2l2ZSB5b3VyIHJlYXNvbiB3 aHkgd2Ugc2hvdWxkIGZvY3VzIG9uIGV4dGVuZGluZyB0aGUNCj4gZXhpc3RpbmcgSVMtSVMgYmFz ZWQgdGVjaG5vbG9naWVzIGRldmVsb3BlZCBieSBJRUVFIG9yIElFVEY6IGkuZS4gSUVFRQ0KPiA4 MDIuMWFxL1NQQiBvciBJRVRGDQo+IFRSSUxMLCByYXRoZXIgdGhhbiBleHRlbmRpbmcgdGhlIGV4 aXN0aW5nIHByb3ZlbiBhbmQgZmFtaWxpYXIgVlBMUw0KPiB0ZWNobm9sb2d5IGEgbGl0dGxlIGJp dD8NCg0KW1tGQl1dIFRoaXMgZGlzY3Vzc2lvbiBpcyBub3QgYWJvdXQgZXh0ZW5kaW5nIElFRUUg c29sdXRpb25zIHZlcnN1cyBleHRlbmRpbmcgVlBMUy4gTm8gbmVlZCB0byBjaGFuZ2UgVlBMUyBk YXRhIHBsYW5lIHRvIGFjY29tbW9kYXRlIElFRUUgODAyLjFhcS9TUEI6IFNQQiB1c2VzIGVuY2Fw c3VsYXRpb25zIGxpa2UgUWluUS84MDIuMWFkIGFuZCBQQkIvODAyLjFhaCBhbHJlYWR5IHN1cHBv cnRlZCBieSBWUExTIChzZWUgTDJWUE4gY29tcHJlaGVuc2l2ZSB3b3JrIG9uIGludGVyb3AgaW4g ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWJyaWRnZS1pbnRlcm9wLCBkcmFmdC1pZXRmLWwydnBuLXBi Yi12cGxzLWludGVyb3AsIGRyYWZ0LWlldGYtbDJ2cG4tcGJiLXZwbHMtcGUtbW9kZWwpLiANCg0K VGhpcyBpcyBhYm91dCBjb21wYXJpbmcgdGhlIHdvcmsgdG8gYWNjb21tb2RhdGUgdGhlIElTLUlT IHByb3Bvc2FsIGluIHlvdXIgZHJhZnQgKGludm9sdmluZyBjaGFuZ2VzIHRvIHRoZSBWUExTIGNv bnRyb2wgcGxhbmUpIHZzIHJlLXVzaW5nIGV4aXN0aW5nIElTLUlTIHByb3Bvc2FscyBkZXZlbG9w ZWQgaW4gSUVFRS9JRVRGIHRvIHRoYXQgZXh0ZW50LiANCg0KPiANCj4gSSBhZ3JlZSB0aGF0IFRS SUxMIGFuZCBTUEIgaGF2ZSBtYW55IGNoYXJtaW5nIGNoYXJhY3RlcnMuIEhvd2V2ZXIsDQo+IElN SE8sDQo+IHRoZXJlIGlzIHN0aWxsIGEgbG9uZyB3YXkgdG8gZ28gZm9yIGJvdGggVFJJTEwgYW5k IFNQQiBiZWZvcmUgdGhleSBhcmUNCj4gY29tcGFyYWJsZSB0byBJUCBhbmQgVlBMUyBvbiB0aGUg YXNwZWN0IG9mIHRlY2hub2xvZ3kgc3RhYmlsaXR5IGFuZA0KPiBtYXR1cmF0aW9uLiBlLmcuLCBi cmVha2luZyA0MDk2IFZMQU5zIGxpbWl0LCBPQU0gdG9vbHMgZm9yIFRSSUxMLA0KPiBBZGRpbmcg VFRMIGFuZCBzaW1wbGlmeWluZyB0aGUgRUNNUCBhbGdvcml0aG0gZm9yIFNQQi4NCg0KW1tGQl1d IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBJRUVFIDgwMi4xYXEvU1BCIHdvcmsgaXMgYWxtb3N0 IGNvbXBsZXRlZCBhbmQgaXQgc2hvdWxkIGNsb3NlIHRoaXMgeWVhciBvciBlYXJseSBuZXh0IHll YXIuIEFsc28gdGhlcmUgd2FzIGEgbG90IG9mIGdvb2Qgd29yayBMMlZQTiBXRyBkaWQgaW4gdGhl IGxhc3QgNS02IHllYXJzIHRvIG1ha2Ugc3VyZSB3ZSBhcmUgaW4gc3luYyB3aXRoIElFRUUgc28g dGhhdCBhbGwgc2NhbGluZyBhc3BlY3RzICg0SyBWTEFOcywgTUFDIHNjYWxpbmcgZXRjKSBhbmQg T0FNIHRvb2xzZXRzICg4MDIuMWFnLCBZLjE3MzEpIGFyZSBpbmhlcml0ZWQgYmV0d2VlbiB0aGUg dHdvIHNwZWNpZmljYXRpb24gc2V0cy4gTmV3IGluaXRpYXRpdmVzIGxpa2UgSUVFRSA4MDIuMVFi cCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYXMgdGhleSBhcmUgZGV2ZWxvcGVkIGJ1dCBkZWZpbml0 ZWx5IGl0IHdpbGwgYmUgZWFzaWVyIHRvIGFjY29tbW9kYXRlIHRoZSBuZXcgZmVhdHVyZXMgaWYg d2UgYXJlIHVzaW5nIHRoZSBzYW1lIGJhc2Ugc3BlYy4NCg0KPiBCZWZvcmUgYSBwaWVjZSBvZiBk ZWxpY2lvdXMgY2FrZSBiZWluZyBiYWtlZCwgY291bGQgc29tZWJvZHkgYmUgYWxsb3dlZA0KPiB0 bw0KPiBoZWF0IGhpcyBleGlzdGluZyBicmVhZCB0byBhbGxheSBoaXMgaHVuZ2VyPyBJIHRoaW5r IHBlb3BsZSBjb3VsZCBtYWtlDQo+IHRoZWlyDQo+IHdpc2UgY2hvaWNlcyBkZXBlbmRpbmcgb24g dGhlaXIgc3RhcnZhdGlvbiBzdGF0dXMuDQo+IA0KPiA+IElmIHlvdSB3YW50IHRvIHN0YXkgaW4g dGhlIGNvbnRleHQgb2Ygc29sdXRpb25zIGFkZHJlc3NlZCBhbHJlYWR5IGJ5DQo+IEwyVlBODQo+ IFdHIEkNCj4gPiBzdWdnZXN0IHlvdSBnbyBmb3IgdGhlIFNQQiBvcHRpb24gYXMgaXQgaXMgYmFz ZWQgb24gSUVFRSBFdGhlcm5ldA0KPiA+IGVuY2Fwc3VsYXRpb25zIChRaW5RLzgwMi4xYWQgYW5k IFBCQi84MDIuMWFoKSB0aGF0IHdlIGFscmVhZHkNCj4gPiBjb25zaWRlcmVkL2FkZHJlc3NlZCBp biB0ZXJtcyBvZiBib3RoIFZQV1MgYW5kIFZQTFMgc29sdXRpb24gY29udGV4dHMNCj4gLSB3ZQ0K PiA+IHB1dCBhIGxvdCBvZiB3b3JrIGFscmVhZHkgaW4gYSBudW1iZXIgb2YgVlBMUyBhbmQgUEJC LVZQTFMgUkZDcy9XRw0KPiBkcmFmdHMNCj4gb24NCj4gPiB0aGUgc3ViamVjdCwgaW5jbHVkaW5n IGludGVyb3Agb25lcy4NCj4gDQo+IEdvb2QgcG9pbnQuIFRoZSBpbnRlbnRpb24gb2YgSVMtSVMg VlBMUyBpcyBqdXN0IHRvIHJldXNlIHRoZSBleGlzdGluZw0KPiBWUExTDQo+IGFuZCBJUCB0ZWNo bm9sb2dpZXMsIHNpbmNlIHdlIGhhdmUgcHV0IGEgbG90IG9mIHdvcmsgYWxyZWFkeSBpbiBhDQo+ IG51bWJlciBvZg0KPiBWUExTIGFuZCBQQkItVlBMUyBSRkNzL1dHIGRyYWZ0cywgd2l0aG91dCBt ZW50aW9uaW5nIG51bWVyb3VzIElQDQo+IFJGQ3MvV0cNCj4gZHJhZnRzLiBBcyB5b3Uga25vdywg ZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgZGF0YSBwbGFuZSwgSVMtSVMgVlBMUw0KPiBjb3VsZA0K PiByZXVzZSB0aGUgZXhpc3RpbmcgVlBMUyBlbmNhcHN1bGF0aW9uIChlLmcuLCBWUExTIG92ZXIg SVAvR1JFKSBhbmQNCj4gZm9yd2FyZGluZyBtZWNoYW5pc21zIFdJVEhPVVQgQU5ZIENIQU5HRS4N Cg0KW1tGQl1dIFNlZSBhYm92ZSB0aGVyZSBzaG91bGQgbm90IGJlIGFueSBjaGFuZ2UgaW4gVlBM UyBkYXRhIHBsYW5lLiBMZXQncyBmb2N1cyBvbiB3aHkgZ28gdGhyb3VnaCBhIFZQTFMgY29udHJv bCBwbGFuZSBjaGFuZ2Ugd2l0aCBuZXcgSVMtSVMgcHJvY2VkdXJlcyB2ZXJzdXMgcmUtdXNpbmcg dGhlIElTLUlTIHdvcmsgYWxyZWFkeSBpbiBwbGFjZSBpbiBJRUVFL0lFVEYuIA0KDQo+IA0KPiBU aGFua3MgYWdhaW4gZm9yIHlvdXIgY29tbWVudHMuDQo+IA0KPiBCZXN0IHdpc2hlcywNCj4gWGlh b2h1DQo+IA0KPiA+IEkgaG9wZSB0aGlzIGhlbHBzLg0KPiA+DQo+ID4gRmxvcmluDQo+ID4NCj4g PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBsMnZwbi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ ID4gPiBPZiBYdSBYaWFvaHUNCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE5LCAyMDExIDM6 MTIgQU0NCj4gPiA+IFRvOiBsMnZwbkBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogU2ltcGxpZmll ZCBtdWx0aWNhc3QgaW4gSVMtSVMgVlBMUw0KPiA+ID4NCj4gPiA+IEhpIGFsbCwNCj4gPiA+DQo+ ID4gPiBJIGp1c3Qgbm90aWNlZCBmcm9tIEVyaWMncyByZWNlbnQgY29tbWVudHMgb24gZHJhZnQt aWV0Zi1sMnZwbi0NCj4gdnBscy0NCj4gPiA+IG1jYXN0LTA4DQo+ID4gPiBhcyBmb2xsb3dzIChz ZWUgdGhlIHRocmVhZDoNCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9sMnZwbi9jdXJyZW50L21zZzAyNzE3Lmh0bWwpDQo+IHRoYXQNCj4gPiA+IFZQTFMtTUNBU1Qg ZG9lc24ndCBzdXBwb3J0IElQLWJhc2VkIHByb3ZpZGVyIG11bHRpY2FzdCBkaXN0cmlidXRpb24N Cj4gPiA+IHRyZWUuDQo+ID4gPg0KPiA+ID4gVGhlcmVmb3JlLCBJIHdvdWxkIGxpa2UgdG8gcmVp dGVyYXRlIHRoYXQgbXVsdGljYXN0IGluIElTLUlTIFZQTFMNCj4gY291bGQNCj4gPiA+IHVzZQ0K PiA+ID4gSVAtYmFzZWQgcHJvdmlkZXIgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiB0cmVlLiBEZXRh aWxzIGFyZSBhcw0KPiBmb2xsb3dzOg0KPiA+ID4NCj4gPiA+DQo+ID4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+ICoq KioqKioNCj4gPiA+ICoqKioNCj4gPiA+IDUuMS4yLiBNdWx0aWNhc3QvQnJvYWRjYXN0DQo+ID4g PiBUaGVyZSBhcmUgdHdvIG1ham9yIG11bHRpY2FzdCBtb2RlcyBmb3IgSVMtSVMgVlBMUzogaW5n cmVzcw0KPiByZXBsaWNhdGlvbg0KPiA+ID4gbW9kZQ0KPiA+ID4gYW5kIFAtTXVsdGljYXN0IHRy ZWUgbW9kZS4NCj4gPiA+IFRoZSBlbmNhcHN1bGF0aW9uIGNvcnJlc3BvbmRpbmcgdG8gZWFjaCBt b2RlIGlzIGRlc2NyaWJlZCBpbiB0aGUNCj4gPiA+IGZvbGxvd2luZw0KPiA+ID4gc3ViLXNlY3Rp b25zLg0KPiA+ID4NCj4gPiA+IDUuMS4yLjEuIEluZ3Jlc3MgUmVwbGljYXRpb24gTW9kZQ0KPiA+ ID4gSW4gdGhlIGluZ3Jlc3MgcmVwbGljYXRpb24gbW9kZSwgYW4gaW5ncmVzcyBQRSByb3V0ZXIg Zm9yd2FyZCB0aGUNCj4gQ0UNCj4gPiA+IG11bHRpY2FzdC9icm9hZGNhc3QgZnJhbWVzIHJlY2Vp dmVkIHZpYSBpdHMgYXR0YWNobWVudCBjaXJjdWl0cw0KPiB0b3dhcmRzDQo+ID4gPiBlYWNoDQo+ ID4gPiByZW1vdGUgUEUgcm91dGVyIG9mIHRoZSBzYW1lIFZQTFMgaW5zdGFuY2UgaW4gdGhlIHNl cGFyYXRlIElQIGJhc2VkDQo+ID4gPiB0dW5uZWxzDQo+ID4gPiBkZXN0aW5lZCBmb3IgZWFjaCBy ZW1vdGUgUEUgcm91dGVyLiBIZW5jZSwgdGhlIGVuY2Fwc3VsYXRpb24gaW4NCj4gdGhpcw0KPiA+ ID4gbW9kZQ0KPiA+ID4gaGFzIG5vIGRpZmZlcmVuY2UgZnJvbSB0aGF0IGZvciB1bmljYXN0Lg0K PiA+ID4NCj4gPiA+IDUuMS4yLjIuIFAtTXVsdGljYXN0IFRyZWUgTW9kZQ0KPiA+ID4gSW4gdGhl IG5vbi1hZ2dyZWdhdGl2ZSBQLU11bHRpY2FzdCB0cmVlIG1vZGUgd2hlcmUgYSBzaW5nbGUgUC0N Cj4gTXVsdGljYXN0DQo+ID4gPiBkaXN0cmlidXRpb24gdHJlZSBpbiB0aGUgYmFja2JvbmUgaXMg ZXhjbHVzaXZlbHkgdXNlZCBieSBvbmUgVlBMUw0KPiA+ID4gaW5zdGFuY2UsDQo+ID4gPiB0aGUg TUFDLWluLUlQIGVuY2Fwc3VsYXRpb24gaXMgdXNlZCBkaXJlY3RseSBzaW5jZSB0aGUgZGVzdGlu YXRpb24NCj4gSVANCj4gPiA+IGFkZHJlc3MgKGkuZS4sIG11bHRpY2FzdCBhZGRyZXNzKSBjb250 YWluZWQgaW4gdGhlIElQLWJhc2VkIHR1bm5lbA0KPiA+ID4gaGVhZGVyIGlzDQo+ID4gPiBlbm91 Z2ggZm9yIHRoZSBlZ3Jlc3MgUEUgcm91dGVycyB0byBkZXRlcm1pbmUgd2hpY2ggVlBMUyBpbnN0 YW5jZQ0KPiB0aGUNCj4gPiA+IGVuY2Fwc3VsYXRlZCBDRSBwYWNrZXRzIHJlY2VpdmVkIGZyb20g YSByZW1vdGUgUEUgcm91dGVyIGJlbG9uZ3MNCj4gdG8uDQo+ID4gPiBGb3IgYWdncmVnYXRpdmUg UC1NdWx0aWNhc3QgdHJlZSBtb2RlIGluIHdoaWNoIGEgc2luZ2xlIFAtTXVsdGljYXN0DQo+ID4g PiB0cmVlIGlzDQo+ID4gPiBzaGFyZWQgYnkgbW9yZSB0aGFuIG9uZSBWUExTIGluc3RhbmNlLCBN QUMtaW4tTVBMUy1JUCBlbmNhcHN1bGF0aW9uDQo+ID4gPiBTSE9VTEQNCj4gPiA+IGJlIHVzZWQu IFRoZSBNUExTIGxhYmVsIGNvbnRhaW5lZCBpbiB0aGUgaW5uZXIgTVBMUyBoZWFkZXIgd291bGQg YmUNCj4gPiA+IHVzZWQgYnkNCj4gPiA+IHRoZSBlZ3Jlc3MgUEUgcm91dGVycyB0byBpZGVudGlm eSB0aGUgcGFydGljdWxhciBWUExTIGluc3RhbmNlIHRoYXQNCj4gdGhlDQo+ID4gPiByZWNlaXZl ZCBDRSBkYXRhIHBhY2tldHMgYmVsb25nIHRvLiBUbyBhdm9pZCBpbnRyb2R1Y2luZyB0aGUNCj4g Y29tcGxleA0KPiA+ID4gdXBzdHJlYW0gbGFiZWwgYXNzaWdubWVudCBtZWNoYW5pc20gW1JGQzUz MzFdLCBpdCBpcyBzdHJvbmdseQ0KPiBzdWdnZXN0ZWQNCj4gPiA+IHRoYXQNCj4gPiA+IHRoZSBn bG9iYWxseSB1bmlxdWUgVlBMUyBsYWJlbCBTSE9VTEQgYmUgdXNlZCBpbiB0aGlzIHBhcnRpY3Vs YXINCj4gY2FzZS4NCj4gPiA+IFRodXMsDQo+ID4gPiB0aGUgdmFsdWUgb2YgdGhlIFZQTiBJRCBm aWxlZCBjb3VsZCBiZSBkaXJlY3RseSBjb3BpZWQgdG8gdGhlIFZQTFMNCj4gPiA+IExhYmVsDQo+ ID4gPiBmaWVsZC4NCj4gPiA+DQo+ID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+ICoqKioqKioNCj4gPiA+ICoqKioq DQo+ID4gPg0KPiA+ID4gSW4gYWRkaXRpb24sIHlvdSBtYXkgbm90aWNlIHRoYXQgSVMtSVMgVlBM UyBhbHNvIGFsbG93cyB1c2luZyB0aGUNCj4gPiA+IGdsb2JhbGx5DQo+ID4gPiB1bmlxdWUgVlBM UyBsYWJlbCBzbyBhcyB0byBhdm9pZCB1c2luZyB0aGUgY29tcGxleCB1cHN0cmVhbSBsYWJlbA0K PiA+ID4gYXNzaWdubWVudA0KPiA+ID4gbWVjaGFuaXNtIHdoZW4gaW1wbGVtZW50aW5nIGFnZ3Jl Z2F0aXZlIFAtTXVsdGljYXN0IHRyZWUgbW9kZS4NCj4gPiA+DQo+ID4gPiBBbnkgY29tbWVudHMg YXJlIHdlbGNvbWUuDQo+ID4gPg0KPiA+ID4gQmVzdCB3aXNoZXMsDQo+ID4gPiBYaWFvaHUNCg0K From yuqun.cao@gmail.com Mon Apr 25 19:45:27 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76025E06BD for ; Mon, 25 Apr 2011 19:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_31=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc+0EwmyXs4W for ; Mon, 25 Apr 2011 19:45:26 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFD9E06B7 for ; Mon, 25 Apr 2011 19:45:26 -0700 (PDT) Received: by pwi5 with SMTP id 5so221327pwi.31 for ; Mon, 25 Apr 2011 19:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:cc:references:subject:date :mime-version:content-type:x-priority:x-msmail-priority:x-mailer :disposition-notification-to:x-mimeole; bh=Imfg6hRhNpQSMXtT1IT8B6pknQwvv2n/nl2ftbTNqY8=; b=ZBqzMwWPARANrLBee5ROfx/HzLUdf9C/4lWJsGu3Yz7GtBhaVvLhgkP4K41OkALp7V NoOSCoZTKOVt3fm/d9VbBz4dZewgxaI90ZZ6bo0wHcYLzKzJVhdCLkyTrJSho1JjPdTz Itu8NhNrWYuE8LH/DNQ3WQ0PsZZFUxl8EzSBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:x-priority:x-msmail-priority:x-mailer :disposition-notification-to:x-mimeole; b=suuITH4pOHTtyIdzOR2C0ePe5WqxaIBoSNirittzwiQUmKO1IGmW1ZiEHzC3b66cw9 w1yFO2CAeRPId/MqDTGe2drSsgv/LARAqQF5YBAMNplt+jxspfUeAzW5yvz2qhIcS3XI xoQUixMwaq+KOWdjI9hIk8Gt2AtVEiEx0T+UA= Received: by 10.142.62.23 with SMTP id k23mr112392wfa.316.1303785924514; Mon, 25 Apr 2011 19:45:24 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id x11sm8544407wfd.13.2011.04.25.19.45.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 19:45:22 -0700 (PDT) Message-ID: From: "Sam Cao" To: "Rogers, Josh" , "Raymond Key" References: <7C9C14078D124EC0B3D99E5DF564B3AC@vvcom>, <834AC633-47CE-4729-9D05-DCB5AD4275E6@twcable.com> Subject: Re: I-D:Extension to BGP-VPLS for E-Tree Date: Tue, 26 Apr 2011 10:43:05 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001F_01CC03FE.B948BC30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Cc: l2vpn@ietf.org, chenxb@ruijie.com.cn X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 02:45:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01CC03FE.B948BC30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9zaCwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cywgYW5kIEkgZ2F2 ZSB0aGUgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb25zIGJlbG93LiANCkkgd2lsbCBjaGVjay1pbiBu ZXcgdmVyc2lvbiBBU0FQLg0KDQo+ICtBIGxlYWYgYW5kIHJvb3QgUEUgdG8gYW5vdGhlciBsZWFm IGFuZCByb290IFBFIHdvdWxkIGhhdmUgY2xlYXJlZCB0aGlzIHVwIGZvciBtZSBhcyB3ZWxsLiAg DQpFaXRoZXIgaW5jbHVkZSBhIDd0aCBBQyBhcyBSYXkgcmVjb21tZW5kZWQsIG9yIGFkZCBhIGZv dXJ0aCBQRSBjb25maWd1cmVkIGp1c3QgbGlrZSBQRTEuDQpbU2FtXSBZZXMsIEkgYWRkIG9uZSBB QzcsIGFuZCByZWZlciB0byBhdHRhY2htZW50IGZvciBmaWd1cmUuDQoNCj4gKyAzLjIgLSBNYXli ZSB5b3UgY2FuIHJlcGhyYXNlIHRoaXM/IEknbSBoYXZpbmcgdHJvdWJsZSBmb2xsb3dpbmcgaXQu IDMuMSBtZW50aW9ucyBhIG1ldGhvZCANCnRoYXQgdXNlcyBhICd0YWcnIGZvciBlYWNoIGZyYW1l IHRoYXQgZGVub3RlcyBpdCBpcyBzb3VyY2VkIGZyb20gYSBsZWFmLCBhbmQgMy4yIChpbiBjb250 cmFzdCkgdXNlcyBhIA0KZGlmZmVyZW50IG1ldGhvZC4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3Rs eSwgeW91IHdhbnQgdGhlIHJvdXRlciB0byBiZSBhd2FyZSBvZiB3aGF0IHRoZSBlbmRwb2ludHMg DQphcmUgYW5kIGRlY2lkZSB3aGV0aGVyIHRvIGZvcndhcmQgdG8gb3RoZXIgUEUncy9BQydzLCBy YXRoZXIgdGhhbiBzZW5kIGl0LCBhbmQgZGVjaWRlIGFmdGVyIGl0IGFycml2ZXMgDQooYXMgaW4g My4xKS4gQW4gYWx0ZXJuYXRlIHdheSBvZiBwaHJhc2luZyB0aGlzIHRoYXQgeW91IG1heSBjb25z aWRlciBpczoNCltTYW1dIFllcywgSSB0cnkgdG8gbWFrZSBpdCBjbGVhci4gQ29tcGx5IHdpdGgg UkZDIDQ3NjEsIFZQTFMgZWRnZSBJRCBzaG91bGQgYmUgYXNzaWduZWQgYnkgDQphZG1pbmlzdHJh dG9yLCBhbmQgUEUgaW4gVlBMUyBhbHNvIGNhbGN1bGF0ZSBsYWJlbCB3aXRoIFZFIElELCBibG9j ayBzaXplLCBMYWJlbCBiYXNlLCBvZmZzZXQuIFNvDQogaWYgd2Ugc2VwZXJhdGUgTGVhZiBBQ3Mg ZnJvbSBSb290IEFDcyB3aXRoIFZFIElELCB0aGVuIHdlIGNhbiBicmVhayBjb21tdW5pY2F0aW9u IGJldHdlZW4gTGVhZnMuIA0KVGhpcyBmb2xsb3dzIEFwcGVuZGl4IEEgaW4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQta2V5LWwydnBuLWV0cmVlLWZyd2stMDQjYXBwZW5kaXgtQQ0K QS44LiAgSSBoYXZlIGV4dGVuZGVkIFJGQyA0NzYxIGluIG5ldyB2ZXJzaW9uLCBhbmQgSSB3aWxs IGNoZWNrLWluIEFTQVAuIFRoaXMgY2FuIGJlIHVzZWQgZm9yIA0KTERQLVZQTFMsIGJ1dCBJIG5l ZWQgdG8gY2xlYXIgaXQgZmlyc3QuDQoNCg0KPiArIElzICdlbmRwb2ludCcgZGVmaW5lZCBzb21l d2hlcmUgZWxzZT8gSSBjYW4gZ2F0aGVyIChmcm9tIGZpZ3VyZSAyKSB0aGF0IHlvdSBtZWFuIGEg cHNldWRvd2lyZSBlbmRwb2ludCwgDQpidXQgSSdtIG5vdCBzdXJlIHRoYXQgaXMgdmVyeSBjbGVh ciBoZXJlLg0KW1NhbV0gRW5kcG9pbnQgaXMgZGVmaW5lZCBpbiBSRkMgNDc2MSxhbmQgSSB0cnkg dG8gdXNlIHRoaXMgdG8gc2VwZXJhdGUgTGVhZiBmcm9tIFJvb3QuIEluIG9uZSB3b3JkLCBFdmVy eSANCmVuZHBvaW50IHNob3VsZCBiZSBkZXNpZ25hdGVkIG9uZSBJRCAoVkUgSUQgaW4gUkZDIDQ3 NjEpLCBhbmQgaXQgaGFzIG9uZSBvciBtb3JlIEFDcy4gSnVzdCBhcyBtZW50aW9uZWQgaW4gDQpt eSBkcmFmdCwgb25lIGVuZHBvaW50IG9ubHkgaGFzIExlYWZzIG9yIFJvb3RzLCBidXQgY2FuIG5v dCBoYXZlIFJvb3RzIGFuZCBMZWFmcy4gVGhpcyBpcyBrZXkgcG9pbnQgaW4gbXkgZHJhZnQuDQoN Cj4gKyBJcyA1LjcgYSBkdXBsaWNhdGUgb2YgNS42Pw0KW1NhbV0gTm8sIHRoZXJlIGFyZSBkaWZm ZXJlbnQsIG9uZSBpcyBmb3IgTGVhZiBlbmRwb2ludCwgYW5kIG9uZSBpcyBSb290IGVuZHBvaW50 LiBOb3cgSSB1cGdyYXRlIGl0IGFuZCBsaWtlIGJlbG93LA0KNS42LjIuIExlYWYgZW5kcG9pbnQN Cg0KICAgMS4gQ2hlY2tzIGlmIHcgaXMgTGVhZiBlbmRwb2ludCB3aXRoICJMYXllcjIgSW5mbyBF eHRlbmRlZCBDb21tdW5pdHkiLg0KICAgICAgSWYgaXQgaXMsIFBFLWIgaWdub3JlcyB0aGlzIG1l c3NhZ2Ugc2luY2UgcmVtb3RlIGVuZHBvaW50IGlzIExlYWYsDQogICAgICBhbmQgc2tpcHMgdGhl IHJlc3Qgb2YgdGhpcyBwcm9jZWR1cmUuDQoNCg0KDQogIENhbyAgICAgICAgICAgICAgICAgRXhw aXJlcyBPY3RvYmVyIDI2LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICBFeHRlbnNpb24gdG8gQkdQLVZQTFMgZm9yIEUtVHJlZSAgICAgICAgICBBcHJp bCAyMDExDQoNCg0KICAgMi4gQ2hlY2tzIGlmIHcgaXMgcGFydCBvZiBQRS1hJ3MgJ3JlbW90ZSBW RSBzZXQnOiBpZiBWQk8gPD0gdyA8IFZCTysNCiAgICAgIFZCUywgdGhlbiB3IGlzIHBhcnQgb2Yg UEUtYSdzIHJlbW90ZSBSb290IFZFIHNldC4gIElmIG5vdCwgUEUtYg0KICAgICAgaWdub3JlcyB0 aGlzIG1lc3NhZ2UsIGFuZCBza2lwcyB0aGUgcmVzdCBvZiB0aGlzIHByb2NlZHVyZS4NCg0KICAg ICAgICA0LiBTZXRzIHVwIGEgUFcgdG8gUEUtYTogdGhlIGRlbXVsdGlwbGV4b3IgbGFiZWwgdG8g c2VuZCB0cmFmZmljDQogICAgICAgICAgIGZyb20gUEUtYiB0byBQRS1hIGlzIGNvbXB1dGVkIGFz IChsTEIgKyB3IC0gVkJPKS4NCg0KICAgICAgICA1LiBDaGVja3MgaWYgbCBpcyBwYXJ0IG9mIGFu eSAncmVtb3RlIFZFIHNldCcgdGhhdCBQRS1iDQogICAgICAgICAgIGFubm91bmNlZCwgaS5lLiwg UEUtYiBjaGVja3MgaWYgbCBiZWxvbmdzIHRvIHNvbWUgcmVtb3RlIFZFDQogICAgICAgICAgIHNl dCB0aGF0IFBFLWIgYW5ub3VuY2VkLCBzYXkgd2l0aCBWRSBCbG9jayBPZmZzZXQgVkJPJywgVkUN CiAgICAgICAgICAgQmxvY2sgU2l6ZSBWQlMnLCBhbmQgbGFiZWwgYmFzZSBMQicuIElmIG5vdCwg UEUtYiBNVVNUIG1ha2UgYQ0KICAgICAgICAgICBuZXcgYW5ub3VuY2VtZW50IGFzIGRlc2NyaWJl ZC4NCg0KICAgICAgICA2LiBTZXRzIHVwIGEgUFcgZnJvbSBQRS1hOiB0aGUgZGVtdWx0aXBsZXhv ciBsYWJlbCBvdmVyIHdoaWNoDQogICAgICAgICAgIFBFLWIgc2hvdWxkIGV4cGVjdCB0cmFmZmlj IGZyb20gUEUtYSBpcyBjb21wdXRlZCBhczogKExCJyArIGwNCiAgICAgICAgICAgLSBWQk8nKS4N Cg0KICAgSWYgUEUtYSB3aXRoZHJhd3MgYW4gTkxSSSBmb3IgbCB0aGF0IFBFLWIgd2FzIHVzaW5n LCB0aGVuIFBFLWIgTVVTVA0KICAgdGVhciBkb3duIGl0cyBlbmRzIG9mIHRoZSBwc2V1ZG93aXJl IGJldHdlZW4gUEUtYSBhbmQgUEUtYi4NCg0KPiBQRTEgdGFyZ2V0OjEyMzoxIHRhcmdldDoxMjM6 MiAoY29yZS1mYWNpbmcpDQo+IFBFMiB0YXJnZXQ6MTIzOjIgdGFyZ2V0OjEyMzoxIChObyBsb2Nh bC1zd2l0Y2hpbmcpDQo+IFBFMyB0YXJnZXQ6MTIzOjEgdGFyZ2V0OjEyMzoyDQpbU2FtXSBZZXMs IHdlIGNhbiB1c2UgUm91dGUgVGFyZ2V0IGluIG1vc3QgY2FzZXMsIGJ1dCBmb3IgUm9vdC1MZWFm LU1peGVkIGNhc2VzIChJbiBGaWd1cmUxKSwgDQppdCBjYW4gbm90IGZpZ3VyZSBvdXQgUm9vdCBh bmQgTGVhZiBlYXNpbHkuIEkgaGF2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIFJheW1vbmQgYW5kIEx1 Y2EgdGhyb3VnaCBFLW1haWwuDQoNCkFnYWluLCBKb3NoLCB0aGFuayB5b3UgdmVyeSBtdWNoIGZv ciB5b3VyIHRpbWUuIA0KDQpTYW0NCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+DQpUbzogIlJh eW1vbmQgS2V5IiA8cmF5bW9uZC5rZXlAaWVlZS5vcmc+DQpDYzogPHl1cXVuLmNhb0BnbWFpbC5j b20+OyA8bDJ2cG5AaWV0Zi5vcmc+OyA8eW9ydGlvbkBob3RtYWlsLmNvbT47IDxjaGVueGJAcnVp amllLmNvbS5jbj4NClNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyMywgMjAxMSAxMTowNCBQTQ0KU3Vi amVjdDogUmU6IEktRDpFeHRlbnNpb24gdG8gQkdQLVZQTFMgZm9yIEUtVHJlZQ0KDQoNClllcywg SSBhZ3JlZS4NCg0KQSBsZWFmIGFuZCByb290IFBFIHRvIGFub3RoZXIgbGVhZiBhbmQgcm9vdCBQ RSB3b3VsZCBoYXZlIGNsZWFyZWQgdGhpcyB1cCBmb3IgbWUgYXMgd2VsbC4gIEVpdGhlciBpbmNs dWRlIGEgN3RoIEFDIGFzIFJheSByZWNvbW1lbmRlZCwgb3IgYWRkIGEgZm91cnRoIFBFIGNvbmZp Z3VyZWQganVzdCBsaWtlIFBFMS4NCg0KQWxzbywgcmVnYXJkaW5nIHRoZSB0YXJnZXQgY29tbXVu aXRpZXMuLi4gIEkndmUgb2Z0ZW4gdGhvdWdodCB0aGF0IGlmIEkgaGFkIHRoZSBhYmlsaXR5IHRv IGltcG9ydCBtb3JlIHRoYW4gb25lIGNvbW11bml0eSwgaXQgd291bGQgYWRkcmVzcyB0aGUgY3Vy cmVudCBpbmFiaWxpdHkgdG8gaGF2ZSByb290LXJvb3QgY29tbXVuaWNhdGlvbiB0aGF0IEkgZXhw ZXJpZW5jZSB0b2RheS4gIEl0IHdvdWxkIG5vdCwgaG93ZXZlciwgYWRkcmVzcyBhIHJvb3QvbGVh ZiB0byByb290L2xlYWYgY29tbXVuaWNhdGlvbi4NCg0KLUpvc2gNCg0KDQoNCk9uIEFwciAyMywg MjAxMSwgYXQgMzoxMCBBTSwgUmF5bW9uZCBLZXkgd3JvdGU6DQoNCkEgY29tbWVudCBvbiBGaWd1 cmUgMiB1bmRlciBTZWN0aW9uIDQuIFJlZmVyZW5jZSBNb2RlbCAoZXh0cmFjdGVkIGJlbG93KQ0K DQogICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tRS1UcmVlLS0tLS0tLS0tLS0tPnwNCiAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWDQogICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLSsNCiAgICAgICAgICAgICAg ICAgICB8ICAgUEUxICAgfCAgICAgICAgICB8ICAgUEUyICAgfCAgICAvTGVhZiBlbmRwb2ludA0K ICAgKy0tLSsgICAgICAgICAgIHwgICstLS0rICB8ICAgICAgICAgIHwgICstLS0rICB8ICAvXCAg ICAgICAgICAgKy0tLSsNCiAgIHxDRTErLS0tLS0tLUFDMS0rLS0rIFYgfCAgfCAgICAgICAgICB8 ICB8IFYgKy0tKy18LS0tIC0tQUMzLS0tLStDRTN8DQogICArLS0tKyAgKFJvb3QgQUMpfCAgfCBT ICstLSstLS1QVzEyLS0tKy0tKyBTIHwgIHwgfCAgfChMZWFmIEFDKSArLS0tKw0KICAgKy0tLSsg ICAgICAgICAgIHwgIHwgSSB8ICB8ICAgICAgICAgIHwgIHwgSSB8ICB8IHwgIHwgICAgICAgICAg Ky0tLSsNCiAgIHxDRTIrLS0tLUFDMi0tLS0rLS0rICAgfCAgfCAgICAgICAgICB8ICB8ICAgKy0t Ky18LS0tLS0tQUM0LS0tLStDRTR8DQogICArLS0tKyAgKExlYWYgQUMpfCAgKy0rLSsgIHwgICAg ICAgICAgfCAgKy0rLSsgIHwgIFwvIChMZWFmIEFDKSArLS0tKw0KICAgICAgICAgICAgICAgICAg ICstLS0rLSstLS0rICAgICAgICAgICstLS0tKy0tLS0rDQogICAgICAgICAgICAgICAgICAgXiAg IHwgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgfCAgIHwgfFBXMTMt MiAgICAgICAgICAgICB8UFcyMw0KICAgICAgICAgICAgICAgICAgIHwgICB8IHwgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICBQVzEzLTF8IHwgICAgICAgICAgICAgICstLS0t Ky0tLS0rICAgIC9Sb290IGVuZHBvaW50DQogICAgICAgICAgICAgICAgICAgfCAgIHwgfCAgICAg ICAgICAgICAgfCAgKy0rLSsgIHwgIC9cICAgICAgICAgICstLS0rDQogICAgICAgICAgICAgICAg ICAgfCAgIHwgfCAgICAgICAgICAgICAgfCAgfCB2ICstLSstfC0tLS0tLS0tQUM1LStDRTV8DQog ICAgICAgICAgICAgICAgICAgfCAgIHwgKy0tLS0tLS0tLS0tLS0tKy0tKyBzIHwgIHwgfCAgfChS b290IEFDKSstLS0rDQogICAgICAgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICAgfCAg fCBJIHwgIHwgfCAgfCAgICAgICAgICstLS0rDQogICAgICAgICAgICAgICAgICAgfCAgICstLS0t LS0tLS0tLS0tLS0tKyAgfCAgICstLSstfC0tLS0tLUFDNi0tLStDRTZ8DQogICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgKy0tLSsgIHwgIFwvIChSb290IEFDKSstLS0r DQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgIFBFMyAgIHwNCiAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKw0KICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgICAgICAg ICAgICAgICAgfCA8LS0tLS0tLS0tLS1FLVRyZWUtLS0tLS0tLS0tPnwNCg0KDQpBcyBQRTMgaGFz IFJvb3QgQUNzIG9ubHksIGNvbW11bmljYXRpb24gYmV0d2VlbiBhbiBBQyBvbiBQRTEgYW5kIGFu IEFDIG9uIFBFMyBpcyBhbHdheXMgYWxsb3dlZC4gIFRoaXMgc2NlbmFyaW8gc2VlbXMgbm90IHJl YWxseSBuZWVkIGV4dGVuc2lvbiB0byBjdXJyZW50IFZQTFMuDQoNCklNTyBpdCBtYXkgYmUgYmV0 dGVyIGlmIHlvdSBhZGQgYSBMZWFmIEFDIChjYWxsZWQgaXQgQUM3KSBvbiBQRTMgYW5kIGV4cGxh aW4gaG93IHlvdXIgcHJvcG9zZWQgc29sdXRpb24gcHJvaGliaXRzIGNvbW11bmljYXRpb24gYmV0 d2VlbiBBQzIgKExlYWYgQUMgb24gUEUxKSBhbmQgQUM3IChMZWFmIEFDIG9uIFBFMykuDQoNClJl Z2FyZHMsDQpSYXltb25kIEtleQ0KDQoNCj4gRnJvbTogam9zaC5yb2dlcnNAdHdjYWJsZS5jb208 bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPg0KPiBUbzogeXVxdW4uY2FvQGdtYWlsLmNv bTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4NCj4gRGF0ZTogRnJpLCAyMiBBcHIgMjAxMSAx NjozMjoyNyAtMDQwMA0KPiBTdWJqZWN0OiBSZTogSS1EOkV4dGVuc2lvbiB0byBCR1AtVlBMUyBm b3IgRS1UcmVlDQo+IENDOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyB5 b3J0aW9uQGhvdG1haWwuY29tPG1haWx0bzp5b3J0aW9uQGhvdG1haWwuY29tPjsgY2hlbnhiQHJ1 aWppZS5jb20uY248bWFpbHRvOmNoZW54YkBydWlqaWUuY29tLmNuPg0KPg0KPiBTYW0sDQo+DQo+ IFRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIHdvcmsgb24gdGhpcyBkcmFmdC4gU29tZSBwb2ludHMg YmVsb3c6DQo+DQo+DQo+ICsgMy4yIC0gTWF5YmUgeW91IGNhbiByZXBocmFzZSB0aGlzPyBJJ20g aGF2aW5nIHRyb3VibGUgZm9sbG93aW5nIGl0LiAzLjEgbWVudGlvbnMgYSBtZXRob2QgdGhhdCB1 c2VzIGEgJ3RhZycgZm9yIGVhY2ggZnJhbWUgdGhhdCBkZW5vdGVzIGl0IGlzIHNvdXJjZWQgZnJv bSBhIGxlYWYsIGFuZCAzLjIgKGluIGNvbnRyYXN0KSB1c2VzIGEgZGlmZmVyZW50IG1ldGhvZC4g SWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IHdhbnQgdGhlIHJvdXRlciB0byBiZSBhd2Fy ZSBvZiB3aGF0IHRoZSBlbmRwb2ludHMgYXJlIGFuZCBkZWNpZGUgd2hldGhlciB0byBmb3J3YXJk IHRvIG90aGVyIFBFJ3MvQUMncywgcmF0aGVyIHRoYW4gc2VuZCBpdCwgYW5kIGRlY2lkZSBhZnRl ciBpdCBhcnJpdmVzIChhcyBpbiAzLjEpLiBBbiBhbHRlcm5hdGUgd2F5IG9mIHBocmFzaW5nIHRo aXMgdGhhdCB5b3UgbWF5IGNvbnNpZGVyIGlzOg0KPg0KPg0KPiAzLiBUZXJtaW5vbG9neQ0KPg0K PiA8c25pcD4NCj4NCj4gMi4gVGhlIGRlY2lzaW9uIHRvIGZvcndhcmQgYSBmcmFtZSB0byBhbm90 aGVyIEFDIG9yIGFjcm9zcyBhIFBXIGlzIGJhc2VkIG9uIGZvcmVrbm93bGVkZ2Ugb2YgdGhlIGxv Y2FsIEFDIHR5cGUgYW5kIHRoZSByZW1vdGUgQUMgdHlwZS4gSWYgYSBmcmFtZSBjb21lcyBmcm9t IGEgbG9jYWwgTGVhZi1BQywgdGhlbiBpdCB3aWxsIG5vdCBmb3J3YXJkIHRvIGFueSBvdGhlciBs b2NhbCBMZWFmLUFDJ3MsIGFuZCB3aWxsIG9ubHkgZm9yd2FyZCBhY3Jvc3MgUFcocykgdG8gYSBQ RSB3aGljaCBoYXMgYSBSb290LUFDLiBJbiB0aGlzIHdheSwgd2UgcmVzdHJpY3QgdGhlIGNvbW11 bmljYXRpb24gYmV0d2VlbiBMZWFmcyBieSBidWlsZGluZyBhIHBhcnRpYWwgbWVzaCBvZiBQVydz LCBpbnRlbnRpb25hbGx5IGV4Y2x1ZGluZyBQVydzIGJldHdlZW4gTGVhZi1BQydzLiBBZGRpdGlv bmFsIFBXcyB3aWxsIG5lZWQgdG8gYmUgY3JlYXRlZCB0by9mcm9tIFBFJ3MgdGhhdCBjb250YWlu IGJvdGggUm9vdCBhbmQgTGVhZiBBQ3MuDQo+DQo+IFRoZSBwdXJwb3NlZCBzb2x1dGlvbiBpbiB0 aGlzIGRvY3VtZW50IHByZWZlcnMgdG8gdGhlIHNlY29uZC4gVHdvIHRlcm1zIGFyZSBpbnRyb2R1 Y2VkLA0KPg0KPiBvIFJvb3QtZW5kcG9pbnQuIE9uZSBlbmRwb2ludCB3aGljaCBjb25uZWN0cyBv bmx5IFJvb3QtQUNzLCBvbmUgb3INCj4gbW9yZSBSb290LUFDcy4NCj4NCj4gbyBMZWFmLWVuZHBv aW50LiBPbmUgZW5kcG9pbnQgd2hpY2ggY29ubmVjdHMgb25seSBMZWFmLUFDcywgb25lIG9yDQo+ IG1vcmUgTGVhZi1BQ3MuDQo+DQo+IFRoZXJlIGlzIG5vIGVuZHBvaW50IHdoaWNoIGNvbm5lY3Rz IGJvdGggUm9vdC1BQ3MgYW5kIExlYWYtQUNzIGluIHRoZQ0KPiBzZWNvbmQgc29sdXRpb24sIGhv d2V2ZXIgYSBQRSBtYXkgaGF2ZSBvbmUgb2YgZWFjaCBlbmRwb2ludCBjb25maWd1cmVkIGluIHRo ZSBzYW1lIHZwbHMgaW5zdGFuY2UuDQo+DQo+ICsgSXMgJ2VuZHBvaW50JyBkZWZpbmVkIHNvbWV3 aGVyZSBlbHNlPyBJIGNhbiBnYXRoZXIgKGZyb20gZmlndXJlIDIpIHRoYXQgeW91IG1lYW4gYSBw c2V1ZG93aXJlIGVuZHBvaW50LCBidXQgSSdtIG5vdCBzdXJlIHRoYXQgaXMgdmVyeSBjbGVhciBo ZXJlLg0KPg0KPiBSZWdhcmRpbmcgZmlndXJlIDIsIEkgYXQgZmlyc3QgdGhvdWdodCB0aGVyZSBz aG91bGQgb25seSBiZSBvbmUgUFcgYmV0d2VlbiBQRTEgYW5kIFBFMywgYW5kIHRoZXJlIHNob3Vs ZCBiZSB0d28gUFcncyBiZXR3ZWVuIFBFMSAoc2luY2UgYm90aCBBQzEgYW5kIEFDMiBjYW4vc2hv dWxkIHRhbGsgdG8gYm90aCBBQzUgYW5kIEFDNikgSW4gZmFjdCwgSSBiZWxpZXZlIHdpdGggdGhl IHRvcG9sb2d5IGRyYXduLCB0aGVyZSBzaG91bGQgYmUgdGhyZWUgUFcncyB0b3RhbCwgaG93ZXZl ciBQRTEgc2hvdWxkIGhhdmUgdHdvIFZFLUlEJ3MsIGFuZCBQVydzIHRlcm1pbmF0aW5nIHRvIGVh Y2gsIHJhdGhlciB0aGFuIG9uZSBWRS1JRCdzIHRlcm1pbmF0aW5nIHR3byBQVydzIGFzIHRoZSBv dGhlciB0d28gUEUncywgd2hpY2ggaXMgd2hhdCBhbGxvd3MgdW5pcXVlIGZvcndhcmRpbmcgZGVj aXNpb25zIGJhc2VkIG9uIHRoZSBzb3VyY2UgVkUtSUQgdHlwZSwgcm9vdCBvciBsZWFmKS4NCj4N Cj4gQWZ0ZXIgbG9va2luZyB0aHJvdWdoIGl0IGEgc2Vjb25kIHRpbWUsIEkgcmVhbGl6ZWQgdGhh dCB5b3VyIGludGVudGlvbiBpcyB0byB0ZXJtaW5hdGUgUFcgcGVyICdlbmRwb2ludCcgKHRoaXMg Z29lcyBiYWNrIHRvIHRoZSBlYXJsaWVyIGNvbW1lbnQgYWJvdXQgd2hldGhlciB0aGlzIGlzIGFs cmVhZHkgZGVmaW5lZCBzb21ld2hlcmUpIG9uIGVhY2ggUEUsIGFsbW9zdCBzZWdtZW50aW5nIHRo ZSBQRSBpbnRvIGJlaGF2aW5nIGFzIHRob3VnaCBpdCB3YXMgdHdvIFBFJ3MgKG9uZSBmb3IgdGhl IHJvb3QgQUMncyBhbmQgb25lIGZvciB0aGUgbGVhZiBBQydzKSBwYXJ0aWNpcGF0aW5nIGluIHRo ZSBpbnN0YW5jZS4gV2hpbGUgSSBiZWxpZXZlIHRoYXQgdGhlIGFkZGl0aW9uYWwgUFcgbWF5IGJl IHVubmVjZXNzYXJ5IGluIHRoaXMgcGFydGljdWxhciBleGFtcGxlLCBJIGJlbGlldmUgeW91ciBh cHByb2FjaCBvZiB1c2luZyBvbmUgJ2VuZHBvaW50JyBwZXIgQUMgdHlwZSBzaG91bGQgc2NhbGUg d2l0aCBhbnkgc2NlbmFyaW8uIEl0IG1heSBiZSBhIGdvb2QgaWRlYSB0byB0cnkgYW5kIHJlcHJl c2VudCB0aGUgJ2VuZHBvaW50cycgaW4gZmlndXJlIDIsIG1heWJlIGluIHBsYWNlIG9mIHRoZSBW U0kgYm94LCBwbGFjZSB0d28gZW5kcG9pbnQgYm94ZXMgb24gUEUxLCBhbmQgb25lIGJveCBvbiBl YWNoIG9mIHRoZSBvdGhlciBQRSdzPyBQdXQgYW4gUiBpbiB0aGUgcm9vdCBlbmRwb2ludHMgYW5k IEwgaW4gdGhlIGxlYWYgb25lcywgbGlrZSB0aGlzOg0KPg0KPiB8PC0tLS0tLS0tLS0tRS1UcmVl LS0tLS0tLS0tLS0tPnwNCj4gfCB8DQo+IFYgVg0KPiArLS0tLS0tLS0tLSsgKy0tLS0tLS0tLSsN Cj4gUm9vdCBlbmRwb2ludC0tIFBFMSB8IHwgUEUyIHwgL0xlYWYgZW5kcG9pbnQNCj4gKy0tLSsg fFwgKy0tLSsgfCB8ICstLS0rIHwgL1wgKy0tLSsNCj4gfENFMSstLS0tLS0tQUMxLSstLSsgUiAr LS0tfC0tLVBXMTItLS0rLS0rICstLSstfC0tLSAtLUFDMy0tLS0rQ0UzfA0KPiArLS0tKyAoUm9v dCBBQyl8ICstLS0rLSsgfCB8IHwgViB8IHwgfCB8KExlYWYgQUMpICstLS0rDQo+IHwgfCB8IHwg fCBTIHwgfCB8IHwNCj4gKy0tLSsgfCArLS0tKyB8IHwgfCB8IEkgfCB8IHwgfCArLS0tKw0KPiB8 Q0UyKy0tLS1BQzItLS0tKy0tKyBMIHwgfCB8IHwgfCArLS0rLXwtLS0tLS1BQzQtLS0tK0NFNHwN Cj4gKy0tLSsgKExlYWYgQUMpfCAvKystLSsgfCB8IHwgKy0rLSsgfCBcLyAoTGVhZiBBQykgKy0t LSsNCj4gLy0tLXwtLS0tfC0rICstLS0tKy0tLS0rDQo+IExlYWYgZW5kcG9pbnQgK14gfCB8IHwN Cj4gfCB8IHxQVzEzLTIgfFBXMjMNCj4gfCB8IHwgfA0KPiBQVzEzLTF8IHwgKy0tLS0rLS0tLSsg L1Jvb3QgZW5kcG9pbnQNCj4gfCB8IHwgfCArLSstKyB8IC9cICstLS0rDQo+IHwgfCB8IHwgfCBW ICstLSstfC0tLS0tLS0tQUM1LStDRTV8DQo+IHwgfCArLS0tLS0tLS0tLS0rLS0rIFMgfCB8IHwg fChSb290IEFDKSstLS0rDQo+IHwgfCB8IHwgSSB8IHwgfCB8ICstLS0rDQo+IHwgKy0tLS0tLS0t LS0tLS0tLS0rIHwgKy0tKy18LS0tLS0tQUM2LS0tK0NFNnwNCj4gfCB8ICstLS0rIHwgXC8gKFJv b3QgQUMpKy0tLSsNCj4gfCB8IFBFMyB8DQo+IHwgKy0tLS0tLS0tLSsNCj4gfCBeDQo+IHwgPC0t LS0tLS0tLS0tRS1UcmVlLS0tLS0tLS0tLT58DQo+DQo+IFRoZXJlIGlzIGEgc21hbGwgdHlwbyBp biA1LjMsIEkgYmVsaWV2ZSBGb2V4IHNob3VsZCBiZSBGb3IuDQo+DQo+IElzIDUuNyBhIGR1cGxp Y2F0ZSBvZiA1LjY/DQo+DQo+IFJlZ2FyZGluZyBzaWduYWxpbmcsIHVuZGVyIHRoZSBleGlzdGlu ZyBzdGFuZGFyZHMgKG5vIGRlZmluZWQgJ2VuZHBvaW50cycpLCB3ZSB1c2Ugb3Bwb3NpbmcgdGFy Z2V0IGNvbW11bml0aWVzIChvbmUgZm9yIHJvb3Qgc2l0ZXMsIGFuZCBvbmUgZm9yIGxlYWYgc2l0 ZXMpIHN1Y2Nlc3NmdWxseSB0b2RheSB0byBhY2NvbXBsaXNoIEVUUkVFIHNlcnZpY2VzLiBJbiB0 aGUgdG9wb2xvZ3kgb3V0bGluZWQgaW4gZmlndXJlIDIsIHdlJ2QgY29uZmlndXJlIGxpa2UgdGhp czoNCj4NCj4gUEUgZXhwb3J0IGltcG9ydCBBZGQnbCBrbm9icw0KPiBQRTEgdGFyZ2V0OjEyMzox IHRhcmdldDoxMjM6MiAoY29yZS1mYWNpbmcpDQo+IFBFMiB0YXJnZXQ6MTIzOjIgdGFyZ2V0OjEy MzoxIChObyBsb2NhbC1zd2l0Y2hpbmcpDQo+IFBFMyB0YXJnZXQ6MTIzOjEgdGFyZ2V0OjEyMzoy DQo+DQo+IFRoZSB0d28gcHJpbWFyeSBwcm9ibGVtcyB0aGF0IHdlIGZhY2Ugd2l0aCB0aGlzIG1l dGhvZCBhcmU6DQo+IDEpIFJvb3QgdG8gcm9vdCBjb21tdW5pY2F0aW9uIGlzIG5vdCBwb3NzaWJs ZS4gUm9vdC1MZWFmIGFuZCBMZWFmLVJvb3QgYXJlIHRoZSBvbmx5IHBvc3NpYmxlIGNvbWJpbmF0 aW9ucy4NCj4gMikgdGhlICdjb3JlIGZhY2luZycga25vYiBhdmFpbGFibGUgb24gdGhlIEp1bmlw ZXIgcGxhdGZvcm0gd2lsbCBjYXVzZSBBQzIgdG8gY29tbXVuaWNhdGUgd2l0aCBBQzEsIGJ1dCBO T1QgY29tbXVuaWNhdGUgd2l0aCBhbnkgb3RoZXIgQUMncywgaW5jbHVkaW5nIEFDNSBhbmQgQUM2 Lg0KPg0KPiBCb3RoIG9mIHRoZXNlIHByb2JsZW1zIGJyZWFrIHRoZSBFVFJFRSByZXF1aXJlbWVu dHMgZHJhZnQgUmF5bW9uZCB3b3JrZWQgb24gZWFybGllciwgYW5kIGJvdGggYXJlIGFkZHJlc3Nl ZCB3aXRoIHRoZSBkcmFmdCB5b3UgYXJlIHdvcmtpbmcgb24gbm93LiBJIGxvb2sgZm9yd2FyZCB0 byBzZWVpbmcgc2VjdGlvbiA1LjcgY29tcGxldGVkL2V4dGVuZGVkLg0KPg0KPg0KPiBUbyByZWNh cCwgdGhlIHByaW1hcnkgcHJvYmxlbSB3ZSBuZWVkIHRvIHNvbHZlIHdpdGggdGhpcyB0b3BvbG9n eSBpcyAxKSBBQzMgYW5kIEFDNCBjYW5ub3QgYmUgYWxsb3dlZCB0byBjb21tdW5pY2F0ZSAobm8g bG9jYWwgc3dpdGNoaW5nKSwgYW5kIDIpIEFDMiBjYW5ub3QgYmUgYWxsb3dlZCB0byBjb21tdW5p Y2F0ZSB3aXRoIEFDMyBhbmQgQUM0IGFuZCB2aWNlIHZlcnNhLiBJIGJlbGlldmUgd2hhdCB5b3Ug YXJlIHRyeWluZyB0byBjb252ZXkgaXMgdGhhdCBQRTEgd2lsbCBmb3J3YXJkIHRyYWZmaWMgZnJv bSBBQzIgdG8gUEUzLCBidXQgbm90IFBFMiwgYW5kIFBFMiB3aWxsIGZvcndhcmQgdG8gUEUzIGJ1 dCBub3QgUEUyLCB3aGlsZSBzdGlsbCBhbGxvd2luZyBBQzEgdG8gZm9yd2FyZCB0byBQRTIuDQo+ DQo+IFNhbSwgdGhpcyBpcyBhIHZlcnkgZ29vZCBzdGFydCwgYW5kIEkgbG9vayBmb3J3YXJkIHRv IHNlZWluZyBpdCB0aHJvdWdoLiBSZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIGVmZm9ydHMgaGVyZSwg YXMgdGhpcyBpcyBhIHZlcnkgcmVsZXZhbnQgZHJhZnQuIFBsZWFzZSBsZXQgbWUga25vdyBpZiBJ IGNhbiBoZWxwLg0KPg0KPiAtSm9zaA0KPg0KPg0KPg0KPg0KPiBPbiBBcHIgMTUsIDIwMTEsIGF0 IDk6MjUgQU0sIFNhbSBDYW8gd3JvdGU6DQo+DQo+ID4gSGkgTDJWUE4gd29ya2luZyBncm91cCwN Cj4gPg0KPiA+IEkgaGF2ZSBqdXN0IHVwZGF0ZWQgIkV4dGVuc2lvbiB0byBCR1AtVlBMUyBmb3Ig RS1UcmVlIiAoaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1jYW8tbDJ2cG4tYmdwLXZwbHMt ZXRyZWUtMDEudHh0KS4gVGhpcyBkcmFmdCBwcm9wb3NlcyBhbiBhcHByb2FjaCB0byBzdXBwb3J0 IE1ldHJvIEV0aGVybmV0IEZvcnVtIChNRUYpIEV0aGVybmV0IFRyZWUgKEUtVHJlZSkgaW4gVmly dHVhbCBQcml2YXRlIExBTiBTZXJ2aWNlIHVzaW5nIEJHUCBmb3IgYXV0by1kaXNjb3ZlcnkgYW5k IHNpZ25hbGluZyBbUkZDNDc2MV0sIGFuZCBJIGJlbGlldmUgdGhhdCB0aGVzZSBzb2x1dGlvbiBj b25jZXB0cyBjYW4gYmUgYXBwbGllZCB0byBib3RoIExEUC1WUExTIGFuZCBCR1AtVlBMUywgYnV0 IHRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgYSBsaXR0bGUgZGlmZmVyZW50Lg0KPiA+DQo+ID4g R3JhdGVmdWwgaWYgeW91IGNvdWxkIHJldmlldyBhbmQgY29sbGFib3JhdGUgb24gdGhlIG1haWxp bmcgbGlzdCwgb3IgZGlyZWN0IHRvIHRoZSBhdXRob3IuIExvb2tpbmcgZm9yd2FyZCB0byB5b3Vy IGZlZWRiYWNrLg0KPiA+DQo+ID4gTWFueSB0aGFua3MgdG8gUmF5bW9uZCBmb3IgaGlzIGNvbW1l bnRzIG9uIGluaXRpYWwgdmVyc2lvbi4gQW5kIHRoYW5rIHlvdSBpbiBhZHZhbmNlIGZvciB5b3Vy IHRpbWUsDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gWXVxdW4oU2FtKSBDYW8NCj4NCj4N Cj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGlt ZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9m IGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkg cHJpbnRvdXQuDQoNCg== ------=_NextPart_000_001F_01CC03FE.B948BC30 Content-Type: text/plain; name="figure2.TXT" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="figure2.TXT" |<--------E-Tree---------->| | | V V +-----------+ +---------+ Leaf endpoint Root endpoint | PE1 | | PE2 | / +---+ \ | +-----+ | | +---+ | /\ +---+ | | /\ | | | | | | | | | | | | |CE1+-|-------AC1-+--+ V | | | | V +--+-|--- --AC3----+CE3| | | \/(Root AC)| | | | | | | | | | | | +---+ | | +--+-PW12-+--+ S | | | |(Leaf AC) +---+ Leaf endpoint | | S | | | | | | | | +---+ \ | | | | | | I | | | | +---+ | | /\ | | | | | | | | | | | | |CE2+-|-------AC2-+--+ I | | | | +--+-|------AC4----+CE4| | | \/(Leaf AC)| | | | | | | | | | | | +---+ | ++-+-++ | | +-+-+ | \/ (Leaf AC) +---+ +---+-+-+---+ +----+----+ ^ | | | | | |PW13-2 |PW23 | | | | | Root endpoint PW13-1| | |PW13-3 +----+----+ / | | | | | +-+-+ | /\ +---+ | | | | | | +--+-|--------AC5-+CE5| | | | +--------+--+ V | | | |(Root AC)+---+ | | | | | | | | | +---+ | | +----------+--+ S +--+-|------AC6---+CE6| | | | | | | \/ (Root AC)+---+ | +------------+--+ I | | /\ +---+ | | | +--+-AC7------|---|CE7| | | +---+ |Leaf AC \/ +---+ | | PE3 | / | +---------+ Leaf endpoint | ^ | <---------E-Tree-------->| Figure 2 E-Tree typical Reference Model ------=_NextPart_000_001F_01CC03FE.B948BC30-- From xuxh@huawei.com Mon Apr 25 21:02:48 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2454E06CA for ; Mon, 25 Apr 2011 21:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2Zslg6RPajj for ; Mon, 25 Apr 2011 21:02:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B52A0E06D9 for ; Mon, 25 Apr 2011 21:02:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK800HGIR8KX0@szxga05-in.huawei.com> for l2vpn@ietf.org; Tue, 26 Apr 2011 12:02:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK800LK1R8JCR@szxga05-in.huawei.com> for l2vpn@ietf.org; Tue, 26 Apr 2011 12:02:44 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LK8002WIR8JJE@szxml06-in.huawei.com> for l2vpn@ietf.org; Tue, 26 Apr 2011 12:02:43 +0800 (CST) Date: Tue, 26 Apr 2011 12:11:32 +0800 From: Xu Xiaohu Subject: re: Simplified multicast in IS-IS VPLS In-reply-to: <2073A6C5467C99478898544C6EBA3F4602B9449F83@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> To: "'Balus, Florin Stelian (Florin)'" , l2vpn@ietf.org Message-id: <003101cc03c8$070dcff0$15296fd0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acv+ekCk6Bb17WCcQ/KYL4eW3jwpwAAK3jAAABQu2IABG4ZoMAAYPtjw x-cr-hashedpuzzle: ARBA CpuM C20y DuBp D0Dg Eaeo Gbi+ HBJP HZ+m LW90 MjUN Ok0p RPQA U+LF WJva Wb32; 2; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {ADBA1ABD-3913-4D3F-94CA-CE453B7A310D}; eAB1AHgAaABAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 26 Apr 2011 04:11:28 GMT; cgBlADoAIABTAGkAbQBwAGwAaQBmAGkAZQBkACAAbQB1AGwAdABpAGMAYQBzAHQAIABpAG4AIABJAFMALQBJAFMAIABWAFAATABTAA== x-cr-puzzleid: {ADBA1ABD-3913-4D3F-94CA-CE453B7A310D} References: <005101cbfe7a$42037860$c60a6920$@com> <2073A6C5467C99478898544C6EBA3F4602B8B895B2@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <002301cbff00$44dabd60$ce903820$@com> <2073A6C5467C99478898544C6EBA3F4602B9449F83@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:02:48 -0000 > [[FB]] See above there should not be any change in VPLS data plane. Let's focus > on why go through a VPLS control plane change with new IS-IS procedures > versus re-using the IS-IS work already in place in IEEE/IETF. As I said at IETF80, VPLS could be a good option for cloud data center network technology due to its powerful capabilities( e.g., Shortest path forwarding. Equal Cost Multi-Path (ECMP), a large amount of VPN instances (>4096), forwarding table scalability, etc.) and especially the fact that VPLS and IP are much proven and familiar technologies to most operators. However, BGP VPLS [RFC4761] and LDP VPLS [RFC4762] protocols seem a bit heavy-weight. That's why I propose a light-weight VPLS using IS-IS. BR, Xiaohu