From l2vpn-bounces@ietf.org Wed Jan 14 18:30:02 2009 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854D73A6AC3; Wed, 14 Jan 2009 18:30:02 -0800 (PST) X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 402763A6AC3; Wed, 14 Jan 2009 18:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpls-mcast-reqts-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090115023001.402763A6AC3@core3.amsl.com> Date: Wed, 14 Jan 2009 18:30:01 -0800 (PST) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org --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 : Requirements for Multicast Support in Virtual Private LAN Services Author(s) : Y. Kamite, et al. Filename : draft-ietf-l2vpn-vpls-mcast-reqts-07.txt Pages : 31 Date : 2009-01-14 This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-07.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-vpls-mcast-reqts-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-14182224.I-D@ietf.org> --NextPart-- From l2vpn-bounces@ietf.org Wed Jan 14 19:04:25 2009 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32EB3A6AAE; Wed, 14 Jan 2009 19:04:25 -0800 (PST) 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 DBB853A6AAE for ; Wed, 14 Jan 2009 19:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 UurrKPJrwOF4 for ; Wed, 14 Jan 2009 19:04:24 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 3985D3A679F for ; Wed, 14 Jan 2009 19:04:24 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E2D7F2684EA; Wed, 14 Jan 2009 20:04:08 -0700 (MST) Received: from mbp.castlepoint.net (71-215-86-141.hlrn.qwest.net [71.215.86.141]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 14 Jan 2009 20:04:08 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.86.141; client-port=4468; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <7D6365E6-05E1-4D5C-8554-254BAE40B304@castlepoint.net> From: Shane Amante To: l2vpn@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: VPMS Requirements as WG Doc? Date: Wed, 14 Jan 2009 20:04:07 -0700 References: X-Mailer: Apple Mail (2.930.3) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi everyone, We appear to have good support to make this draft a WG doc. Yuji: can you please republish this as: draft-ietf-l2vpn-vpms-frmwk-requirements-00 Thanks, -shane On Nov 20, 2008, at 6:41 PM, Shane Amante wrote: > Hi all, > > At this morning's L2VPN WG meeting, Yuji presented the latest > updates and changes on the VPMS requirements draft: > http://tools.ietf.org/html/draft-kamite-l2vpn-vpms-frmwk-requirements-02 > > We would now like to poll the WG mailing list and ask two questions: > 1) Is there support for making this a WG document? > 2) Are there WG members who support making this a WG document that > will volunteer to be reviewers as the doc progresses through WG > reviews, WG Last Call, etc.? > > Thanks, > > -shane & Vach From l2vpn-bounces@ietf.org Mon Jan 19 07:15:02 2009 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C100728C1D5; Mon, 19 Jan 2009 07:15:02 -0800 (PST) X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CB81E28C1D5; Mon, 19 Jan 2009 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpms-frmwk-requirements-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090119151501.CB81E28C1D5@core3.amsl.com> Date: Mon, 19 Jan 2009 07:15:01 -0800 (PST) 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org --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 : Framework and Requirements for Virtual Private Multicast Service (VPMS) Author(s) : Y. Kamite, et al. Filename : draft-ietf-l2vpn-vpms-frmwk-requirements-00.txt Pages : 23 Date : 2009-01-18 This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpms-frmwk-requirements-00.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-vpms-frmwk-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-19070347.I-D@ietf.org> --NextPart-- From l2vpn-bounces@ietf.org Fri Jan 23 13:37:10 2009 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A87B3A685F; Fri, 23 Jan 2009 13:37:10 -0800 (PST) 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 EC3F13A680D for ; Fri, 23 Jan 2009 13:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qWpScKYde8cz for ; Fri, 23 Jan 2009 13:37:07 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id F32B53A67F3 for ; Fri, 23 Jan 2009 13:37:06 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 13so2625679fge.41 for ; Fri, 23 Jan 2009 13:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=GK9DzjOAK4r9KP6COSgypqJn4QdmgCLRV54fUvrsguU=; b=DHFxrwLA2QzNcUGmAwbG+/74NEsZePT7ciDFJ8IxdMXB5JkRBZKpLu7stXqpt+4uva q/42orPsKla/qqhIXzyr5eu8gNWKHsAjQ05bgZkFQAhoA0nSPId281d0CEEpSFOT7dYv H3ASipBd6g3TXpE+on1P5uvQ+75eCax3kpNGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=vJ2oVi1zFFHHZSMghhzdp/LvOojT188wTYcwRk9xjNBruCcZUBTiwhby7zrposNeso lX9xO4Ws8nHrycJI5Hw0vRZ9l33vFUx1XlXdnsuy8D0w7+RHjosnXpKPJGFtdaDHVQL/ uO+39hQ1MQDdqJCnMSnIyGuy4M/bQ1wEokG2g= MIME-Version: 1.0 Received: by 10.181.144.11 with SMTP id w11mr758836bkn.81.1232746608182; Fri, 23 Jan 2009 13:36:48 -0800 (PST) Date: Fri, 23 Jan 2009 16:36:47 -0500 Message-ID: <787be2780901231336y369bcc54i7d25f671931be506@mail.gmail.com> Subject: Comments to VPMS Requirements From: Greg Mirsky To: y.kamite@ntt.com Content-Type: multipart/alternative; boundary=00163646be02adc59204612d2f5e 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org --00163646be02adc59204612d2f5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Yuji and All, please find my notes to the document below: - Section 4.1 "However, if only P2MP connectivity is required, the traffic between different receivers is not always needed, and traffic from receiver to sender is not always needed, either." I believe that in P2MP constructs connectivity between leafs is not just "not always needed" but prohibited. To enforce this might require extra efforts if P2MP uses VPLS. I propose changing this to: "However, if only P2MP connectivity is required, the traffic between leafs is not allowed. It might require extra efforts to guarantee this behavior in VPLS. And in some P2MP scenarios there no traffic from leafs to root." - Section 4.2 I'm not sure how second paragraph of the section 4.2 is related to the subject of P2MP scenarios in TDM. And perhaps "drop-and-continue" TDM-based applications might be added as one of use cases that can benefit from VPMS. - Section 5 Following seems somewhat ambiguous since frames might not be just duplicated but replicated multiple times on the same node (PE or P) "The SP's network (PE as well as P) has a role to duplicate frames so that the traffic source does not need to send multiple frames to individual receivers." I think that it can be clarified as: "The SP's network (PE as well as P) has a role to replicate frames so that the sender's CE does not need to send multiple frames to individual receivers." Is following a requirement or a statement: "In a VPMS, PEs will be connected by PW technology which may include P2MP traffic optimization ..." If this is a statement that perhaps it can be re-worded as more probable wording like "PW technology with P2MP traffic optimization might be used in a VPMS ..." I don't understand if following is a requirement or statement of benefit: "Also routed backbone provides IP or MPLS-enabled PSN tunnels for transporting the PW traffic." - Section 6.1.2 Multiple Source Support I understand this section as expression of requirement of VPMS's high availability. Is that correct understanding? If so, then I'd propose to change the name of the section to "VPMS High Availability" or remove the section all together since the subject is covered in section 6.4 Protection and Restoration. For one I'd suggest removing reference to support of multiple senders/sources in VPMS and mention redundant ACes. How to provide high availability in VPMS, I believe, is outside of the scope of the document but it is worth mentioning some of possible mechanisms, e.g. redundant ACes, redundant p2mp PWs, p2mp LSP protection, etc. - Section 6.1.3 Reverse Traffic Support "The simplest way to accomplish this is to provide different VPMS instances for reverse traffic, i.e. a sender CE is a receiver of another VPMS instance." I would argue that this is the simplest and cleanest way to achieve stated goal because it leads to N reverse VMPSes for a VMPS with N receivers. I think that if application requires support of revese traffic then either it should be OOB or use VPLS model instead of VPMS. And perhaps little typo in "That is, the combination between VLAN id and the flow direction is ..." should be "That is, combination of VLAN id and the flow direction is ..." - Section 7.3 "Auto-discovery will help operators' initial configuration of adding a new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, and so on." I think that VPMS instance is created when a sender PE (can we use "s-PE") and at least one receiver PE (r-PE) been added. Without this minimum requirement VPMS instance does not exist. If that is correct then only backup s-PE can be dynamically added/deleted to/from VPMS without destroying the VPN. - Section 7.7.2 Testing I think that it is useful to explixitly require ability to test not only connectivity over working P2MP connection but protecting path(s) as well from s-PE and, possibly, sender CE. Regards, Greg --00163646be02adc59204612d2f5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Yuji and All,
please find my notes to the document below:
    Section 4.1
"However, if only P2MP connectivity is required, the traffic between different receivers is not always needed, and traffic from receiver to sender is not always needed, either."
I believe that in P2MP constructs connectivity between leafs is not just "not always needed" but prohibited. To enforce this might re= quire extra efforts if P2MP uses VPLS. I propose changing this to:
"Howev= er, if only P2MP connectivity is required, the traffic between leafs is not allowed. It might require extra efforts to guarantee this behavior in VPLS. And in some P2MP scenarios there no traffic from leafs to root."=
  • Section 4.2
I'm not sure how second paragraph of the section 4.2 is related to the subject of P2MP scenarios in TDM. And perhaps "drop-and-continue" TDM-based applications might be added= as one of use cases that can benefit from VPMS.
  • Section 5
= Following seems somewhat ambiguous since frames might not be just duplicated but replicated multiple times on the same node (PE or P)
"The SP's network (PE as well as P) has= a role to duplicate frames so that the traffic source does not need to send multiple frames to individual receivers."
I think that it can be clarified as:
"The SP's network (PE as w= ell as P) has a role to replicate frames so that the sender's CE does not need to send multiple frames to individual receivers."

Is following a requirement or a statemen= t:
"In a VPMS, PEs will be connected by PW technology which may inc= lude P2MP traffic optimization ..."
If this is a statement that per= haps it can be re-worded as more probable wording like
"PW technology with P2MP traffic optimization might be used in a VPMS = ..."

I don't understand if following is a requirement or st= atement of benefit:
"Also routed backbone provides IP or MPLS-enabl= ed PSN tunnels for transporting the PW traffic."
  • Section 6.1.2 Multiple Source Support
I understand this se= ction as expression of requirement of VPMS's high availability. Is that= correct understanding? If so, then I'd propose to change the name of t= he section to "VPMS High Availability" or remove the section all = together since the subject is covered in section 6.4 Protection and Restora= tion. For one I'd suggest removing reference to support of multiple sen= ders/sources in VPMS and mention redundant ACes. How to provide high availa= bility in VPMS, I believe, is outside of the scope of the document but it i= s worth mentioning some of possible mechanisms, e.g. redundant ACes, redund= ant p2mp PWs, p2mp LSP protection, etc.
  • Section 6.1.3 Reverse Traffic Support
"The simplest w= ay to accomplish this is to provide different VPMS instances for reverse t= raffic, i.e. a sender CE is a receiver of another VPMS instance." I would argue that this is the simplest and cleanest way to achieve stated = goal because it leads to N reverse VMPSes for a VMPS with N receivers. I th= ink that if application requires support of revese traffic then either it s= hould be OOB or use VPLS model instead of VPMS.

And perhaps little typo in "That is, the combination between VLAN= id and the flow direction is ..." should be "That is, combination of VLAN id and the flow dire= ction is ..."
  • Section 7.3
"Auto-discovery wil= l help operators' initial configuration of adding a new VPN (i.e., VPM= S instance), adding/deleting new sender/receiver, and so on."
I think that VPMS instance is created when a sender PE (can we use "s-= PE") and at least one receiver PE (r-PE) been added. Without this mini= mum requirement VPMS instance does not exist. If that is correct then only = backup s-PE can be dynamically added/deleted to/from VPMS without destroyin= g the VPN.
  • Section 7.7.2 Testing
I think that it is useful to explixi= tly require ability to test not only connectivity over working P2MP connect= ion but protecting path(s) as well from s-PE and, possibly, sender CE.

Regards,
Greg


--00163646be02adc59204612d2f5e-- From l2vpn-bounces@ietf.org Mon Jan 26 05:44:37 2009 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D46B28C212; Mon, 26 Jan 2009 05:44:37 -0800 (PST) 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 C9C5228C212 for ; Mon, 26 Jan 2009 05:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 UYEbXBf5d5R2 for ; Mon, 26 Jan 2009 05:44:36 -0800 (PST) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 8941028C1FB for ; Mon, 26 Jan 2009 05:44:36 -0800 (PST) Received: from [192.36.158.123] (wdhcp-158-123.verkstad.net [192.36.158.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 11A092D812C for ; Mon, 26 Jan 2009 14:44:18 +0100 (CET) Message-ID: <497DBE30.3010804@pi.nu> Date: Mon, 26 Jan 2009 14:44:16 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: the mpls-tp mailing list is the consensus list for mpls-tp isseus Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org All, we have agreed with our ADs that the mpl-tp@ietf.org shall be used as the consensus list for mpls-tp related drafts and issues. We will still send generic announcements lie this one or working group last cal to the relevant working group mailing lists, but the discussions should be taken to the mpls-tp list. (Cross-) working group consensus will be decided based on the discussion on the mpls-tp list. /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu