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 260733A6A71; Fri, 6 Feb 2009 02:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 SKqrQnIVFczd; Fri, 6 Feb 2009 02:11:18 -0800 (PST) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 4D47F3A692D; Fri, 6 Feb 2009 02:11:18 -0800 (PST) Received: from [192.168.0.101] (h133n2fls33o883.telia.com [217.208.62.133]) (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 E10BA2D81D9; Fri, 6 Feb 2009 11:11:17 +0100 (CET) Message-ID: <498C0CBC.6050400@pi.nu> Date: Fri, 06 Feb 2009 11:11:08 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, ccamp@ops.ietf.org, mpls@ietf.org, pwe3@ietf.org, l2vpn@ietf.org Subject: working group last call on draft-ietf-mpls-tp-requirements-04 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: , X-List-Received-Date: Fri, 06 Feb 2009 10:11:19 -0000 All, this is to initiate a working group last call for draft-ietf-mpls-tp-requirements-04. This document is one of the key documents for the mpls-tp work, in particular it is important that the ITU-T mpls-tp ad hoc team verifies the completeness of the requirements and that we have a good review form all parties. Please review and send your comments to the mpls-tp list, i.e. try to avoid doing a "reply all on this message" ! The working group last call will end on Feb 28, 2009. /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 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 D84CC28C23E; Fri, 6 Feb 2009 07:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 pqqjmCCAsT9o; Fri, 6 Feb 2009 07:20:02 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 026BB28C243; Fri, 6 Feb 2009 07:20:01 -0800 (PST) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 15:20:01 +0000 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Feb 2009 15:20:00 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Feb 2009 15:20:00 +0000 Subject: Re: [PWE3] working group last call on draft-ietf-mpls-tp-requirements-04 From: Ben Niven-Jenkins To: Loa Andersson , , , , , , Message-ID: Thread-Topic: [PWE3] working group last call on draft-ietf-mpls-tp-requirements-04 Thread-Index: AcmIbmBJQHo6yZksOEqy4kWTRLayXQ== In-Reply-To: <498C0CBC.6050400@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Feb 2009 15:20:01.0547 (UTC) FILETIME=[6135DDB0:01C9886E] 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, 06 Feb 2009 15:20:04 -0000 Colleagues, In my rush to get this ready for last call I made an editing mistake, requirement 30 currently reads 30 MPLS-TP MUST support unidirectional, bidirectional and co-routed bidirectional point-to-point transport paths. But it should read 30 MPLS-TP MUST support unidirectional, bidirectional and associated bidirectional point-to-point transport paths. This has no impact in terms of the meaning of the requirement, just an editing error where I updated the terminology section to reflect discussion on the MPLS-TP mailing list but forgot to subsequently update the requirement to use the agreed term. Ben On 06/02/2009 10:11, "Loa Andersson" wrote: > All, > > this is to initiate a working group last call for > draft-ietf-mpls-tp-requirements-04. > > This document is one of the key documents for the mpls-tp work, > in particular it is important that the ITU-T mpls-tp ad hoc team > verifies the completeness of the requirements and that we have a > good review form all parties. > > Please review and send your comments to the mpls-tp list, > i.e. try to avoid doing a "reply all on this message" ! > > The working group last call will end on Feb 28, 2009. > > /Loa 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 5477128C185 for ; Tue, 10 Feb 2009 01:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 j5l2lV0S2Pf4 for ; Tue, 10 Feb 2009 01:30:32 -0800 (PST) Received: from mgw4.noc.ntt.com (mgw4.noc.ntt.com [210.160.15.15]) by core3.amsl.com (Postfix) with ESMTP id DD0693A699D for ; Tue, 10 Feb 2009 01:30:31 -0800 (PST) Received: from mop1.noc.ntt.com by mgw4.noc.ntt.com (NTT-Com MailSV) with ESMTP id n1A9UWVH000700; Tue, 10 Feb 2009 18:30:32 +0900 (JST) Received: from mip01.noc.ntt.com (mvi2.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0KEU000DDFQV4A@ntt.com>; Tue, 10 Feb 2009 18:30:32 +0900 (JST) Date: Tue, 10 Feb 2009 18:30:31 +0900 From: "Yuji KAMITE" Subject: RE: Comments to VPMS Requirements In-reply-to: <787be2780901231336y369bcc54i7d25f671931be506@mail.gmail.com> To: "'Greg Mirsky'" , l2vpn@ietf.org Message-id: <011f01c98b62$37bb7de0$b3d80e0a@coe.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="----=_NextPart_000_0120_01C98BAD.A7A325E0" Thread-index: Acl9ormrP5AFuAsISR6XhidrSu8rLANuM2YA References: <787be2780901231336y369bcc54i7d25f671931be506@mail.gmail.com> 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, 10 Feb 2009 09:30:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0120_01C98BAD.A7A325E0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi Greg, Thanks for comments. See inline below please. _____ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Saturday, January 24, 2009 6:37 AM To: y.kamite@ntt.com Cc: l2vpn@ietf.org Subject: Comments to VPMS Requirements 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." Agreed. * 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. I think you probably mentioned Section 4.3. Section 4.3 describes the use case of multicast clock distribution that master clock is delivered via TDM P2MP-PW. Several end hosts will receive the same TDM channel via p2mp topology efficiently. What kind of actual applications do you assume in "drop-and-continue"? Are you looking at SONET-SDH ring protection's context, TDM-based multicast video delivery usage, or anything else? Could you elaborate the application scenarios a little more if you have? * 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." OK, I'll correct. 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 ..." Agreed. 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." It is just for an explanation about whole framework, i.e., it's shown PSN tunnel is expected to be naturally used as a transport technology for PW in VPMS. I'll consider editorial changes around here to make it more clear. * 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. I think supporting high availability is a basic and important service requirement, so it's worth documenting even though the detailed functional discussion (e.g., about P2MP PW, LSP etc.) are out of the scope in this draft. But I agree with your opinion that Section 6.1.2 largely overlaps with　Section 6.4 now. I'm going to merge/edit to make a unified section about high-availability as much as possible. As you pointed out, redundant (sourc-side) ACes is　actually equivalent to redundant sources. I'll try to change the text. * 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. Yes, this section says, if you want reverse traffic, you need to provision additional VPMS instances for that direction. Or perhaps are you suggesting to write a sort of guideline when and which model you should adopt, VPLS model or VPMS model? 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 ..." I'll correct. * 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. You have a point. This section auto-discovery needs additional consideration in the case multiple-sourced redundancy. It will be addressed in the next revision. * 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. Agreed. Your requirement is important. I think protecting path would probably mean "protecting PW" when you use redundancy in P2MP-PW. Best regards, Yuji Regards, Greg ------=_NextPart_000_0120_01C98BAD.A7A325E0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi = Greg,
 
Thanks for comments.  See inline below=20 please. 
 
 
From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org]=20 On Behalf Of Greg Mirsky
Sent: Saturday, January 24, = 2009=20 6:37 AM
To: y.kamite@ntt.com
Cc:=20 l2vpn@ietf.org
Subject: Comments to VPMS=20 Requirements

Dear Yuji and All,
please find my notes to the document=20 below:
  • Section 4.1
"However, if only P2MP connectivity is required, the traffic = between=20 different receivers is not always needed, and traffic from receiver to = sender=20 is not always needed, either."
I believe that in P2MP constructs=20 connectivity between leafs is not just "not always needed" but = prohibited. To=20 enforce this might require extra efforts if P2MP uses VPLS. I propose = changing=20 this to:
"However, if only P2MP connectivity is required, the = traffic=20 between leafs is not allowed. It might require extra efforts to = guarantee this=20 behavior in VPLS. And in some P2MP scenarios there no traffic from = leafs to=20 root." 
Agreed. 
  • Section 4.2
I'm not sure how second paragraph of the section 4.2 is related = to the=20 subject of P2MP scenarios in TDM. And perhaps "drop-and-continue" = TDM-based=20 applications might be added as one of use cases that can benefit from=20 VPMS. 

I think you probably mentioned Section=20 4.3.
Section 4.3 describes the use case of multicast clock = distribution that=20 master clock is delivered via TDM P2MP-PW.  Several end = hosts
will=20 receive the same TDM channel via p2mp topology=20 efficiently.
 
What kind of = actual=20 applications do you assume in "drop-and-continue"?
Are you looking at = SONET-SDH ring protection's context, TDM-based multicast video delivery = usage,=20 or anything else?
Could you elaborate the application scenarios a little more if you have? 
  • 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=20 SP's network (PE as well as P) has a role to duplicate frames so that = the=20 traffic source does not need to send multiple frames to individual=20 receivers."
I think that it can be clarified as:
"The SP's = network (PE=20 as well as P) has a role to replicate frames so that the sender's CE = does not=20 need to send multiple frames to individual receivers."
 
OK, I'll=20 correct.
 
 
Is following a=20 requirement or a statement:
"In a VPMS, PEs will be connected by PW = technology which may include P2MP traffic optimization ..."
If this = is a=20 statement that perhaps it can be re-worded as more probable wording=20 like
"PW technology with P2MP traffic optimization might be used in = a VPMS=20 ..."
 
Agreed.
 
I don't = understand if=20 following is a requirement or statement of benefit:
"Also routed = backbone=20 provides IP or MPLS-enabled PSN tunnels for transporting the PW = traffic." 
 
It is just = for an=20 explanation about whole framework, i.e., it's shown PSN tunnel is = expected to be=20 naturally used as a transport
technology = for PW in=20 VPMS. I'll consider editorial changes around here to make it more=20 clear.
  • Section 6.1.2 Multiple Source Support
I understand this section as expression of requirement of VPMS's = high=20 availability. Is that correct understanding? If so, then I'd propose = to change=20 the name of the section to "VPMS High Availability" or remove the = section all=20 together since the subject is covered in section 6.4 Protection and=20 Restoration. For one I'd suggest removing reference to support of = multiple=20 senders/sources in VPMS and mention redundant ACes. How to provide = high=20 availability in VPMS, I believe, is outside of the scope of the = document but=20 it is worth mentioning some of possible mechanisms, e.g. redundant = ACes,=20 redundant p2mp PWs, p2mp LSP protection, etc. 
 
 
I think supporting high = availability is a=20 basic and important service requirement, so it's worth documenting even = though the=20 detailed
functional discussion (e.g., about P2MP PW, LSP etc.) are out of the scope in this=20 draft.
 
But I agree with your opinion that Section = 6.1.2=20 largely overlaps with=1B$B!!=1B(BSection 6.4 now. I'm going to merge/edit to make = a=20 unified
section about high-availability  as much as=20 possible.
 
As you pointed out, redundant (sourc-side) = ACes=20 is=1B$B!!=1B(Bactually equivalent to redundant sources.  I'll  try to change the=20 text. 
  • 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=20 instance."
I would argue that this is the simplest and cleanest way = to=20 achieve stated goal because it leads to N reverse VMPSes for a VMPS = with N=20 receivers. I think that if application requires support of revese = traffic then=20 either it should be OOB or use VPLS model instead of VPMS. 
 

Yes, this section says, if you want = reverse=20 traffic, you need to provision additional VPMS instances for = that=20 direction. 
Or perhaps = are you=20 suggesting to write a sort of guideline when and which model you should=20 adopt,
VPLS model or VPMS model? 
 
 

And perhaps = little=20 typo in "That is, the combination between VLAN id and the flow = direction is=20 ..." should be "That is, combination of VLAN id and the flow direction = is=20 ..." 
 

I'll correct. =20  
  • Section 7.3
"Auto-discovery will help operators' initial configuration of = adding a=20 new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, = and so=20 on."
I think that VPMS instance is created when a sender PE (can we = use=20 "s-PE") and at least one receiver PE (r-PE) been added. Without this = minimum=20 requirement VPMS instance does not exist. If that is correct then only = backup=20 s-PE can be dynamically added/deleted to/from VPMS without destroying = the=20 VPN. 
 
You have a = point. =20 This section auto-discovery needs additional consideration in the case=20 multiple-sourced redundancy.
It will be addressed in the next=20 revision.
  • Section 7.7.2 Testing
I think that it is useful to explixitly require ability to test = not only=20 connectivity over working P2MP connection but protecting path(s) as = well from=20 s-PE and, possibly, sender CE.
 
 
Agreed.  Your=20 requirement is important.  
I=20 think protecting path would probably mean "protecting PW" when you use = redundancy in=20 P2MP-PW. 
 
 
Best regards,
Yuji 
 
 
Regards,
Greg

 
 
------=_NextPart_000_0120_01C98BAD.A7A325E0-- 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 8C6813A6A36 for ; Wed, 11 Feb 2009 19:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[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 EEL9tnAJKMfx for ; Wed, 11 Feb 2009 19:12:18 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C584D3A6A0E for ; Wed, 11 Feb 2009 19:12:18 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id BA0AD2684E1; Wed, 11 Feb 2009 20:12:23 -0700 (MST) Received: from mbp.castlepoint.net (71-215-72-111.hlrn.qwest.net [71.215.72.111]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 11 Feb 2009 20:12:23 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.72.111; client-port=2136; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <852318C0-5589-4AA8-A18A-7A357E361B01@castlepoint.net> From: Shane Amante To: l2vpn@ietf.org 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: Fwd: Posting of IPR Disclosure Date: Wed, 11 Feb 2009 20:12:22 -0700 References: <20090211223627.D75D93A6BAA@core3.amsl.com> 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: , X-List-Received-Date: Thu, 12 Feb 2009 03:12:19 -0000 FYI. This doesn't appear to have made it to the list ... -shane Begin forwarded message: > From: IETF Secretariat > Date: February 11, 2009 3:36:27 PM MST > To: "yakov@juniper.net" , "kireeti@juniper.net" > > Cc: "jari.arkko@piuha.net" , > "townsley@cisco.com" , "l2vpn@ietf.org" >, "Amante, Shane" , "vach.kompella@alcatel-lucent.com > " , "ipr-announce@ietf.org" > > Subject: Posting of IPR Disclosure > > Dear Yakov Rekhter, Kireeti Kompella: > > An IPR disclosure that pertains to your RFC entitled "Virtual > Private LAN > Service (VPLS) Using BGP for Auto-discovery and Signaling" (RFC4761) > was > submitted to the IETF Secretariat on 2009-02-10 and has been posted > on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the > IPR > disclosure is "Juniper's Statement of IPR related to RFC 4761." > > The IETF Secretariat > > Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F3C6728C192; Tue, 17 Feb 2009 08:59:54 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Document Action: 'Requirements for Multicast Support in Virtual Private LAN Services' to Informational RFC Message-Id: <20090217165954.F3C6728C192@core3.amsl.com> Date: Tue, 17 Feb 2009 08:59:54 -0800 (PST) Cc: l2vpn mailing list , l2vpn chair , Internet Architecture Board , RFC Editor 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, 17 Feb 2009 16:59:55 -0000 The IESG has approved the following document: - 'Requirements for Multicast Support in Virtual Private LAN Services ' as an Informational RFC This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-07.txt Technical Summary 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. Working Group Summary This document has been reviewed by carriers and experts in the L2VPN WG and there are no outstanding issues. Document Quality This document was reviewed by the l2vpn chairs and Mark Townsley. Personnel Who is the Document Shepherd for this document? Shane Amante (shane@castlepoint.net) Who is the Responsible Area Director? Mark Townsley (townsley@cisco.com) 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 BE48C28C0FF for ; Thu, 19 Feb 2009 08:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 s7DuKSQrsPl0 for ; Thu, 19 Feb 2009 08:59:19 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 3DE9C3A67FA for ; Thu, 19 Feb 2009 08:59:19 -0800 (PST) Received: by fxm11 with SMTP id 11so72774fxm.13 for ; Thu, 19 Feb 2009 08:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gcT73naFTtMjUPaZBhO8HA2bB6M08Fs58endJtF2cN4=; b=ozDk1+j/ZaM+rwWsNoRg9LJy87x560ZhVsGrNNs5prxyhzgqIvRwOQsbq6oQpqKyhy sm2Bp1p1F/SF2njLnTfssqxoHFzGsUjLh0zDSodCoSYI8cRhkxt/mMYGO04y5IXYM5QV u62o6hGxhjPV78Q5+ppjqIXbatRJo4jU38x2w= 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=LByrAB1WU9JymVjQ4nyle65uJUjkS6JbxTmAFitay010f849xGmTh9h1UUyqXASTcg wYnIldG1/WnDfsGO2kK9aL5ODnZ1Eeq9h+4e+RU8VdlmLejQcBgSEikyRsnIpS2WCrHI YPCQb82VKXbOHzmaM17R9S117NEC3XMs4SnAo= MIME-Version: 1.0 Received: by 10.181.202.8 with SMTP id e8mr85551bkq.25.1235062770933; Thu, 19 Feb 2009 08:59:30 -0800 (PST) In-Reply-To: <011f01c98b62$37bb7de0$b3d80e0a@coe.ntt.com> References: <787be2780901231336y369bcc54i7d25f671931be506@mail.gmail.com> <011f01c98b62$37bb7de0$b3d80e0a@coe.ntt.com> Date: Thu, 19 Feb 2009 11:59:30 -0500 Message-ID: <787be2780902190859l517287c3u835b9387ab7eeafb@mail.gmail.com> Subject: Re: Comments to VPMS Requirements From: Greg Mirsky To: Yuji KAMITE Content-Type: multipart/alternative; boundary=0016368e2b20bca18504634875ff 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: Thu, 19 Feb 2009 16:59:20 -0000 --0016368e2b20bca18504634875ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Yuji, thank you for your consideration. Please find my clarifications in-line tagged [GIM] [snip] > > - 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. > > > > I think you probably mentioned Section 4.3. > Section 4.3 describes the use case of multicast clock distribution that > master clock is delivered via TDM P2MP-PW. Several end hosts > will receive the same TDM channel via p2mp topology efficiently. > > What kind of actual applications do you assume in "drop-and-continue"? > Are you looking at SONET-SDH ring protection's context, TDM-based multicast > video delivery usage, or anything else? > Could you elaborate the application scenarios a little more if you have? > [GIM] You're right, it was Section 4.3. I thought of TDM-based video distribution but your study case is perfectly fine for VPMS. [snip] > > > - 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. > > > > Yes, this section says, if you want reverse traffic, you need to provision > additional VPMS instances for that direction. > Or perhaps are you suggesting to write a sort of guideline when and which > model you should adopt, > VPLS model or VPMS model? > > [GIM] I'm concerned that VPMS model doesn't allow it to be used as E-Tree as defined by MEF in Section 6.3 MEF6.1. This is probably neither good nor bad but just a fact. But if we decide that VPMS is essentially unidirectional service, then all applications that require bi-directional commuunication between the root and a leaf are outside of the scope of VPMS and the only model we have in l2vpn now for such applications will be VPLS. Kind regards, Greg --0016368e2b20bca18504634875ff Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 SGkgWXVqaSw8YnI+dGhhbmsgeW91IGZvciB5b3VyIGNvbnNpZGVyYXRpb24uIFBsZWFzZSBmaW5k IG15IGNsYXJpZmljYXRpb25zIGluLWxpbmUgdGFnZ2VkIFtHSU1dPGJyPgogIDxkaXYgZGlyPSJs dHIiIGFsaWduPSJsZWZ0IiBsYW5nPSJqYSI+PGJyPltzbmlwXTwvZGl2PjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXIt bGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAw LjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48ZGl2PjxkaXYgY2xhc3M9IkloMkUzZCI+Cgo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCByZ2IoMCwgMCwgMjU1KTsgcGFk ZGluZy1sZWZ0OiA1cHg7IG1hcmdpbi1sZWZ0OiA1cHg7IG1hcmdpbi1yaWdodDogMHB4OyI+CiAg PHVsPgogICAgPGxpPlNlY3Rpb24gNC4yPC9saT48L3VsPgogIDxkaXY+SSYjMzk7bSBub3Qgc3Vy ZSBob3cgc2Vjb25kIHBhcmFncmFwaCBvZiB0aGUgc2VjdGlvbiA0LjIgaXMgcmVsYXRlZCB0byB0 aGUgCiAgc3ViamVjdCBvZiBQMk1QIHNjZW5hcmlvcyBpbiBURE0uIEFuZCBwZXJoYXBzICZxdW90 O2Ryb3AtYW5kLWNvbnRpbnVlJnF1b3Q7IFRETS1iYXNlZCAKICBhcHBsaWNhdGlvbnMgbWlnaHQg YmUgYWRkZWQgYXMgb25lIG9mIHVzZSBjYXNlcyB0aGF0IGNhbiBiZW5lZml0IGZyb20gCiAgVlBN Uy48c3Bhbj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iGyRCI00jUxsoQiAb JEIlNCU3JUMlLxsoQiI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+Cjwv ZGl2PjxkaXY+PHNwYW4+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwZmYiIGZhY2U9IhskQiNN I1MbKEIgGyRCJTQlNyVDJS8bKEIiPjxicj48Zm9udCBzaXplPSIzIiBmYWNlPSIbJEIjTSNTGyhC IBskQiNQJTQlNyVDJS8bKEIiPkkgdGhpbmsgeW91IHByb2JhYmx5IG1lbnRpb25lZCBTZWN0aW9u IAo0LjMuPGJyPlNlY3Rpb24gNC4zIGRlc2NyaWJlcyB0aGUgdXNlIGNhc2Ugb2YgbXVsdGljYXN0 IGNsb2NrIGRpc3RyaWJ1dGlvbiB0aGF0IAptYXN0ZXIgY2xvY2sgaXMgZGVsaXZlcmVkIHZpYSBU RE0gUDJNUC1QVy4mbmJzcDsgU2V2ZXJhbCBlbmQgaG9zdHM8YnI+d2lsbCAKcmVjZWl2ZSB0aGUg c2FtZSBURE0gY2hhbm5lbCB2aWEgcDJtcCB0b3BvbG9neSAKZWZmaWNpZW50bHkuPC9mb250Pjwv Zm9udD48L3NwYW4+PC9kaXY+CjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjwvZm9udD4mbmJz cDs8L2Rpdj4KPGRpdj48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+V2hhdCBraW5kIG9mIGFj dHVhbCAKYXBwbGljYXRpb25zIGRvIHlvdSBhc3N1bWUgaW4gJnF1b3Q7ZHJvcC1hbmQtY29udGlu dWUmcXVvdDs/PGJyPkFyZSB5b3UgbG9va2luZyBhdCAKU09ORVQtU0RIIHJpbmcgcHJvdGVjdGlv biYjMzk7cyBjb250ZXh0LCBURE0tYmFzZWQgbXVsdGljYXN0IHZpZGVvIGRlbGl2ZXJ5IHVzYWdl LCAKb3IgYW55dGhpbmcgZWxzZT88YnI+Q291bGQgeW91IGVsYWJvcmF0ZSB0aGUgYXBwbGljYXRp b24gc2NlbmFyaW9zIDxzcGFuPmE8L3NwYW4+IDxzcGFuPmxpdHRsZTwvc3Bhbj4gPHNwYW4+bW9y ZTwvc3Bhbj4gaWYgeW91IGhhdmU/Jm5ic3A7IDwvZm9udD48L3NwYW4+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+W0dJTV0gWW91JiMzOTtyZSByaWdodCwgaXQgd2FzIFNlY3Rpb24gNC4z LiBJIHRob3VnaHQgb2YgVERNLWJhc2VkIHZpZGVvIGRpc3RyaWJ1dGlvbiBidXQgeW91ciBzdHVk eSBjYXNlIGlzIHBlcmZlY3RseSBmaW5lIGZvciBWUE1TLjxmb250IGNvbG9yPSIjMDAwMGZmIj48 YnI+Cjxicj5bc25pcF08L2ZvbnQ+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdp bjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+PHNwYW4+PC9zcGFuPjxi cj4KPGRpdiBjbGFzcz0iSWgyRTNkIj48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJw eCBzb2xpZCByZ2IoMCwgMCwgMjU1KTsgcGFkZGluZy1sZWZ0OiA1cHg7IG1hcmdpbi1sZWZ0OiA1 cHg7IG1hcmdpbi1yaWdodDogMHB4OyI+CiAgPHVsPgogICAgPGxpPlNlY3Rpb24gNi4xLjMgUmV2 ZXJzZSBUcmFmZmljIFN1cHBvcnQ8L2xpPjwvdWw+CiAgPGRpdj4mcXVvdDtUaGUgc2ltcGxlc3Qg d2F5IHRvIGFjY29tcGxpc2ggdGhpcyBpcyB0byBwcm92aWRlIGRpZmZlcmVudCBWUE1TIAogIGlu c3RhbmNlcyBmb3IgcmV2ZXJzZSB0cmFmZmljLCBpLmUuIGEgc2VuZGVyIENFIGlzIGEgcmVjZWl2 ZXIgb2YgYW5vdGhlciBWUE1TIAogIGluc3RhbmNlLiZxdW90Ozxicj5JIHdvdWxkIGFyZ3VlIHRo YXQgdGhpcyBpcyB0aGUgc2ltcGxlc3QgYW5kIGNsZWFuZXN0IHdheSB0byAKICBhY2hpZXZlIHN0 YXRlZCBnb2FsIGJlY2F1c2UgaXQgbGVhZHMgdG8gTiByZXZlcnNlIFZNUFNlcyBmb3IgYSBWTVBT IHdpdGggTiAKICByZWNlaXZlcnMuIEkgdGhpbmsgdGhhdCBpZiBhcHBsaWNhdGlvbiByZXF1aXJl cyBzdXBwb3J0IG9mIHJldmVzZSB0cmFmZmljIHRoZW4gCiAgZWl0aGVyIGl0IHNob3VsZCBiZSBP T0Igb3IgdXNlIFZQTFMgbW9kZWwgaW5zdGVhZCBvZiBWUE1TLjxzcGFuPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSIbJEIjTSNTGyhCIBskQiU0JTclQyUvGyhCIj4mbmJzcDs8 L2ZvbnQ+PC9zcGFuPjwvZGl2PgogIDxkaXY+PHNwYW4+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMw MDAwZmYiIGZhY2U9IhskQiNNI1MbKEIgGyRCJTQlNyVDJS8bKEIiPjwvZm9udD48L3NwYW4+Jm5i c3A7PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxzcGFuPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MDAwMGZmIiBmYWNlPSIbJEIjTSNTGyhCIBskQiU0JTclQyUvGyhCIj48L2ZvbnQ+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMwMDAwZmYiIGZhY2U9IhskQiNNI1MbKEIgGyRCJTQlNyVDJS8bKEIiPjwv Zm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iGyRCI00jUxsoQiAbJEIl NCU3JUMlLxsoQiI+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGZmIiBmYWNlPSIb JEIjTSNTGyhCIBskQiU0JTclQyUvGyhCIj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMw MDAwZmYiIGZhY2U9IhskQiNNI1MbKEIgGyRCJTQlNyVDJS8bKEIiPjwvZm9udD48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iGyRCI00jUxsoQiAbJEIlNCU3JUMlLxsoQiI+PC9m b250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGZmIiBmYWNlPSIbJEIjTSNTGyhCIBskQiU0 JTclQyUvGyhCIj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwZmYiIGZhY2U9Ihsk QiNNI1MbKEIgGyRCJTQlNyVDJS8bKEIiPjwvZm9udD4KPGRpdj48YnI+PGZvbnQgY29sb3I9IiMw MDAwZmYiPlllcywgdGhpcyBzZWN0aW9uIHNheXMsIGlmIHlvdSB3YW50IHJldmVyc2UgCnRyYWZm aWMsIHlvdSBuZWVkIHRvIHByb3Zpc2lvbjxzcGFuPiZuYnNwOzwvc3Bhbj5hZGRpdGlvbmFsIFZQ TVMgaW5zdGFuY2VzIGZvciB0aGF0IApkaXJlY3Rpb24uPHNwYW4+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iGyRCI00jUxsoQiAbJEIlNCU3JUMlLxsoQiI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L2ZvbnQ+ PC9kaXY+CjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxzcGFuPk9yIHBlcmhhcHMgYXJlIHlv dSAKc3VnZ2VzdGluZyB0byB3cml0ZSBhIHNvcnQgb2YgZ3VpZGVsaW5lIHdoZW4gYW5kIHdoaWNo IG1vZGVsIHlvdSBzaG91bGQgCmFkb3B0LDxicj5WUExTIG1vZGVsIG9yIFZQTVMgbW9kZWw/Jm5i c3A7PC9zcGFuPjwvZm9udD48L2Rpdj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+PC9mb250Pgo8ZGl2 Pjxmb250IGNvbG9yPSIjMDAwMGZmIj48L2ZvbnQ+PC9kaXY+PC9zcGFuPjxkaXYgY2xhc3M9Iklo MkUzZCI+Jm5ic3A7CjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PltHSU1dIEkmIzM5O20gY29uY2Vy bmVkIHRoYXQgVlBNUyBtb2RlbCBkb2VzbiYjMzk7dCBhbGxvdyBpdCB0byBiZSB1c2VkIGFzIEUt VHJlZSBhcyBkZWZpbmVkIGJ5IE1FRiBpbiBTZWN0aW9uIDYuMyBNRUY2LjEuIFRoaXMgaXMgcHJv YmFibHkgbmVpdGhlciBnb29kIG5vciBiYWQgYnV0IGp1c3QgYSBmYWN0Ljxicj5CdXQgaWYgd2Ug ZGVjaWRlIHRoYXQgVlBNUyBpcyBlc3NlbnRpYWxseSB1bmlkaXJlY3Rpb25hbCBzZXJ2aWNlLCB0 aGVuIGFsbCBhcHBsaWNhdGlvbnMgdGhhdCByZXF1aXJlIGJpLWRpcmVjdGlvbmFsIGNvbW11dW5p Y2F0aW9uIGJldHdlZW4gdGhlIHJvb3QgYW5kIGEgbGVhZiBhcmUgb3V0c2lkZSBvZiB0aGUgc2Nv cGUgb2YgVlBNUyBhbmQgdGhlIG9ubHkgbW9kZWwgd2UgaGF2ZSBpbiBsMnZwbiBub3cgZm9yIHN1 Y2ggYXBwbGljYXRpb25zIHdpbGwgYmUgVlBMUy48YnI+Cjxicj5LaW5kIHJlZ2FyZHMsPGJyPkdy ZWc8YnI+PC9kaXY+PC9kaXY+PGJyPgo= --0016368e2b20bca18504634875ff-- 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 54D773A6A1D for ; Fri, 20 Feb 2009 06:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.306, 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 nMyrp6L7ETNQ for ; Fri, 20 Feb 2009 06:14:56 -0800 (PST) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id E30CB28C156 for ; Fri, 20 Feb 2009 06:14:25 -0800 (PST) Received: from [192.168.0.101] (h133n2fls33o883.telia.com [217.208.62.133]) (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 566912D823F for ; Fri, 20 Feb 2009 15:14:39 +0100 (CET) Message-ID: <499EBAC9.7040608@pi.nu> Date: Fri, 20 Feb 2009 15:14:33 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: the first MPLS-TP RFC 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: , X-List-Received-Date: Fri, 20 Feb 2009 14:14:56 -0000 All, we have our first MPLS-TP RFC: RFC 5317 Title: Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile Author: S. Bryant, Ed., L. Andersson, Ed. Status: Informational Date: February 2009 Mailbox: stbryant@cisco.com, loa@pi.nu Pages: 10, 68 Characters: 18367, 1411313 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-bryant-mpls-tp-jwt-report-00.txt URL: http://www.rfc-editor.org/rfc/rfc5317.txt /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 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 0A0253A684D; Mon, 23 Feb 2009 06:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.246, 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 UvUripcmUqHV; Mon, 23 Feb 2009 06:25:54 -0800 (PST) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 3FF1C3A67B6; Mon, 23 Feb 2009 06:25:54 -0800 (PST) Received: from [192.36.158.94] (wdhcp-158-94.verkstad.net [192.36.158.94]) (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 B538A2D8593; Mon, 23 Feb 2009 15:26:10 +0100 (CET) Message-ID: <49A2B201.8050603@pi.nu> Date: Mon, 23 Feb 2009 15:26:09 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, pwe3@ietf.org, ccamp@ops.ietf.org, l2vpn@ietf.org, Ross Callon , David Ward , ITU-T ad hoc team on MPLS-TP Subject: new mpls(-tp) working group document 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: , X-List-Received-Date: Mon, 23 Feb 2009 14:25:55 -0000 Dear all, the poll for draft-gray-mpls-tp-nm-req to become MPLS WG document has ended with full support. Authors, please republish as: draft-ietf-mpls-tp-nm-req-00 /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 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 EA8D33A6AAA; Thu, 26 Feb 2009 03:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.134, 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 DFUBDeOnsUcQ; Thu, 26 Feb 2009 03:48:56 -0800 (PST) Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 1DE933A69F7; Thu, 26 Feb 2009 03:48:56 -0800 (PST) Received: from [192.36.158.94] (wdhcp-158-94.verkstad.net [192.36.158.94]) (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 AB4BA2D8257; Thu, 26 Feb 2009 12:49:15 +0100 (CET) Message-ID: <49A681B5.6020501@pi.nu> Date: Thu, 26 Feb 2009 12:49:09 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, ITU-T ad hoc team on MPLS-TP , l2vpn@ietf.org, IAB IAB , "Iesg (E-mail)" Subject: RFC 5462 the second MPLS-TP RFC 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: , X-List-Received-Date: Thu, 26 Feb 2009 11:48:57 -0000 All, we have just seen our second mpls-tp RFC being published: RFC5462 'Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field'. /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