From web-usrn@ISI.EDU Tue Nov 3 10:13:27 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC693A6A50 for ; Tue, 3 Nov 2009 10:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.188 X-Spam-Level: X-Spam-Status: No, score=-17.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 6XKbEQqrI6fz for ; Tue, 3 Nov 2009 10:13:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id EDA813A6994 for ; Tue, 3 Nov 2009 10:13:26 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nA3IBOFo015241; Tue, 3 Nov 2009 10:11:25 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nA3IBLH9015213; Tue, 3 Nov 2009 10:11:21 -0800 (PST) Date: Tue, 3 Nov 2009 10:11:21 -0800 (PST) Message-Id: <200911031811.nA3IBLH9015213@boreas.isi.edu> To: matthew.bocci@alcatel-lucent.com, martin.vigoureux@alcatel-lucent.com, stbryant@cisco.com, rcallon@juniper.net, adrian.farrel@huawei.com, swallow@cisco.com, loa@pi.nu From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: rfc-editor@rfc-editor.org, mpls@ietf.org Subject: [mpls] [Technical Errata Reported] RFC5586 (1940) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:13:28 -0000 The following errata report has been submitted for RFC5586, "MPLS Generic Associated Channel". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=1940 -------------------------------------- Type: Technical Reported by: Matthew Bocci Section: 10 Original Text ------------- In order to support this requirement, IANA has changed the code point allocation scheme for the PW Associated Channel Type be changed as follows: 0 - 32751 : IETF Review 32760 - 32767 : Experimental Corrected Text -------------- In order to support this requirement, IANA has changed the code point allocation scheme for the PW Associated Channel Type be changed as follows: 0 - 32759 : IETF Review 32760 - 32767 : Experimental 32768 - 65535 : IETF Review Notes ----- There are some gaps in the specified allocation policy for some parts of the ACH channel type range (32752 to 32759 and 32768 to 65535). The channel type is a 16-bit value, and the IANA considerations section of RFC5586 should be updated to reflect this. I propose that the correction should be to clarify that the allocation policy for the code points that have been left out of RFC5586 is IETF review (which I believe reflects the WG consensus at the time of publication), and to leave the Experimental range where it is to avoid impacting current implementations. This also requires an update by IANA to the PW ACH Channel Type registry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5586 (draft-ietf-mpls-tp-gach-gal-06) -------------------------------------- Title : MPLS Generic Associated Channel Publication Date : June 2009 Author(s) : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From Adrian.Farrel@huawei.com Tue Nov 3 15:04:41 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEF03A67E7; Tue, 3 Nov 2009 15:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599, STOX_REPLY_TYPE=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 utmNQvpzcueK; Tue, 3 Nov 2009 15:04:41 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 14BD43A6778; Tue, 3 Nov 2009 15:04:41 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSK00KPE2SDRB@usaga03-in.huawei.com>; Tue, 03 Nov 2009 17:05:01 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSK00KWV2S9NM@usaga03-in.huawei.com>; Tue, 03 Nov 2009 17:05:01 -0600 (CST) Date: Tue, 03 Nov 2009 23:04:41 +0000 From: Adrian Farrel To: pwe3@ietf.org, mpls@ietf.org, mpls-tp@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: Ross Callon , BOCCI Matthew Subject: [mpls] Erratum for RFC 5586 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 23:04:42 -0000 All, Matthew Bocci has reported an Erratum for RFC 5586 that can be viewed at http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=1940) The IANA considerations section (section 10) as published says that the code point allocation scheme for the PW Associated Channel Type is... 0 - 32751 : IETF Review 32760 - 32767 : Experimental This leaves an unexplained gap in the code points for 32752 to 32759, and also does not explain what happens for values above 32767. The Erratum fixes the allocation to read: 0 - 32759 : IETF Review 32760 - 32767 : Experimental 32768 - 65535 : IETF Review This choice is made to keep the Experimental range where it has already been defined (so as not to impact any existing implementations) and to cover the rest of the codepoints. IANA have confirmed that they can update the registry to reflect this change on the strength of the Erratum without us publishing any further documents. At this time, I need to hear from the people working in this area (PWE3, MPLS, and MPLS-TP) if this change is *not* acceptable. Please send comments to the mpls-tp list only (mpls-tp@ietf.org) or unicast to me. I will let this comment period run until 20th November. Thanks, Adrian From rahul@juniper.net Wed Nov 4 09:20:25 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F393A68A8 for ; Wed, 4 Nov 2009 09:20:25 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc7YTM07i5tq for ; Wed, 4 Nov 2009 09:20:24 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id E173E3A69DA for ; Wed, 4 Nov 2009 09:20:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSvG3z6lEbp6m/iZUcPGMBdNML2IQ0YKb@postini.com; Wed, 04 Nov 2009 09:20:46 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 4 Nov 2009 09:12:47 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:12:48 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:12:47 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:12:46 -0800 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 nA4HClj06007; Wed, 4 Nov 2009 09:12:47 -0800 (PST) (envelope-from rahul@juniper.net) Date: Wed, 4 Nov 2009 09:12:46 -0800 From: Rahul Aggarwal To: Eric Rosen In-Reply-To: <19676.1256913773@erosen-linux> Message-ID: <20091104082901.W19863@sapphire.juniper.net> References: <19676.1256913773@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-OriginalArrivalTime: 04 Nov 2009 17:12:46.0971 (UTC) FILETIME=[07A9E4B0:01CA5D72] Cc: mpls@ietf.org Subject: Re: [mpls] Last Call comments on ldp upstream label allocation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:20:25 -0000 Hi Eric, Thanks for the comments. Please see below: On Fri, 30 Oct 2009, Eric Rosen wrote: > > I have a couple of comments on draft-ietf-mpls-ldp-upstream-04. > > The draft has a normative reference to RFC 3472 "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution > Protocol (CR-LDP) Extensions". I don't think this is allowable, as we do > not want to take any action that prevents the deprecated CR-LDP documents > from being reclassified as historic. > > Section 4.3 of RFC 3468 "The Multiprotocol Label Switching (MPLS) Working Group > decision on MPLS signaling protocols" says: > > Consequently we need to keep CR-LDP referenceable, i.e., on the > standards track, for the foreseeable future. The implication of this > is not that we need to progress it further, or need to undertake > further work in the area. One implication however is that standards > organizations which reference the document, need to be notified of > our decision so that they (at their own pace) can change their > references to more appropriate documents. > > I would interpret this as implying that the IETF should not be creating > normative references to CR-LDP documents. (If we expect other organizations > to be changing their references to the CR-LDP documents, we shouldn't be > creating new references to them.) Note that RFC 3468 explicitly calls out > RFC 3472 as one of the deprecated documents. > > The normative reference is due to the draft's reuse of the "Interface ID > TLV" defined in RFC 3472. If this TLV is to be used, it would be better to > define it in the ldp-upstream draft and to have IANA change the reference in > the iana.org registry. > It is not clear that we have a problem with the draft's reference of the "Interface ID TLV" (as defined in rfc3472). This is because rfc3468 makes it very clear that CR-LDP is "referenceable, i.e., on the standards track, for the foreseeable future", and thus there should be no problem for us to reference rfc3472. > However, it is questionable whether the Interface ID TLV is really the right > TLV for ldp-upstream to use, as the interface ID TLV has fields that are do > not appear to be needed in ldp-upstream (e.g., "next/previous hop", "logical > inteface id"). > The issue with the next/previous hop and logical interface id is easy to fix. If there are no objections from the WG, then I will specify in the LDP upstream draft that the next/previous hop and logical interface id should be set to 0 by the sender and ignored by the receiver. > One more comment: the "LDP Tunnel Identifiers" defined in section 5 of > ldp-upstream do not appear to be exactly the same in all cases as the "PMSI > Tunnel Attribute Tunnel Identifiers" defined in section 5 of draft-ietf- > l3vpn-2547bis-mcast-bgp-08.txt. (E.g., the means of identification of > RSVP-TE tunnels seems to be different.) I will replace "1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of he TLV is the RSVP-TE P2MP Session Object and optionally the P2MP Sender Template Object [RFC4875]." with: "1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object [RFC4875]." rahul From lufang@cisco.com Wed Nov 4 19:59:14 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CE43A67D7 for ; Wed, 4 Nov 2009 19:59:14 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxAMc-FNbxD5 for ; Wed, 4 Nov 2009 19:59:13 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CB82A3A67A3 for ; Wed, 4 Nov 2009 19:59:13 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/c8UpAZnwN/2dsb2JhbADGEpdbAoQ7BA X-IronPort-AV: E=Sophos;i="4.44,684,1249257600"; d="scan'208";a="425165974" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2009 03:59:35 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA53xZik029791; Thu, 5 Nov 2009 03:59:35 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 22:59:35 -0500 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 Date: Wed, 4 Nov 2009 22:59:34 -0500 Message-ID: In-Reply-To: <4ADED0B3.2070106@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-lu-ldp-igp-sync-bcast-01an mpls wgdocument Thread-Index: AcpSLsSki2zhCy8iThm/L985VE7RNALnY3zQ References: <4ADED0B3.2070106@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , X-OriginalArrivalTime: 05 Nov 2009 03:59:35.0523 (UTC) FILETIME=[635CFB30:01CA5DCC] Subject: Re: [mpls] poll on making draft-lu-ldp-igp-sync-bcast-01an mpls wgdocument X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 03:59:14 -0000 yes/support. Luyuan=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 21 October 2009 05:13 To: mpls@ietf.org Subject: [mpls] poll on making draft-lu-ldp-igp-sync-bcast-01an mpls wgdocument Working Group, the authors of draft-lu-ldp-igp-sync-bcast-01.txt has requested that the document is accepted as a working group document. This mail starts a two week poll on making the draft a working group document. Send a mail to the mpls@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content should be sent to the same mailing list with a different subject line. The poll ends Fri Nov 6. /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yakov@juniper.net Fri Nov 6 04:35:35 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776A73A69B4 for ; Fri, 6 Nov 2009 04:35:35 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuSGPwZ+sQVS for ; Fri, 6 Nov 2009 04:35:34 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 670D63A69A3 for ; Fri, 6 Nov 2009 04:35:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSvQYLGhjhF0pU+rtLSE3LNE6DfxKkYn+@postini.com; Fri, 06 Nov 2009 04:35:58 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 6 Nov 2009 04:33:19 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:33:20 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:33:19 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:33:19 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA6CXIj49945 for ; Fri, 6 Nov 2009 04:33:18 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911061233.nA6CXIj49945@magenta.juniper.net> To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82974.1257510798.1@juniper.net> Date: Fri, 6 Nov 2009 04:33:18 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 06 Nov 2009 12:33:19.0304 (UTC) FILETIME=[522E7480:01CA5EDD] Subject: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:35:35 -0000 Folks, At the last IETF I asked the authors to explicitly spell out the applicability of this draft to various "flavors" of PIM. The latest version of the draft (-02) still does not address this. To address this I propose to insert the following in the Introduction section of the draft: The procedures specified in this draft are sufficient to support IP multicast with PIM-SM in SSM mode. The procedures specified in this draft are insufficient to support IP multicast with PIM-SM in ASM mode for the reason mentioned in section 2.3 of this draft. The procedures specified in this draft do not support IP multicast with PIM-DM. Yakov. From yakov@juniper.net Fri Nov 6 04:39:47 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756123A677D for ; Fri, 6 Nov 2009 04:39:47 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh5CQc7rYQWj for ; Fri, 6 Nov 2009 04:39:46 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id ADF333A698F for ; Fri, 6 Nov 2009 04:39:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSvQZInmSpcQl80yvQ0/5RAl9Wr08sZeK@postini.com; Fri, 06 Nov 2009 04:40:03 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 6 Nov 2009 04:36:09 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:36:09 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:36:08 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:36:08 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA6Ca7j50883 for ; Fri, 6 Nov 2009 04:36:07 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911061236.nA6Ca7j50883@magenta.juniper.net> To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83249.1257510967.1@juniper.net> Date: Fri, 6 Nov 2009 04:36:07 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 06 Nov 2009 12:36:08.0329 (UTC) FILETIME=[B6ED9F90:01CA5EDD] Subject: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - RP discovery X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:39:47 -0000 Folks, At the last IETF I asked the authors to address the issue of RP discovery. The latest version of the draft (-02) still does not address this. I would suggest that the draft either (a) has to restrict RP discovery to just static RP, or (b) spell out the procedures for running BSR over an MPLS infrastructure. Yakov. From yakov@juniper.net Fri Nov 6 04:42:46 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5308C3A69CB for ; Fri, 6 Nov 2009 04:42:46 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d6RrlfqjXPu for ; Fri, 6 Nov 2009 04:42:45 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 45D663A677D for ; Fri, 6 Nov 2009 04:42:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSvQZ3O+41okzrufzKCS4IYbbXTdTFsiX@postini.com; Fri, 06 Nov 2009 04:43:09 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 6 Nov 2009 04:38:09 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:38:10 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:38:09 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 04:38:08 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA6Cc7j51322 for ; Fri, 6 Nov 2009 04:38:07 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911061238.nA6Cc7j51322@magenta.juniper.net> To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83443.1257511087.1@juniper.net> Date: Fri, 6 Nov 2009 04:38:07 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 06 Nov 2009 12:38:08.0122 (UTC) FILETIME=[FE5495A0:01CA5EDD] Subject: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:42:46 -0000 Folks, Last IETF at MPLS WG meeting I asked the authors to clarify the procedures for handling PIM-Bidir sender-only branches with mLDP in-band signaling. The latest (-02) version of the draft still does not address this in sufficient level of details. >From section 1 of that draft: When an IP multicast tree (either a source-specific tree or a bidirectional tree) enters the MPLS network, the IP multicast control messages used to set up the tree are translated into mLDP messages. In the case where we have PIM-Bidir sender-only branches (that do not originate any PIM Join messages) what are "the IP multicast control messages used to set up the tree", and how do these messages get "translated into mLDP messages" ? >From section 2.2 of that draft: 2.2. Transiting IP multicast bidirectional trees Bidirectional IP multicast trees [RFC5015] MUST be transported across a MPLS network using MP2MP LSPs. A bidirectional tree does not have a specific source address; only the group address and subnet mask are relevant for multicast forwarding. The RP for the group already known by IP multicast is used to select the ingress PE and root of the LSP. The group address is encoded in either Section 3.3 or Section 3.4, depending on the IP version. The subnet mask associated with the bidirectional group is encoded in the Transit TLV. There are two types of bidirection states in IP multicast, the group specific state and the RPA state. The first type is typlically created due to receiving a PIM join and has a subnet mask of 32 for IPv4 and 128 for IPv6, the latter is typically created via the RP mapping protocol and has a variable subnet mask. The RPA state is used to build a tree to the RP and used for sender only branches. Please see [RFC5015] for more details. The above talks about "the group specific state" and "the RPA state", Could some of the branches of an MP2MP LSP be associated with just the RPA state, while other branches of the *same* MP2MP LSP be associated with the group specific state ? In other words, could some branches of an MP2MP LSP be signaled using Transit IPv4 Bidir TLV with mask length less than 32 (the branches associated with the RPA state), while some other branches of *the same* MP2MP LSP be signaled using Transit IPv4 Bidir TLV with mask length 32 (the branches associated with the group specific state) ? If yes, then what are the procedures at the nodes where the branches of the MP2MP LSP that are associated with just the RPA state merge into the part of the *same* MP2MP LSP that is associated with just the group specific state ? Yakov. From erosen@cisco.com Fri Nov 6 10:25:42 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5FD3A68DE for ; Fri, 6 Nov 2009 10:25:42 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZWLpdQz9OtY for ; Fri, 6 Nov 2009 10:25:41 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 94DC83A6824 for ; Fri, 6 Nov 2009 10:25:41 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208";a="66801136" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Nov 2009 18:26:04 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6IQ42e007669; Fri, 6 Nov 2009 18:26:04 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id nA6IQ4iG021574; Fri, 6 Nov 2009 13:26:04 -0500 To: Rahul Aggarwal In-reply-to: Your message of Wed, 04 Nov 2009 09:12:46 -0800. <20091104082901.W19863@sapphire.juniper.net> Date: Fri, 06 Nov 2009 13:26:04 -0500 Message-ID: <21573.1257531964@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org Subject: Re: [mpls] Last Call comments on ldp upstream label allocation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 18:25:42 -0000 RFC3468> Consequently we need to keep CR-LDP referenceable, i.e., on the RFC3468> standards track, for the foreseeable future. The implication of this RFC3468> is not that we need to progress it further, or need to undertake RFC3468> further work in the area. One implication however is that standards RFC3468> organizations which reference the document, need to be notified of RFC3468> our decision so that they (at their own pace) can change their RFC3468> references to more appropriate documents. Eric> I would interpret this as implying that the IETF should not be Eric> creating normative references to CR-LDP documents. (If we expect Eric> other organizations to be changing their references to the CR-LDP Eric> documents, we shouldn't be creating new references to them.) Note Eric> that RFC 3468 explicitly calls out RFC 3472 as one of the deprecated Eric> documents. Rahul> It is not clear that we have a problem with the draft's reference of Rahul> the "Interface ID TLV" (as defined in rfc3472). This is because Rahul> rfc3468 makes it very clear that CR-LDP is "referenceable, i.e., on Rahul> the standards track, for the foreseeable future", and thus there Rahul> should be no problem for us to reference rfc3472. It seems to me to be quite clear that the intention is for the CR-LDP documents to continue to be "referenceable" by pre-3468 documents, and that normative references by post-3468 IETF drafts are not "appropriate". If you're determined for some reason to keep this normative reference to CR-LDP, I suppose my next step is to ask the WG chairs for a ruling on this. WG chairs, do you have an opinion on this process issue? Your proposed resolutions to my other comments are fine. From Martin.Vigoureux@alcatel-lucent.com Fri Nov 6 14:36:11 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9C53A67FA; Fri, 6 Nov 2009 14:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=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 l6prGY4SbDG9; Fri, 6 Nov 2009 14:36:10 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 58CF23A67B0; Fri, 6 Nov 2009 14:36:09 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA6MaWgr019219; Fri, 6 Nov 2009 23:36:32 +0100 Received: from [135.244.34.165] ([135.244.34.165]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 23:36:31 +0100 Message-ID: <4AF4A4E7.2050908@alcatel-lucent.com> Date: Fri, 06 Nov 2009 23:36:23 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2009 22:36:32.0205 (UTC) FILETIME=[96D4DFD0:01CA5F31] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: [mpls] MPLS WG Sessions agenda (please start sending slides) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:36:11 -0000 All, you can find the most recent agenda at: http://www.ietf.org/proceedings/09nov/agenda/mpls.txt Please start sending me your slides. Please also note that some mpls-tp drafts will be discussed during the Friday PWE3 session. regards, martin From ice@cisco.com Sat Nov 7 17:34:18 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887C93A681B for ; Sat, 7 Nov 2009 17:34:18 -0800 (PST) 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 JofE8SWQvzv9 for ; Sat, 7 Nov 2009 17:34:17 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 75DD73A6878 for ; Sat, 7 Nov 2009 17:34:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA81UuVV023585; Sun, 8 Nov 2009 02:30:56 +0100 (CET) Received: from tky-vpn-client-230-172.cisco.com (tky-vpn-client-230-172.cisco.com [10.70.230.172]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA81UqxG008007; Sun, 8 Nov 2009 02:30:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911061233.nA6CXIj49945@magenta.juniper.net> Date: Sun, 8 Nov 2009 02:30:46 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:34:18 -0000 Yakov, > At the last IETF I asked the authors to explicitly spell out the > applicability of this draft to various "flavors" of PIM. > > The latest version of the draft (-02) still does not address this. > To address this I propose to insert the following in the Introduction > section of the draft: > > The procedures specified in this draft are sufficient to support > IP multicast with PIM-SM in SSM mode. The procedures specified That is too restrictive. > in this draft are insufficient to support IP multicast with > PIM-SM in ASM mode for the reason mentioned in section 2.3 of This prevents receiving a (S,G) from the P2MP LSP and send it down the (*,G) PIM tree. This is the behavior we want to support in combination with out-of-band source discovery via MSDP. The only thing we want to restrict is transport (*,G) traffic down the P2MP LSP, that is covered by section 2.3. > this draft. The procedures specified in this draft do not support > IP multicast with PIM-DM. This is fine, I can add that. Thx, Ice. From ice@cisco.com Sat Nov 7 17:40:44 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD1C3A67A8 for ; Sat, 7 Nov 2009 17:40:44 -0800 (PST) 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 9FCtKXx5-pZv for ; Sat, 7 Nov 2009 17:40:43 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 79DEF3A681B for ; Sat, 7 Nov 2009 17:40:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA81f6C7001227; Sun, 8 Nov 2009 02:41:06 +0100 (CET) Received: from tky-vpn-client-230-172.cisco.com (tky-vpn-client-230-172.cisco.com [10.70.230.172]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA81f3Rf012048; Sun, 8 Nov 2009 02:41:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911061236.nA6Ca7j50883@magenta.juniper.net> Date: Sun, 8 Nov 2009 02:40:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200911061236.nA6Ca7j50883@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - RP discovery X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:40:44 -0000 Yakov, > At the last IETF I asked the authors to address the issue of RP > discovery. The latest version of the draft (-02) still does not > address this. > > I would suggest that the draft either (a) has to restrict RP discovery > to just static RP, or (b) spell out the procedures for running BSR > over an MPLS infrastructure. For transporting (S,G) traffic down a P2MP LSP there is no need to have an RP. For the (*,G) tree to be build towards the MPLS egress PE its necessary to have an RP. I'm ok to restrict the RP discovery to static for that. I'll add that in the next revision. Thx, Ice. From ice@cisco.com Sat Nov 7 18:05:41 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9FF3A6822 for ; Sat, 7 Nov 2009 18:05:41 -0800 (PST) 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 AqCBHEidkiwF for ; Sat, 7 Nov 2009 18:05:40 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 3471C3A6767 for ; Sat, 7 Nov 2009 18:05:40 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA8263Bc020125; Sun, 8 Nov 2009 03:06:03 +0100 (CET) Received: from tky-vpn-client-230-172.cisco.com (tky-vpn-client-230-172.cisco.com [10.70.230.172]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA825vSU022324; Sun, 8 Nov 2009 03:05:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911061238.nA6Cc7j51322@magenta.juniper.net> Date: Sun, 8 Nov 2009 03:05:51 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200911061238.nA6Cc7j51322@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 02:05:41 -0000 Yakov, > > In the case where we have PIM-Bidir sender-only branches (that do not > originate any PIM Join messages) what are "the IP multicast control > messages used to set up the tree", and how do these messages get > "translated into mLDP messages" ? In PIM this will result in two different trees, one tree that represents the (*,G) for the receivers, the other being the (*,G/M) for the senders. The same will be true for mLDP. There will be two MP2MP LSPs, one encoding (*,G), the other (*,G/M). The only thing that we are doing is translate the PIM state into a mLDP LSP. This is what is described in section 2.2. > >> From section 2.2 of that draft: > > 2.2. Transiting IP multicast bidirectional trees > > Bidirectional IP multicast trees [RFC5015] MUST be transported > across > a MPLS network using MP2MP LSPs. A bidirectional tree does not have > a specific source address; only the group address and subnet mask > are > relevant for multicast forwarding. The RP for the group already > known by IP multicast is used to select the ingress PE and root of > the LSP. The group address is encoded in either Section 3.3 or > Section 3.4, depending on the IP version. The subnet mask > associated > with the bidirectional group is encoded in the Transit TLV. There > are two types of bidirection states in IP multicast, the group > specific state and the RPA state. The first type is typlically > created due to receiving a PIM join and has a subnet mask of 32 for > IPv4 and 128 for IPv6, the latter is typically created via the RP > mapping protocol and has a variable subnet mask. The RPA state is > used to build a tree to the RP and used for sender only branches. > Please see [RFC5015] for more details. > > The above talks about "the group specific state" and "the RPA state", > > Could some of the branches of an MP2MP LSP be associated with just > the RPA state, while other branches of the *same* MP2MP LSP be > associated with the group specific state ? In other words, could Yes. > some branches of an MP2MP LSP be signaled using Transit IPv4 Bidir > TLV with mask length less than 32 (the branches associated with the > RPA state), while some other branches of *the same* MP2MP LSP be > signaled using Transit IPv4 Bidir TLV with mask length 32 (the > branches associated with the group specific state) ? Yes. > > If yes, then what are the procedures at the nodes where the branches > of the MP2MP LSP that are associated with just the RPA state merge > into the part of the *same* MP2MP LSP that is associated with just > the group specific state ? This is documented in RFC5015 section 3.1.4. Its not mLDP's functionality to merge the 2 trees together, this is done in PIM. Let me know if this addresses your concerns. I will also update the bidir section to state the RP discovery is via static configuration. Thanks for the comments, Ice. From loa@pi.nu Sun Nov 8 01:57:32 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6ED83A67D7; Sun, 8 Nov 2009 01:57:32 -0800 (PST) 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 71BjtQ6srC4w; Sun, 8 Nov 2009 01:57:32 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 2E71C3A67B5; Sun, 8 Nov 2009 01:57:32 -0800 (PST) Received: from [133.93.17.10] (host-17-10.meeting.ietf.org [133.93.17.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 2856BD404F; Sun, 8 Nov 2009 10:57:53 +0100 (CET) Message-ID: <4AF69619.5030807@pi.nu> Date: Sun, 08 Nov 2009 10:57:45 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 09:57:33 -0000 WG, the working group chairs have decided to make draft-sprecher-mpls-tp-oam-analysis-07.txt an mpls working group draft. Could the authors please republish as draft-ietf-mpls-tp-oam-analysis-00.txt Loa and George -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Sun Nov 8 02:02:16 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A983A6980; Sun, 8 Nov 2009 02:02:16 -0800 (PST) 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 PlAJqnLyTvO3; Sun, 8 Nov 2009 02:02:16 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 1D98A3A6971; Sun, 8 Nov 2009 02:02:16 -0800 (PST) Received: from [133.93.17.10] (host-17-10.meeting.ietf.org [133.93.17.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B91A9D404F; Sun, 8 Nov 2009 11:02:38 +0100 (CET) Message-ID: <4AF69737.3000305@pi.nu> Date: Sun, 08 Nov 2009 11:02:31 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] two new working group drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 10:02:17 -0000 Working group, we have consensus to accept draft-swallow-mpls-tp-identifiers-02 and draft-lu-ldp-igp-sync-bcast-01.txt as mpls working group drafts, could the authors please republish as: draft-ietf-mpls-tp-identifiers-00 and draft-ietf-ldp-igp-sync-bcast-00.txt /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From tnadeau@lucidvision.com Sun Nov 8 04:48:12 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38C23A6956; Sun, 8 Nov 2009 04:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 j03CrVjR4Ouk; Sun, 8 Nov 2009 04:48:11 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 30B243A68F7; Sun, 8 Nov 2009 04:48:11 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 33C1741B750B; Sun, 8 Nov 2009 07:48:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Thomas Nadeau In-Reply-To: <4AF69619.5030807@pi.nu> Date: Sun, 8 Nov 2009 07:48:34 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4AF69619.5030807@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1076) Cc: mpls@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 12:48:12 -0000 Did the chairs also agree to take into account any of the objections or suggestions that were made, or did you decide to accept it as-is? --Tom > WG, > > the working group chairs have decided to make > draft-sprecher-mpls-tp-oam-analysis-07.txt > an mpls working group draft. > > Could the authors please republish as > > draft-ietf-mpls-tp-oam-analysis-00.txt > > Loa and George > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From yakov@juniper.net Sun Nov 8 06:16:26 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916DE3A69A1 for ; Sun, 8 Nov 2009 06:16:26 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiPE0Ju1yEwH for ; Sun, 8 Nov 2009 06:16:25 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 587323A6954 for ; Sun, 8 Nov 2009 06:16:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSvbS0f2ynaXMsw5o0P/3ky7duwYCCSvO@postini.com; Sun, 08 Nov 2009 06:16:51 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 8 Nov 2009 06:16:14 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:16:14 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:16:13 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:16:13 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA8EGBj36753; Sun, 8 Nov 2009 06:16:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911081416.nA8EGBj36753@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: References: <200911061238.nA6Cc7j51322@magenta.juniper.net> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Sun, 08 Nov 2009 03:05:51 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18913.1257689770.1@juniper.net> Date: Sun, 8 Nov 2009 06:16:11 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 08 Nov 2009 14:16:13.0192 (UTC) FILETIME=[06EE8080:01CA607E] Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 14:16:26 -0000 Ice, > > In the case where we have PIM-Bidir sender-only branches (that do not > > originate any PIM Join messages) what are "the IP multicast control > > messages used to set up the tree", and how do these messages get > > "translated into mLDP messages" ? > > In PIM this will result in two different trees, one tree that > represents the (*,G) for the receivers, the other being the (*,G/M) > for the senders. The same will be true for mLDP. There will be two > MP2MP LSPs, one encoding (*,G), the other (*,G/M). The only thing that > we are doing is translate the PIM state into a mLDP LSP. This is what > is described in section 2.2. That still does not answer the question I asked above. Namely, what are "the IP multicast control messages used to set up the tree", and how do these messages get "translated into mLDP messages" when we have mp2mp LSP for (*, G/M)? > >> From section 2.2 of that draft: > > > > 2.2. Transiting IP multicast bidirectional trees > > > > Bidirectional IP multicast trees [RFC5015] MUST be transported across > > a MPLS network using MP2MP LSPs. A bidirectional tree does not have > > a specific source address; only the group address and subnet mask are > > relevant for multicast forwarding. The RP for the group already > > known by IP multicast is used to select the ingress PE and root of > > the LSP. The group address is encoded in either Section 3.3 or > > Section 3.4, depending on the IP version. The subnet mask associated > > with the bidirectional group is encoded in the Transit TLV. There > > are two types of bidirection states in IP multicast, the group > > specific state and the RPA state. The first type is typlically > > created due to receiving a PIM join and has a subnet mask of 32 for > > IPv4 and 128 for IPv6, the latter is typically created via the RP > > mapping protocol and has a variable subnet mask. The RPA state is > > used to build a tree to the RP and used for sender only branches. > > Please see [RFC5015] for more details. > > > > The above talks about "the group specific state" and "the RPA state", > > > > Could some of the branches of an MP2MP LSP be associated with just > > the RPA state, while other branches of the *same* MP2MP LSP be > > associated with the group specific state ? In other words, could > > Yes. Your answer contradicts your own statement you made above, namely, In PIM this will result in two different trees, one tree that represents the (*,G) for the receivers, the other being the (*,G/M) for the senders. The same will be true for mLDP. There will be two MP2MP LSPs, one encoding (*,G), the other (*,G/M). > > some branches of an MP2MP LSP be signaled using Transit IPv4 Bidir > > TLV with mask length less than 32 (the branches associated with the > > RPA state), while some other branches of *the same* MP2MP LSP be > > signaled using Transit IPv4 Bidir TLV with mask length 32 (the > > branches associated with the group specific state) ? > > Yes. see my previous comment. > > If yes, then what are the procedures at the nodes where the branches > > of the MP2MP LSP that are associated with just the RPA state merge > > into the part of the *same* MP2MP LSP that is associated with just > > the group specific state ? > > This is documented in RFC5015 section 3.1.4. Its not mLDP's > functionality to merge the 2 trees together, this is done in PIM. Does that mean that the merge point has to run PIM ? > Let me know if this addresses your concerns. No this does not address my concerns - see above. Yakov. From yakov@juniper.net Sun Nov 8 06:31:39 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994A03A67B2 for ; Sun, 8 Nov 2009 06:31:39 -0800 (PST) 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.000, 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 SpWWdf5sqhyz for ; Sun, 8 Nov 2009 06:31:38 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id A0A863A677D for ; Sun, 8 Nov 2009 06:31:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSvbWYyDTCEITc/JPdD/7U/kxtw/BnodP@postini.com; Sun, 08 Nov 2009 06:32:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 8 Nov 2009 06:31:45 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:31:45 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:31:44 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:31:43 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA8EVhj41501; Sun, 8 Nov 2009 06:31:43 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911081431.nA8EVhj41501@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Sun, 08 Nov 2009 02:30:46 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19970.1257690703.1@juniper.net> Date: Sun, 8 Nov 2009 06:31:43 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 08 Nov 2009 14:31:43.0936 (UTC) FILETIME=[31B2C400:01CA6080] Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 14:31:39 -0000 Ice, > > At the last IETF I asked the authors to explicitly spell out the > > applicability of this draft to various "flavors" of PIM. > > > > The latest version of the draft (-02) still does not address this. > > To address this I propose to insert the following in the Introduction > > section of the draft: > > > > The procedures specified in this draft are sufficient to support > > IP multicast with PIM-SM in SSM mode. The procedures specified > > That is too restrictive. > > > in this draft are insufficient to support IP multicast with > > PIM-SM in ASM mode for the reason mentioned in section 2.3 of > > This prevents receiving a (S,G) from the P2MP LSP and send it down the > (*,G) PIM tree. This is the behavior we want to support in combination > with out-of-band source discovery via MSDP. The only thing we want to > restrict is transport (*,G) traffic down the P2MP LSP, that is covered > by section 2.3. Then the draft should explicitly spell out "the behavior we want to support", *and* the mechanisms/procedures to support such behavior, including the interaction with the out-of-band source discovery via MSDP. Yakov. From sboutros@cisco.com Sun Nov 8 16:32:50 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B043A6A21 for ; Sun, 8 Nov 2009 16:32:50 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAzxZAKQKdQM for ; Sun, 8 Nov 2009 16:32:49 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5624528C0D9 for ; Sun, 8 Nov 2009 16:32:49 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoGAEfy9kqrRN+K/2dsb2JhbACCHzGFSbsOljiCO4IDBA X-IronPort-AV: E=Sophos;i="4.44,705,1249257600"; d="scan'208,217";a="427761071" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2009 00:33:15 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nA90XF4W009596; Mon, 9 Nov 2009 00:33:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 16:33:15 -0800 Received: from sboutros-wxp.ciswco.com ([10.21.81.86]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 16:33:14 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Nov 2009 16:33:08 -0800 To: dai.xuehui@zte.com.cn, wu.bo@zte.com.cn, yang_jian@zte.com.cn From: Sami Boutros Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2418500==.ALT" Message-ID: X-OriginalArrivalTime: 09 Nov 2009 00:33:14.0225 (UTC) FILETIME=[392FD610:01CA60D4] Cc: mpls@ietf.org, "Siva Sivabalan \(msiva\)" Subject: [mpls] draft-dai-mpls-tp-lock-instruct-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:32:50 -0000 --=====================_2418500==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Xuehui, Bo, Jian, The draft seems to cover what we already covered in http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02 4.4.2. Lock The Lock operation is used to take an LSP out of service for mainte- nance. The Lock operation is carried in an MPLS Loopback request message sent from a MEP to a trail-end MEP of the LSP to request that the LSP be taken out of service. In response, the Lock operation is carried in an Loopback response message sent from the trail-end MEP back to the originating MEP to report the result. 4.4.3. Unlock The Unlock operation is used to restore a previously locked LSP to service. The Unlock operation is carried in an MPLS Loopback request message sent from a MEP to a trail-end MEP of the LSP to request that the LSP be restored to service. In response, the Unlock operation is carried in an Loopback Response message sent from the trail-end MEP back to the originating MEP to report the result. Thanks, Sami --=====================_2418500==.ALT Content-Type: text/html; charset="us-ascii" Hi 
Xuehui, Bo, Jian,
The draft seems to cover what we already covered in http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02

4.4.2. Lock

   The Lock operation is used to take an LSP out of service for mainte-
   nance.  The Lock operation is carried in an MPLS Loopback request
   message sent from a MEP to a trail-end MEP of the LSP to request that
   the LSP be taken out of service.  In response, the Lock operation is
   carried in an Loopback response message sent from the trail-end MEP
   back to the originating MEP to report the result.


4.4.3. Unlock

   The Unlock operation is used to restore a previously locked LSP to
   service.  The Unlock operation is carried in an MPLS Loopback request
   message sent from a MEP to a trail-end MEP of the LSP to request that
   the LSP be restored to service.  In response, the Unlock operation is
   carried in an Loopback Response message sent from the trail-end MEP
   back to the originating MEP to report the result.

Thanks,

Sami
--=====================_2418500==.ALT-- From ice@cisco.com Sun Nov 8 19:42:20 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAC93A6A95 for ; Sun, 8 Nov 2009 19:42:20 -0800 (PST) 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=[AWL=0.000, 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 tgoraVJqgVbt for ; Sun, 8 Nov 2009 19:42:19 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9576428C0EC for ; Sun, 8 Nov 2009 19:42:13 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA93crCq018510; Mon, 9 Nov 2009 04:38:53 +0100 (CET) Received: from tky-vpn-client-230-168.cisco.com (tky-vpn-client-230-168.cisco.com [10.70.230.168]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA93cpMw026260; Mon, 9 Nov 2009 04:38:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911081416.nA8EGBj36753@magenta.juniper.net> Date: Mon, 9 Nov 2009 12:38:45 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <200911061238.nA6Cc7j51322@magenta.juniper.net> <200911081416.nA8EGBj36753@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:42:20 -0000 Yakov, > That still does not answer the question I asked above. Namely, what > are "the IP multicast control messages used to set up the tree", > and how do these messages get "translated into mLDP messages" when > we have mp2mp LSP for (*, G/M)? PIM messages are not translated into mLDP messages. I think that is the key point of the mis-understanding. You translate multicast routing state into mLDP messages. So if the MRIB has (*,G) it encodes it into a mLDP FEC, if it has (*,G/M) is does the same. That also makes the solution independent of PIM, MSDP or IGMP. Any multicast protocol that can populate the MRIB can be used to create a mLDP LSP. > > Your answer contradicts your own statement you made above, namely, Correct, I mis interpreted your question. There will be different MP2MP LSPs. >> >> This is documented in RFC5015 section 3.1.4. Its not mLDP's >> functionality to merge the 2 trees together, this is done in PIM. > > Does that mean that the merge point has to run PIM ? Yes, it will by default because this is the Ingress PE/Root of the P2MP LSP that borders with the IP PIM network. > >> Let me know if this addresses your concerns. > > No this does not address my concerns - see above. Did we make progress? Thx, Ice. From ice@cisco.com Sun Nov 8 19:57:53 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2349128C11A for ; Sun, 8 Nov 2009 19:57:53 -0800 (PST) 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 uULs9kanFXZK for ; Sun, 8 Nov 2009 19:57:52 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 2834C28B56A for ; Sun, 8 Nov 2009 19:57:52 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA93d09B018588; Mon, 9 Nov 2009 04:39:00 +0100 (CET) Received: from tky-vpn-client-230-168.cisco.com (tky-vpn-client-230-168.cisco.com [10.70.230.168]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA93cpMx026260; Mon, 9 Nov 2009 04:38:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911081431.nA8EVhj41501@magenta.juniper.net> Date: Mon, 9 Nov 2009 12:38:48 +0900 Content-Transfer-Encoding: 7bit Message-Id: <45661C01-5325-4A3E-B10D-A79F7E57CF8C@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> <200911081431.nA8EVhj41501@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:57:53 -0000 Yakov, >> This prevents receiving a (S,G) from the P2MP LSP and send it down >> the >> (*,G) PIM tree. This is the behavior we want to support in >> combination >> with out-of-band source discovery via MSDP. The only thing we want to >> restrict is transport (*,G) traffic down the P2MP LSP, that is >> covered >> by section 2.3. > > Then the draft should explicitly spell out "the behavior we want > to support", *and* the mechanisms/procedures to support such behavior, > including the interaction with the out-of-band source discovery via > MSDP. There are no additional mechanisms/procedures to support this behavior. This is basic PIM Sparse-mode behavior. Maybe this goes back to my comment on the other email, that PIM messages are not translated into mLDP messages. The multicast routing state is used to drive the creating of the mLDP LSPs. Thx, Ice. From loa@pi.nu Sun Nov 8 21:15:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A483A6ABE; Sun, 8 Nov 2009 21:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 nnhUuvGcD7iD; Sun, 8 Nov 2009 21:15:33 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id CA9703A6A83; Sun, 8 Nov 2009 21:15:32 -0800 (PST) Received: from [133.93.17.10] (host-17-10.meeting.ietf.org [133.93.17.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 820D0D404F; Mon, 9 Nov 2009 06:15:55 +0100 (CET) Message-ID: <4AF7A584.2030308@pi.nu> Date: Mon, 09 Nov 2009 06:15:48 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Nadeau References: <4AF69619.5030807@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:15:33 -0000 Tom, this is a very curious question, the statement is clear. Documents are always accepted as is. That is not to say that the working group might not revise it, in fact that is the intention with having the working group taking over revision control. /Loa Thomas Nadeau wrote: > > Did the chairs also agree to take into account any of the objections > or suggestions that were made, or did you decide to accept it as-is? > > --Tom > > >> WG, >> >> the working group chairs have decided to make >> draft-sprecher-mpls-tp-oam-analysis-07.txt >> an mpls working group draft. >> >> Could the authors please republish as >> >> draft-ietf-mpls-tp-oam-analysis-00.txt >> >> Loa and George >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From yang_jian@zte.com.cn Sun Nov 8 22:07:16 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791EA3A69BD for ; Sun, 8 Nov 2009 22:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.598 X-Spam-Level: X-Spam-Status: No, score=-91.598 tagged_above=-999 required=5 tests=[AWL=-1.409, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 jLb3tabWDfGM for ; Sun, 8 Nov 2009 22:07:15 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E1E663A6867 for ; Sun, 8 Nov 2009 22:07:14 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 11164806486374; Mon, 9 Nov 2009 13:39:57 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 16639.2442755200; Mon, 9 Nov 2009 13:54:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id nA965D6i084215; Mon, 9 Nov 2009 14:05:22 +0800 (CST) (envelope-from yang_jian@zte.com.cn) In-Reply-To: To: Sami Boutros MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: yang_jian@zte.com.cn Date: Mon, 9 Nov 2009 14:06:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-11-09 14:05:12, Serialize complete at 2009-11-09 14:05:12 Content-Type: multipart/alternative; boundary="=_alternative 00216C3B48257669_=" X-MAIL: mse1.zte.com.cn nA965D6i084215 Cc: mpls@ietf.org, "Siva Sivabalan \(msiva\)" , su.hui@zte.com.cn Subject: [mpls] =?gb2312?b?tPC4tDogZHJhZnQtZGFpLW1wbHMtdHAtbG9jay1pbnN0?= =?gb2312?b?cnVjdC0wMA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:07:16 -0000 This is a multipart message in MIME format. --=_alternative 00216C3B48257669_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FtaaOsDQoNClRoYW5rcyBmb3IgeW91ciBjb25jZXJucyBhYm91dCBvdXIgZHJhZnQuDQoN CldlIGhhdmUgcmVhZCB5b3VyIGRyYWZ0IGRyYWZ0LWJvdXRyb3MtbXBscy10cC1sb29wYmFjay0w Mi4gSW4geW91ciBkcmFmdCwgDQp0aGUgTG9jayBpbmZvcm1hdGlvbiBpcyBpbmNsdWRlZCBpbiB0 aGUgTG9vcGJhY2sgTWVzc2FnZS4gQnV0IHdlIHRoaW5rIA0KTG9jayBzaG91bGQgYmUgYW4gaW5k ZXBlbmRlbnQgT0FNIHRvb2wgYW5kIG5vdCBhbHdheSBhY2NvbXBhbnkgbG9vcGJhY2suIA0KQmVj YXVzZSB0aGVyZSBhcmUgc29tZSBvdGhlciBhcHBsaWNhdGlvbnMgdXNpbmcgTG9jaywgZm9yIGV4 YW1wbGUgdGhlIA0Kb3V0LW9mLXNlcnZpY2UgcGVyZm9ybWFuY2UgbW9uaXRvci4gSXQgYWxzbyBj YW4gYmUgaW5pdGlhdGVkIGJ5IG1hbmFnZW1lbnQgDQpwbGFuZS4NClNvIHdlIHN1Ym1pdHRlZCBh IGRyYWZ0IHdoaWNoIG9ubHkgdGFsa3MgYWJvdXQgbG9jayBvcGVyYXRpb24uDQoNCg0KSmlhbg0K DQoNCg0KDQoNClNhbWkgQm91dHJvcyA8c2JvdXRyb3NAY2lzY28uY29tPiANCjIwMDktMTEtMDkg MDg6MzMNCg0KytW8/sjLDQpkYWkueHVlaHVpQHp0ZS5jb20uY24sIHd1LmJvQHp0ZS5jb20uY24s IHlhbmdfamlhbkB6dGUuY29tLmNuDQqzrcvNDQoiR2VvcmdlIFN3YWxsb3ciIDxzd2FsbG93QGNp c2NvLmNvbT4sICJTaXZhIFNpdmFiYWxhbiAobXNpdmEpIiANCjxtc2l2YUBjaXNjby5jb20+LCBt cGxzQGlldGYub3JnDQrW98ziDQpkcmFmdC1kYWktbXBscy10cC1sb2NrLWluc3RydWN0LTAwDQoN Cg0KDQoNCg0KDQpIaSANClh1ZWh1aSwgQm8sIEppYW4sDQoNCg0KVGhlIGRyYWZ0IHNlZW1zIHRv IGNvdmVyIHdoYXQgd2UgYWxyZWFkeSBjb3ZlcmVkIGluIA0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYm91dHJvcy1tcGxzLXRwLWxvb3BiYWNrLTAyDQoNCjQuNC4yLiBMb2NrDQoN CiAgIFRoZSBMb2NrIG9wZXJhdGlvbiBpcyB1c2VkIHRvIHRha2UgYW4gTFNQIG91dCBvZiBzZXJ2 aWNlIGZvciBtYWludGUtDQogICBuYW5jZS4gIFRoZSBMb2NrIG9wZXJhdGlvbiBpcyBjYXJyaWVk IGluIGFuIE1QTFMgTG9vcGJhY2sgcmVxdWVzdA0KICAgbWVzc2FnZSBzZW50IGZyb20gYSBNRVAg dG8gYSB0cmFpbC1lbmQgTUVQIG9mIHRoZSBMU1AgdG8gcmVxdWVzdCB0aGF0DQogICB0aGUgTFNQ IGJlIHRha2VuIG91dCBvZiBzZXJ2aWNlLiAgSW4gcmVzcG9uc2UsIHRoZSBMb2NrIG9wZXJhdGlv biBpcw0KICAgY2FycmllZCBpbiBhbiBMb29wYmFjayByZXNwb25zZSBtZXNzYWdlIHNlbnQgZnJv bSB0aGUgdHJhaWwtZW5kIE1FUA0KICAgYmFjayB0byB0aGUgb3JpZ2luYXRpbmcgTUVQIHRvIHJl cG9ydCB0aGUgcmVzdWx0Lg0KDQoNCjQuNC4zLiBVbmxvY2sNCg0KICAgVGhlIFVubG9jayBvcGVy YXRpb24gaXMgdXNlZCB0byByZXN0b3JlIGEgcHJldmlvdXNseSBsb2NrZWQgTFNQIHRvDQogICBz ZXJ2aWNlLiAgVGhlIFVubG9jayBvcGVyYXRpb24gaXMgY2FycmllZCBpbiBhbiBNUExTIExvb3Bi YWNrIHJlcXVlc3QNCiAgIG1lc3NhZ2Ugc2VudCBmcm9tIGEgTUVQIHRvIGEgdHJhaWwtZW5kIE1F UCBvZiB0aGUgTFNQIHRvIHJlcXVlc3QgdGhhdA0KICAgdGhlIExTUCBiZSByZXN0b3JlZCB0byBz ZXJ2aWNlLiAgSW4gcmVzcG9uc2UsIHRoZSBVbmxvY2sgb3BlcmF0aW9uIGlzDQogICBjYXJyaWVk IGluIGFuIExvb3BiYWNrIFJlc3BvbnNlIG1lc3NhZ2Ugc2VudCBmcm9tIHRoZSB0cmFpbC1lbmQg TUVQDQogICBiYWNrIHRvIHRoZSBvcmlnaW5hdGluZyBNRVAgdG8gcmVwb3J0IHRoZSByZXN1bHQu DQoNClRoYW5rcywNCg0KU2FtaQ0KDQoNCg== --=_alternative 00216C3B48257669_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48Zm9udCBzaXpl PTM+U2FtaTwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o6w8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBj b25jZXJucyBhYm91dCBvdXIgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5XZSBoYXZlIHJlYWQgeW91ciBkcmFmdCA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsdWU+PHU+ZHJhZnQtYm91dHJvcy1tcGxzLXRwLWxvb3BiYWNrLTAyPC91Pjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Lg0KSW4geW91ciBkcmFmdCwgdGhl IExvY2sgaW5mb3JtYXRpb24gaXMgaW5jbHVkZWQgaW4gdGhlIDwvZm9udD48Zm9udCBzaXplPTM+ PHR0Pkxvb3BiYWNrDQpNZXNzYWdlPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPi4gQnV0IHdlIHRoaW5rICZuYnNwO0xvY2sNCnNob3VsZCBiZSBhbiBpbmRlcGVuZGVu dCBPQU0gdG9vbCBhbmQgbm90IGFsd2F5IGFjY29tcGFueSBsb29wYmFjay4gQmVjYXVzZQ0KdGhl cmUgYXJlIHNvbWUgb3RoZXIgYXBwbGljYXRpb25zIHVzaW5nIExvY2ssIGZvciBleGFtcGxlIHRo ZSBvdXQtb2Ytc2VydmljZQ0KcGVyZm9ybWFuY2UgbW9uaXRvci4gSXQgYWxzbyBjYW4gYmUgaW5p dGlhdGVkIGJ5IG1hbmFnZW1lbnQgcGxhbmUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5TbyB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCB3aGljaCBvbmx5IHRhbGtzDQph Ym91dCBsb2NrIG9wZXJhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkppYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5TYW1pIEJvdXRyb3MgJmx0O3Nib3V0cm9zQGNpc2NvLmNvbSZndDs8L2I+ DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0xMS0wOSAw ODozMzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5kYWkueHVlaHVpQHp0ZS5jb20uY24sIHd1LmJvQHp0ZS5jb20uY24sDQp5YW5nX2ppYW5A enRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7R2VvcmdlIFN3YWxsb3cmcXVvdDsg Jmx0O3N3YWxsb3dAY2lzY28uY29tJmd0OywNCiZxdW90O1NpdmEgU2l2YWJhbGFuIChtc2l2YSkm cXVvdDsgJmx0O21zaXZhQGNpc2NvLmNvbSZndDssIG1wbHNAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPmRyYWZ0LWRhaS1tcGxzLXRwLWxvY2staW5zdHJ1Y3QtMDA8L2ZvbnQ+PC90YWJsZT4N Cjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SGkgPC9mb250Pg0KPGJyPjxm b250IHNpemU9Mz48dHQ+WHVlaHVpLCBCbywgSmlhbiw8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+VGhlIGRyYWZ0IHNlZW1zIHRvIGNvdmVyIHdoYXQgd2UgYWxyZWFk eSBjb3ZlcmVkIGluIDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ib3V0cm9zLW1wbHMtdHAtbG9vcGJhY2stMDIiPjxmb250IHNpemU9MyBjb2xvcj1ibHVl Pjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdXRyb3MtbXBscy10cC1sb29w YmFjay0wMjxicj4NCjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo0LjQuMi4gTG9j azxicj4NCjxicj4NCiAmbmJzcDsgVGhlIExvY2sgb3BlcmF0aW9uIGlzIHVzZWQgdG8gdGFrZSBh biBMU1Agb3V0IG9mIHNlcnZpY2UgZm9yIG1haW50ZS08YnI+DQogJm5ic3A7IG5hbmNlLiAmbmJz cDtUaGUgTG9jayBvcGVyYXRpb24gaXMgY2FycmllZCBpbiBhbiBNUExTIExvb3BiYWNrDQpyZXF1 ZXN0PGJyPg0KICZuYnNwOyBtZXNzYWdlIHNlbnQgZnJvbSBhIE1FUCB0byBhIHRyYWlsLWVuZCBN RVAgb2YgdGhlIExTUCB0byByZXF1ZXN0DQp0aGF0PGJyPg0KICZuYnNwOyB0aGUgTFNQIGJlIHRh a2VuIG91dCBvZiBzZXJ2aWNlLiAmbmJzcDtJbiByZXNwb25zZSwgdGhlIExvY2sgb3BlcmF0aW9u DQppczxicj4NCiAmbmJzcDsgY2FycmllZCBpbiBhbiBMb29wYmFjayByZXNwb25zZSBtZXNzYWdl IHNlbnQgZnJvbSB0aGUgdHJhaWwtZW5kDQpNRVA8YnI+DQogJm5ic3A7IGJhY2sgdG8gdGhlIG9y aWdpbmF0aW5nIE1FUCB0byByZXBvcnQgdGhlIHJlc3VsdC48YnI+DQo8YnI+DQo8YnI+DQo0LjQu My4gVW5sb2NrPGJyPg0KPGJyPg0KICZuYnNwOyBUaGUgVW5sb2NrIG9wZXJhdGlvbiBpcyB1c2Vk IHRvIHJlc3RvcmUgYSBwcmV2aW91c2x5IGxvY2tlZCBMU1ANCnRvPGJyPg0KICZuYnNwOyBzZXJ2 aWNlLiAmbmJzcDtUaGUgVW5sb2NrIG9wZXJhdGlvbiBpcyBjYXJyaWVkIGluIGFuIE1QTFMgTG9v cGJhY2sNCnJlcXVlc3Q8YnI+DQogJm5ic3A7IG1lc3NhZ2Ugc2VudCBmcm9tIGEgTUVQIHRvIGEg dHJhaWwtZW5kIE1FUCBvZiB0aGUgTFNQIHRvIHJlcXVlc3QNCnRoYXQ8YnI+DQogJm5ic3A7IHRo ZSBMU1AgYmUgcmVzdG9yZWQgdG8gc2VydmljZS4gJm5ic3A7SW4gcmVzcG9uc2UsIHRoZSBVbmxv Y2sgb3BlcmF0aW9uDQppczxicj4NCiAmbmJzcDsgY2FycmllZCBpbiBhbiBMb29wYmFjayBSZXNw b25zZSBtZXNzYWdlIHNlbnQgZnJvbSB0aGUgdHJhaWwtZW5kDQpNRVA8YnI+DQogJm5ic3A7IGJh Y2sgdG8gdGhlIG9yaWdpbmF0aW5nIE1FUCB0byByZXBvcnQgdGhlIHJlc3VsdC48YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KPGJyPg0KU2FtaTwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 00216C3B48257669_=-- From swallow@cisco.com Sun Nov 8 22:35:43 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5482C3A68CB; Sun, 8 Nov 2009 22:35:43 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E+CJy+j1U+f; Sun, 8 Nov 2009 22:35:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1DEA83A68CF; Sun, 8 Nov 2009 22:35:42 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKZG90qtJV2Z/2dsb2JhbADDIYkiCI0TAoJLCIFpBA X-IronPort-AV: E=Sophos;i="4.44,706,1249257600"; d="scan'208";a="67020382" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 06:36:07 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id nA96a7R4002854; Mon, 9 Nov 2009 06:36:07 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 00:36:07 -0600 Received: from 10.70.230.175 ([10.70.230.175]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Nov 2009 06:36:06 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 09 Nov 2009 01:36:05 -0500 From: George Swallow To: Thomas Nadeau , Loa Andersson Message-ID: Thread-Topic: [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcphBumUDOQNnlWNXE2O62XNeexRBw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 06:36:07.0112 (UTC) FILETIME=[EAD6BC80:01CA6106] Cc: mpls@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:35:43 -0000 It will progress as a workgroup document. Normal commenting mechanisms apply as always. ...George On 11/8/09 7:48 AM, "Thomas Nadeau" wrote: > > Did the chairs also agree to take into account any of the objections > or suggestions that were made, or did you decide to accept it as-is? > > --Tom > > >> WG, >> >> the working group chairs have decided to make >> draft-sprecher-mpls-tp-oam-analysis-07.txt >> an mpls working group draft. >> >> Could the authors please republish as >> >> draft-ietf-mpls-tp-oam-analysis-00.txt >> >> Loa and George >> -- >> >> >> Loa Andersson email: >> loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From root@core3.amsl.com Sun Nov 8 23:00:02 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4761B3A684C; Sun, 8 Nov 2009 23:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109070002.4761B3A684C@core3.amsl.com> Date: Sun, 8 Nov 2009 23:00:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-analysis-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP OAM Analysis Author(s) : N. Sprecher, et al. Filename : draft-ietf-mpls-tp-oam-analysis-00.txt Pages : 29 Date : 2009-11-08 This document analyzes the set of requirements for Operations, Administration, and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether existing OAM tools (either from the current MPLS toolset or from the ITU-T documents) can be applied to these requirements. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP. This document reports the conclusions of the MPLS-TP design team discussions concerning the MPLS-TP OAM tools at IETF75. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-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-mpls-tp-oam-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08224927.I-D@ietf.org> --NextPart-- From satoru.matsushima@gmail.com Sun Nov 8 23:16:06 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6C93A684C; Sun, 8 Nov 2009 23:16:06 -0800 (PST) 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 4oYQDIwQa7Tv; Sun, 8 Nov 2009 23:16:05 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 94C343A6810; Sun, 8 Nov 2009 23:16:05 -0800 (PST) Received: by ywh13 with SMTP id 13so3006636ywh.29 for ; Sun, 08 Nov 2009 23:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1IX1b0R9YJNIXAjhk9fVN+THShsnhvZbJjYNQjvuMGs=; b=AkAtX2cYsERJRD7AN2WHoXICfQWu+45PhOmj6EtU0CuXUyM4f85Hvhmz0H0rQZcnDK gP0ZnaeBiAiS9xbFAdAOLacIWLyRzYYLjMqgscCfpAz0PNUnIRxwPB+kuyhsyCjqxkJQ b8+ngj8RHK+p/+4NY7qjjOvfOdhwkiDcdmHZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Jble7pJi/WnG/IjgPd6tBuCdvlQ2R5P+m6tZeEBk28jX3j/553YBIOiFrttCdXTn/O rNWIFMepWrD0qR67AlBPNELlJqROeyTV/H2YdlBrdNhshoqAfoIlmOrYZzHrU75Z7OPb QaRQPdqYr5cO8lD/MG8vhrZI5TCBlQGEv+8l4= Received: by 10.150.114.14 with SMTP id m14mr12741476ybc.162.1257750989023; Sun, 08 Nov 2009 23:16:29 -0800 (PST) Received: from host-24-195.meeting.ietf.org (host-24-195.meeting.ietf.org [133.93.24.195]) by mx.google.com with ESMTPS id 15sm1337698gxk.8.2009.11.08.23.16.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 23:16:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Satoru Matsushima In-Reply-To: Date: Mon, 9 Nov 2009 16:16:21 +0900 Content-Transfer-Encoding: 7bit Message-Id: <1A8CDAFF-598B-4C6A-AE26-76BEA0E525A9@gmail.com> References: To: George Swallow X-Mailer: Apple Mail (2.1076) Cc: mpls@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:16:06 -0000 I think that mpls-wg chairs had decided to continue the analysis as an item of working-group, is it correct? My question is that working-group needs whether make plan to schedule of finalizing analysis. I think that the analysis should be finalized before make mpls-tp oam standard. If it is correct, the analysis document schedule then influence entire schedule of mpls-tp oam standardizations. Thanks, -- Satoru Matsushima On 2009/11/09, at 15:36, George Swallow wrote: > It will progress as a workgroup document. Normal commenting > mechanisms > apply as always. > > ...George > > > On 11/8/09 7:48 AM, "Thomas Nadeau" wrote: > >> >> Did the chairs also agree to take into account any of the objections >> or suggestions that were made, or did you decide to accept it as-is? >> >> --Tom >> >> >>> WG, >>> >>> the working group chairs have decided to make >>> draft-sprecher-mpls-tp-oam-analysis-07.txt >>> an mpls working group draft. >>> >>> Could the authors please republish as >>> >>> draft-ietf-mpls-tp-oam-analysis-00.txt >>> >>> Loa and George >>> -- >>> >>> >>> Loa Andersson email: >>> loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sun Nov 8 23:45:32 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8EB28C1C9; Sun, 8 Nov 2009 23:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 id4IgDhO7LU2; Sun, 8 Nov 2009 23:45:31 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 41D4828C154; Sun, 8 Nov 2009 23:45:30 -0800 (PST) Received: from [133.93.17.10] (host-17-10.meeting.ietf.org [133.93.17.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 194E1D404F; Mon, 9 Nov 2009 08:45:50 +0100 (CET) Message-ID: <4AF7C8A8.9060003@pi.nu> Date: Mon, 09 Nov 2009 08:45:44 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Satoru Matsushima References: <1A8CDAFF-598B-4C6A-AE26-76BEA0E525A9@gmail.com> In-Reply-To: <1A8CDAFF-598B-4C6A-AE26-76BEA0E525A9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-tp@ietf.org" , mpls@ietf.org Subject: Re: [mpls] [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:45:32 -0000 Satoru, we decided to make the OAM Analysis ID a wg document. I think that we have what we need to start developing the OAM solutions draft. In turn it is likely that this work will provide input to the OAM analysis. /Loa Satoru Matsushima wrote: > I think that mpls-wg chairs had decided to continue the analysis as an > item of working-group, is it correct? > My question is that working-group needs whether make plan to schedule > of finalizing analysis. > > I think that the analysis should be finalized before make mpls-tp oam > standard. If it is correct, the analysis document > schedule then influence entire schedule of mpls-tp oam standardizations. > > > Thanks, > > > -- > Satoru Matsushima > > > On 2009/11/09, at 15:36, George Swallow wrote: > >> It will progress as a workgroup document. Normal commenting mechanisms >> apply as always. >> >> ...George >> >> >> On 11/8/09 7:48 AM, "Thomas Nadeau" wrote: >> >>> >>> Did the chairs also agree to take into account any of the objections >>> or suggestions that were made, or did you decide to accept it as-is? >>> >>> --Tom >>> >>> >>>> WG, >>>> >>>> the working group chairs have decided to make >>>> draft-sprecher-mpls-tp-oam-analysis-07.txt >>>> an mpls working group draft. >>>> >>>> Could the authors please republish as >>>> >>>> draft-ietf-mpls-tp-oam-analysis-00.txt >>>> >>>> Loa and George >>>> -- >>>> >>>> >>>> Loa Andersson email: >>>> loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13 >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From satoru.matsushima@gmail.com Mon Nov 9 00:40:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E495D28C1E0; Mon, 9 Nov 2009 00:40:33 -0800 (PST) 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 tY-kfaorH48m; Mon, 9 Nov 2009 00:40:33 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id E02F028C1D5; Mon, 9 Nov 2009 00:40:32 -0800 (PST) Received: by gxk4 with SMTP id 4so79964gxk.8 for ; Mon, 09 Nov 2009 00:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wcqlCNneRL7p5dCCjZa5gR0Mk3g58rEq3Pul0uvCD2I=; b=Fh5vqIr4H+ljyiCg4H+0Wpq6CZTOEUzn4KupHmJdTYzmvvQ6XdV+bwCPhscj2kMUH1 CMqfPy7MYDm4iVFYh7ftOxhsAN9sFewnlzoYCSA78biTwNzI1B0mTugVrfUhF79aATRt 4dktpe6JTMmEaAMBEGp947zpGwb6jJFhqW1+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=snULsUd6aXIThPwvN/oIZy3Tf9ih8TIZsmke1fTM703+oZ0h5B8jz7iyCOl4lfS1+b nl2mgTov2+2jgM6ekLgHeUQsWUB2WbBFiwyxTIgiJOrXJuuL9M7k5qmOMab7hhmgM5SF PltE/mKHZs9qw6XZ73eTjLzxzfnnzvcWARV6A= Received: by 10.150.254.7 with SMTP id b7mr12888483ybi.137.1257756053648; Mon, 09 Nov 2009 00:40:53 -0800 (PST) Received: from host-24-195.meeting.ietf.org (host-24-195.meeting.ietf.org [133.93.24.195]) by mx.google.com with ESMTPS id 15sm1363348gxk.12.2009.11.09.00.40.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 00:40:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Satoru Matsushima In-Reply-To: <4AF7C8A8.9060003@pi.nu> Date: Mon, 9 Nov 2009 17:40:48 +0900 Content-Transfer-Encoding: 7bit Message-Id: <5023EB89-5E12-473F-9AB2-07BCE33B618A@gmail.com> References: <1A8CDAFF-598B-4C6A-AE26-76BEA0E525A9@gmail.com> <4AF7C8A8.9060003@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1076) Cc: mpls@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:40:34 -0000 Loa, On 2009/11/09, at 16:45, Loa Andersson wrote: > Satoru, > > we decided to make the OAM Analysis ID a wg document. > > I think that we have what we need to start developing the OAM > solutions > draft. In turn it is likely that this work will provide input to the > OAM analysis. This is my point. - MPLS-TP OAM standard should wait finalize the analysis work. or - MPLS-TP OAM standard will be make then we input the history of discussion to the analysis work. I believe what you mentioned is latter one. Thanks, -- Satoru Matsushima > > /Loa > > Satoru Matsushima wrote: >> I think that mpls-wg chairs had decided to continue the analysis as >> an item of working-group, is it correct? >> My question is that working-group needs whether make plan to >> schedule of finalizing analysis. >> I think that the analysis should be finalized before make mpls-tp >> oam standard. If it is correct, the analysis document >> schedule then influence entire schedule of mpls-tp oam >> standardizations. >> Thanks, >> -- >> Satoru Matsushima >> On 2009/11/09, at 15:36, George Swallow wrote: >>> It will progress as a workgroup document. Normal commenting >>> mechanisms >>> apply as always. >>> >>> ...George >>> >>> >>> On 11/8/09 7:48 AM, "Thomas Nadeau" wrote: >>> >>>> >>>> Did the chairs also agree to take into account any of the >>>> objections >>>> or suggestions that were made, or did you decide to accept it as- >>>> is? >>>> >>>> --Tom >>>> >>>> >>>>> WG, >>>>> >>>>> the working group chairs have decided to make >>>>> draft-sprecher-mpls-tp-oam-analysis-07.txt >>>>> an mpls working group draft. >>>>> >>>>> Could the authors please republish as >>>>> >>>>> draft-ietf-mpls-tp-oam-analysis-00.txt >>>>> >>>>> Loa and George >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: >>>>> loa.andersson@ericsson.com >>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>> +46 767 72 92 13 >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> >>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jgs@juniper.net Mon Nov 9 01:10:56 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47873A6B24 for ; Mon, 9 Nov 2009 01:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 RdRHcgraXP2V for ; Mon, 9 Nov 2009 01:10:54 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 8A84F3A659B for ; Mon, 9 Nov 2009 01:10:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSvfctu34pXKfPbex9ku03A7obH7rsMbJ@postini.com; Mon, 09 Nov 2009 01:11:20 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 01:10:30 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 01:10:29 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 01:10:29 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 01:10:29 -0800 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.23.8.196]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA99ARj13592; Mon, 9 Nov 2009 01:10:28 -0800 (PST) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 18:10:27 +0900 Message-ID: To: ice@cisco.com MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 09 Nov 2009 09:10:29.0150 (UTC) FILETIME=[7B7193E0:01CA611C] Cc: mpls@ietf.org Subject: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:10:56 -0000 My question from the mic: Please also consider how the draft responds to the requirements in RFC4834 (and contrast to the existing CsC solutions if possible). Specific requirements to consider include From RFC4834, Section 5.2.2 (Scalability): .... proposed solutions SHOULD offer the possibility of sharing such resources between different multicast streams (between different VPNs, between different multicast streams of the same or of different VPNs). and From RFC4834, Section 5.2.4.1 (Tunneling Technologies) Following the principle of separation between the control plane and the forwarding plane, a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent: the control plane SHALL NOT depend on which forwarding plane is used (and vice versa), and the choice of forwarding plane SHOULD NOT be limited by the design of the solution. Also, the solution SHOULD NOT be tied to a specific tunneling technology. Thanks, --John From root@core3.amsl.com Mon Nov 9 01:45:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AB94F3A68FE; Mon, 9 Nov 2009 01:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109094501.AB94F3A68FE@core3.amsl.com> Date: Mon, 9 Nov 2009 01:45:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-survive-fwk-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching Transport Profile Survivability Framework Author(s) : N. Sprecher, A. Farrel Filename : draft-ietf-mpls-tp-survive-fwk-03.txt Pages : 52 Date : 2009-11-09 Network survivability is the ability of a network to restore traffic delivery following disruption or failure of network resources. Survivability is critical to the delivery of guaranteed network services such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time the service may be degraded or unavailable. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet transport technology based on the MPLS data plane and re-using many aspects of the MPLS management and control planes. This document provides a framework for the provision of survivability in an MPLS-TP network, describing recovery elements, types, methods and topological considerations. Survivability may be supported by control plane, management plane, and by Operations, Administration and Maintenance (OAM) functions to achieve data plane recovery. This document describes mechanisms for protecting MPLS-TP Label Switched Paths (LSPs). Detailed consideration for the protection of pseudowires in MPLS-TP networks is out of scope. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-03.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-mpls-tp-survive-fwk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-09014251.I-D@ietf.org> --NextPart-- From Adrian.Farrel@huawei.com Mon Nov 9 02:23:12 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EEB28C18F for ; Mon, 9 Nov 2009 02:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_05=-1.11, STOX_REPLY_TYPE=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 ObYW4p6D+V7i for ; Mon, 9 Nov 2009 02:23:11 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 561633A680D for ; Mon, 9 Nov 2009 02:23:11 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSU00COB7JB0C@usaga01-in.huawei.com> for mpls@ietf.org; Mon, 09 Nov 2009 02:23:35 -0800 (PST) Received: from your029b8cecfe (host-16-167.meeting.ietf.org [133.93.16.167]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSU00BMA7J9TB@usaga01-in.huawei.com> for mpls@ietf.org; Mon, 09 Nov 2009 02:23:35 -0800 (PST) Date: Mon, 09 Nov 2009 10:23:13 +0000 From: Adrian Farrel To: mpls@ietf.org Message-id: <8929EE15EE284E1486B81B56786E525B@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [mpls] MPLS Process Draft and Historic Status X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:23:12 -0000 Hi, Kam asked : What does it mean for an RFC to be "Historic" >From RFC 2026 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.) Just to clarify, however, we will NOT advance this draft to RFC (of any sort) until the MPLS-TP project has completed. So, in particular, this will not be marked as Historic until it truly is a description of history. This allows us to keep the document flexible and updated as the project develops. Sasha asked : Could you consider making this a BCP for use by other future projects. My answer is : Yes, maybe. We would have to make some modifications to the document in that case, but it is a possible way to handle the document after the end of the MPLS-TP project. Thanks, Adrian From lmartini@cisco.com Mon Nov 9 02:27:13 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEEA28C1F8 for ; Mon, 9 Nov 2009 02:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6] 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 nE7-IiEoUb7b for ; Mon, 9 Nov 2009 02:27:12 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 9E62728C1F7 for ; Mon, 9 Nov 2009 02:27:12 -0800 (PST) Received: from rasputin.monoski.com (host-40-57.meeting.ietf.org [133.93.40.57]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id nA9ARKo0028698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 03:27:23 -0700 (MST) Message-ID: <4AF7EE81.9090705@cisco.com> Date: Mon, 09 Nov 2009 03:27:13 -0700 From: Luca Martini User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: sandeep.bishnoi@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 67.41.208.110 Cc: mpls@ietf.org Subject: [mpls] draft-bishnoi-mpls-mldp-opaque-types-01.txt and figuring out all these types .. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:27:13 -0000 Sandeep, As I mentioned in the meting here are the many versions of these things : sec 5 in draft-ietf-mpls-ldp-upstream-04.txt quotes an RFC3472 TLV which is defined in sec 8.1.1. in RFC3472. This rfc defines an interface ID TLV , and 3471 defines an interface ID. In draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03.txt it quotes draft-ietf-mpls-ldp-upstream-04.txt . Then we have draft-martini-pwe3-p2mp-pw-01.txt , which is the merge of the draft-Journay-niger , and draft-martini-pwe3-p2mp-pw-00.txt ,and I have yet another definition of the LSP identifier , which comes from the L3VPN draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt document. ( this is going to be changed in the next version) ok, Now I'm really confused ! :-) The problem: We are looking at somehow identifying an P2MP or M2MP LSP. I would like to state that the specific encoding is trivial, as long as we can get a unique ID we can all agree on. I do not agree that we MUST not share the LSP. If there are applications that are all going to the same locations, I do not see why we cannot share the tree. Why are we attempting to centralize the definition of these LDP LSP identifiers ? Maybe we just need a simple document defining an IANA registry, and rules to get assignments from it . This is very similar to the PW AII definitions, and history shows us that a simple registry is a good way to solve this problem. Luca From yakov@juniper.net Mon Nov 9 06:13:49 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C701228C13F for ; Mon, 9 Nov 2009 06:13:49 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnJq5AKL+m-P for ; Mon, 9 Nov 2009 06:13:48 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 18D5828C13E for ; Mon, 9 Nov 2009 06:13:48 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSvgjtUniHJwiDCuNzO4Z3F4A6+HMWx9E@postini.com; Mon, 09 Nov 2009 06:14:14 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 05:54:08 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 05:54:08 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 05:54:08 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 05:54:05 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9Ds5j67475; Mon, 9 Nov 2009 05:54:05 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911091354.nA9Ds5j67475@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: References: <200911061238.nA6Cc7j51322@magenta.juniper.net> <200911081416.nA8EGBj36753@magenta.juniper.net> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Mon, 09 Nov 2009 12:38:45 +0900." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25317.1257774845.1@juniper.net> Date: Mon, 9 Nov 2009 05:54:05 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 09 Nov 2009 13:54:05.0770 (UTC) FILETIME=[1A23BAA0:01CA6144] Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:13:49 -0000 Ice, > Yakov, > > > That still does not answer the question I asked above. Namely, what > > are "the IP multicast control messages used to set up the tree", > > and how do these messages get "translated into mLDP messages" when > > we have mp2mp LSP for (*, G/M)? > > PIM messages are not translated into mLDP messages. I think that is > the key point of the mis-understanding. You translate multicast > routing state into mLDP messages. So if the MRIB has (*,G) it encodes > it into a mLDP FEC, if it has (*,G/M) is does the same. That also > makes the solution independent of PIM, MSDP or IGMP. Any multicast > protocol that can populate the MRIB can be used to create a mLDP LSP. That contradicts your draft. Quoting from Abstract: The IP multicast control messages are translated into MPLS control messages when they enter the MPLS domain, and are translated back into IP multicast control messages at the far end of the MPLS domain. > > Your answer contradicts your own statement you made above, namely, > > Correct, I mis interpreted your question. There will be different > MP2MP LSPs. Use of mp2mp LSP for the (*,G/M) state would result in traffic originated from one source only branch to reach all other source only branches. This is clearly undesirable. Thus the draft needs to explain the rationale for using mp2mp LSP for the (*, G/M) state. > >> This is documented in RFC5015 section 3.1.4. Its not mLDP's > >> functionality to merge the 2 trees together, this is done in PIM. > > > > Does that mean that the merge point has to run PIM ? > > Yes, it will by default because this is the Ingress PE/Root of the > P2MP LSP that borders with the IP PIM network. Restricting the merge point to the Ingress PE defeats one of the (main) benefits of PIM-Bidir, namely that as traffic travels from sources towards the RPA, the traffic is forwarded to the (downstream) receivers for that traffic. This is because with the mechanisms proposed in your draft the traffic (from source only branches) has to reach the Ingress PE before it could get forwarded to the downstream receivers - the traffic can not get forwarded to the downstream receivers in the middle of the MPLS network. The draft should certainly document this. Yakov. From yakov@juniper.net Mon Nov 9 06:35:01 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76CF3A67A5 for ; Mon, 9 Nov 2009 06:35:01 -0800 (PST) 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.000, 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 px86xMr6QXUm for ; Mon, 9 Nov 2009 06:35:01 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id BEA7C3A681C for ; Mon, 9 Nov 2009 06:35:00 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSvgorrY0Hqcqm+fSHTzxcqfZxRmCXi5H@postini.com; Mon, 09 Nov 2009 06:35:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 06:08:59 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:08:59 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:08:58 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:08:58 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9E8vj83127; Mon, 9 Nov 2009 06:08:57 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911091408.nA9E8vj83127@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: <45661C01-5325-4A3E-B10D-A79F7E57CF8C@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> <200911081431.nA8EVhj41501@magenta.juniper.net> <45661C01-5325-4A3E-B10D-A79F7E57CF8C@cisco.com> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Mon, 09 Nov 2009 12:38:48 +0900." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26479.1257775737.1@juniper.net> Date: Mon, 9 Nov 2009 06:08:57 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 09 Nov 2009 14:08:58.0170 (UTC) FILETIME=[2E0D29A0:01CA6146] Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:35:01 -0000 Ice, > Yakov, > > >> This prevents receiving a (S,G) from the P2MP LSP and send it down > >> the > >> (*,G) PIM tree. This is the behavior we want to support in > >> combination > >> with out-of-band source discovery via MSDP. The only thing we want to > >> restrict is transport (*,G) traffic down the P2MP LSP, that is > >> covered > >> by section 2.3. > > > > Then the draft should explicitly spell out "the behavior we want > > to support", *and* the mechanisms/procedures to support such behavior, > > including the interaction with the out-of-band source discovery via > > MSDP. > > There are no additional mechanisms/procedures to support this > behavior. This is basic PIM Sparse-mode behavior. Consider the following example: Rcv1--R1---LSR1---LSR2---LSR3----R2--RP \ LSR5--------LSR4---R3--S DR connected to Rcv1 sends Join(*,G) to R1, which in turn sends it to LSR1. If indeed we rely just on "basic PIM Sparse-mode behavior" (as specified in rfc4601), then how would this "basic PIM Sparse-mode behavior" result in Rcv1 receiving multicast traffic from S (assuming S sends to G). Yakov. From wwwrun@core3.amsl.com Mon Nov 9 09:36:11 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4B8773A6891; Mon, 9 Nov 2009 09:36:11 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091109173611.4B8773A6891@core3.amsl.com> Date: Mon, 9 Nov 2009 09:36:11 -0800 (PST) Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'MPLS TP Network Management Requirements' to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:36:11 -0000 The IESG has approved the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-06.txt Technical Summary This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS transport profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. Working Group Summary The document is part of the MPLS-TP project, the cooperation between IETF and ITU-T to specify an MPLS transport profile. There are no outstanding issues. It is put on the standards track to resolve issues around how the ITU-T references IETF documents. Document Quality The document is a requirements specification and will mainly be used as input to the network management solutions specifications that will be published shortly. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From ice@cisco.com Mon Nov 9 12:18:38 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60F13A6831 for ; Mon, 9 Nov 2009 12:18:38 -0800 (PST) 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=[AWL=0.000, 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 n-cgj0C0-xhX for ; Mon, 9 Nov 2009 12:18:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id C145A3A657C for ; Mon, 9 Nov 2009 12:18:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA9KFIgM029287; Mon, 9 Nov 2009 21:15:18 +0100 (CET) Received: from tky-vpn-client-231-189.cisco.com (tky-vpn-client-231-189.cisco.com [10.70.231.189]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA9KFEwK018418; Mon, 9 Nov 2009 21:15:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911091408.nA9E8vj83127@magenta.juniper.net> Date: Tue, 10 Nov 2009 05:15:08 +0900 Content-Transfer-Encoding: 7bit Message-Id: <9E100C2D-AF7D-4E27-A944-519EBCDDAE42@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> <200911081431.nA8EVhj41501@magenta.juniper.net> <45661C01-5325-4A3E-B10D-A79F7E57CF8C@cisco.com> <200911091408.nA9E8vj83127@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:18:38 -0000 Yakov, > > Consider the following example: > > Rcv1--R1---LSR1---LSR2---LSR3----R2--RP > \ > LSR5--------LSR4---R3--S > > DR connected to Rcv1 sends Join(*,G) to R1, which in turn sends it > to LSR1. If indeed we rely just on "basic PIM Sparse-mode behavior" > (as specified in rfc4601), then how would this "basic PIM Sparse-mode > behavior" result in Rcv1 receiving multicast traffic from S (assuming > S sends to G). Section 2.3 in the draft says this is out of scope. We're not using mLDP in-band signaling to pull traffic down a (*,G) tree. If you want to support the example above, LSR1 needs to create (S,G) state for the source. Section 2.1 suggest that MSDP can be used to do that. Thx, Ice. From cbenson@adax.com Mon Nov 9 12:26:14 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0083A6B53 for ; Mon, 9 Nov 2009 12:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 K3a15GYO0pUw for ; Mon, 9 Nov 2009 12:26:13 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 792C43A6A44 for ; Mon, 9 Nov 2009 12:26:13 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id D926A120A06 for ; Mon, 9 Nov 2009 12:26:38 -0800 (PST) Received: by adax (Postfix, from userid 243) id D4E5B8E52B; Mon, 9 Nov 2009 12:25:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id CF97C8E52A for ; Mon, 9 Nov 2009 12:25:52 -0800 (PST) Date: Mon, 9 Nov 2009 12:25:52 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: mpls@ietf.org In-Reply-To: <20090906004501.32A1B3A67F7@core3.amsl.com> Message-ID: References: <20090906004501.32A1B3A67F7@core3.amsl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:26:14 -0000 Hi folks, I offer the tiniest typographic correction to the document draft-ietf-mpls-ldp-typed-wildcard-04.txt In the first sentence of Section 5, there is a mis-typed RFC reference by number. OLD: As noted above, RFC5056 FEC procedures provide for ... NEW As noted above, RFC5036 FEC procedures provide for ... With thanks, from Chris Benson. On Sat, 5 Sep 2009, Internet-Drafts@ietf.org wrote: >> Date: Sat, 5 Sep 2009 17:45:01 -0700 (PDT) >> From: >> To: >> Cc: >> Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. >> >> >> Title : LDP Typed Wildcard FEC >> Author(s) : I. Minei, et al. >> Filename : draft-ietf-mpls-ldp-typed-wildcard-04.txt >> Pages : 10 >> Date : 2009-09-05 >> >> The LDP specification [RFC5036] for the Wildcard FEC element has >> several deficiencies. This document corrects those deficiencies. In >> addition, it specifies the Typed Wildcard FEC for the Prefix FEC >> Element Type defined in RFC5036. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-04.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. >> From ice@cisco.com Mon Nov 9 12:31:39 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7933A68F8 for ; Mon, 9 Nov 2009 12:31:39 -0800 (PST) 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=[AWL=0.000, 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 OVPCZGQeMQ6F for ; Mon, 9 Nov 2009 12:31:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id E7A5B3A680F for ; Mon, 9 Nov 2009 12:31:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA9K4wCI021309; Mon, 9 Nov 2009 21:04:58 +0100 (CET) Received: from tky-vpn-client-231-189.cisco.com (tky-vpn-client-231-189.cisco.com [10.70.231.189]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA9K4qcc007076; Mon, 9 Nov 2009 21:04:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911091354.nA9Ds5j67475@magenta.juniper.net> Date: Tue, 10 Nov 2009 05:04:46 +0900 Content-Transfer-Encoding: 7bit Message-Id: <5AEA5E9C-9FFD-4636-B9FE-ECF82099D90F@cisco.com> References: <200911061238.nA6Cc7j51322@magenta.juniper.net> <200911081416.nA8EGBj36753@magenta.juniper.net> <200911091354.nA9Ds5j67475@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:31:39 -0000 Yakov, > That contradicts your draft. Quoting from Abstract: > > The IP multicast control > messages are translated into MPLS control messages when they enter > the MPLS domain, and are translated back into IP multicast control > messages at the far end of the MPLS domain. I'll change that in the next revision. It basically comes down to the same thing. Whether you take the information directly from PIM or via the MRIB is an implementation matter, but I can see how the term 'translation' causes confusion. > >>> Your answer contradicts your own statement you made above, namely, >> >> Correct, I mis interpreted your question. There will be different >> MP2MP LSPs. > > Use of mp2mp LSP for the (*,G/M) state would result in traffic > originated from one source only branch to reach all other source only > branches. This is clearly undesirable. Thus the draft needs to > explain the rationale for using mp2mp LSP for the (*, G/M) state. Good point. I'll clarify this in the draft. > >>>> This is documented in RFC5015 section 3.1.4. Its not mLDP's >>>> functionality to merge the 2 trees together, this is done in PIM. >>> >>> Does that mean that the merge point has to run PIM ? >> >> Yes, it will by default because this is the Ingress PE/Root of the >> P2MP LSP that borders with the IP PIM network. > > Restricting the merge point to the Ingress PE defeats one of the > (main) benefits of PIM-Bidir, namely that as traffic travels from > sources towards the RPA, the traffic is forwarded to the (downstream) > receivers for that traffic. This is because with the mechanisms > proposed in your draft the traffic (from source only branches) has > to reach the Ingress PE before it could get forwarded to the > downstream receivers - the traffic can not get forwarded to the > downstream receivers in the middle of the MPLS network. The draft > should certainly document this. One of the main benefits of PIM bidir is to reduce PIM state. PIM bidir forwarding does not guarantee packets are forwarded along the shortest path. The sender only traffic will indeed go up to ingress PE before it will go down. However, this is not very different from what is documented in draft-ietf-mpls-ldp-p2mp-08 section 3 with the exception that using a MP2MP LSP you will at least not receive your own originated packets back, which is a big advantage. Sites that will be a receiver on the bidir tree will not suffer from this. I'll add a section in the draft to clarify this. Thx, Ice. From yakov@juniper.net Mon Nov 9 13:15:27 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8433A6BAA for ; Mon, 9 Nov 2009 13:15:27 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs9dwyiQG-2A for ; Mon, 9 Nov 2009 13:15:26 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 974323A6768 for ; Mon, 9 Nov 2009 13:15:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSviGiKk2ny9JM7xzdBfEN9lC++tUkhL0@postini.com; Mon, 09 Nov 2009 13:15:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 9 Nov 2009 13:13:32 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:13:32 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:13:31 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:13:31 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA9LDVj06437; Mon, 9 Nov 2009 13:13:31 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911092113.nA9LDVj06437@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: <9E100C2D-AF7D-4E27-A944-519EBCDDAE42@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> <200911081431.nA8EVhj41501@magenta.juniper.net> <45661C01-5325-4A3E-B10D-A79F7E57CF8C@cisco.com> <200911091408.nA9E8vj83127@magenta.juniper.net> <9E100C2D-AF7D-4E27-A944-519EBCDDAE42@cisco.com> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Tue, 10 Nov 2009 05:15:08 +0900." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70415.1257801211.1@juniper.net> Date: Mon, 9 Nov 2009 13:13:31 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 09 Nov 2009 21:13:31.0773 (UTC) FILETIME=[7D8082D0:01CA6181] Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:15:27 -0000 Ice, > > Consider the following example: > > > > Rcv1--R1---LSR1---LSR2---LSR3----R2--RP > > \ > > LSR5--------LSR4---R3--S > > > > DR connected to Rcv1 sends Join(*,G) to R1, which in turn sends it > > to LSR1. If indeed we rely just on "basic PIM Sparse-mode behavior" > > (as specified in rfc4601), then how would this "basic PIM Sparse-mode > > behavior" result in Rcv1 receiving multicast traffic from S (assuming > > S sends to G). > > Section 2.3 in the draft says this is out of scope. We're not using > mLDP in-band signaling to pull traffic down a (*,G) tree. What I showed in my example above is a fairly simple PIM-SM in ASM mode scenario. Since as you said above, supporting this scenario "is out of scope", the draft has to say that supporting PIM-SM in ASM mode is "out of scope". > If you want to support the example above, LSR1 needs to create (S,G) > state for the source. Section 2.1 suggest that MSDP can be used to do > that. If you do not want to state in the draft that supporting PIM-SM in ASM mode is out of scope, then the draft needs to explicitly spell out how exactly MSDP will be used in the scenarios like the one I showed above. Saying that "IP multicast source trees can either be created via PIM operating in SSM mode [RFC4607] or ASM mode [RFC4601] (for example via last hop behavior or MSDP [RFC3618])", *as that is all what section 2.1 said about MSDP*, is not sufficient. Yakov. From rajiva@cisco.com Mon Nov 9 15:23:21 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5A53A68C1 for ; Mon, 9 Nov 2009 15:23:21 -0800 (PST) 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.000, 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 8001iAfASgQL for ; Mon, 9 Nov 2009 15:23:20 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 10DA33A6808 for ; Mon, 9 Nov 2009 15:23:19 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJoz+EqtJV2d/2dsb2JhbADGHZdDhD4E X-IronPort-AV: E=Sophos;i="4.44,711,1249257600"; d="scan'208";a="67180362" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 23:23:46 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id nA9NNjAL008814; Mon, 9 Nov 2009 23:23:45 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 17:23:45 -0600 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 Date: Mon, 9 Nov 2009 17:23:42 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C1974FF@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt Thread-Index: Acphevf4pUqbqv9MROi6PvTjEeLW3QAGKZsA References: <20090906004501.32A1B3A67F7@core3.amsl.com> From: "Rajiv Asati (rajiva)" To: "Chris Benson" , X-OriginalArrivalTime: 09 Nov 2009 23:23:45.0699 (UTC) FILETIME=[AEF6FF30:01CA6193] Subject: Re: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:23:21 -0000 Hi Chris, Good catch. Will fix it in the next version. Thanks for reviewing the draft. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chris > Benson > Sent: Monday, November 09, 2009 3:26 PM > To: mpls@ietf.org > Subject: Re: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt >=20 > Hi folks, >=20 > I offer the tiniest typographic correction to the document > draft-ietf-mpls-ldp-typed-wildcard-04.txt >=20 > In the first sentence of Section 5, there is a mis-typed > RFC reference by number. >=20 > OLD: > As noted above, RFC5056 FEC procedures provide for ... >=20 > NEW > As noted above, RFC5036 FEC procedures provide for ... >=20 > With thanks, from Chris Benson. >=20 > On Sat, 5 Sep 2009, Internet-Drafts@ietf.org wrote: >=20 > >> Date: Sat, 5 Sep 2009 17:45:01 -0700 (PDT) > >> From: > >> To: > >> Cc: > >> Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > >> > >> > >> Title : LDP Typed Wildcard FEC > >> Author(s) : I. Minei, et al. > >> Filename : draft-ietf-mpls-ldp-typed-wildcard-04.txt > >> Pages : 10 > >> Date : 2009-09-05 > >> > >> The LDP specification [RFC5036] for the Wildcard FEC element has > >> several deficiencies. This document corrects those deficiencies. In > >> addition, it specifies the Typed Wildcard FEC for the Prefix FEC > >> Element Type defined in RFC5036. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard- > 04.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. > >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Sandeep.Bishnoi@alcatel-lucent.com Mon Nov 9 16:32:18 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927733A677E for ; Mon, 9 Nov 2009 16:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 X-uo9+omYlUp for ; Mon, 9 Nov 2009 16:32:17 -0800 (PST) Received: from audl952.usa.alcatel.com (audl952.usa.alcatel.com [143.209.238.159]) by core3.amsl.com (Postfix) with ESMTP id B52443A689C for ; Mon, 9 Nov 2009 16:32:17 -0800 (PST) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id nAA0WgSU016806; Mon, 9 Nov 2009 18:32:42 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 18:32:42 -0600 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 Date: Mon, 9 Nov 2009 18:32:36 -0600 Message-ID: <4E816EC104822245BA3C86149A7158150BE51435@USDALSMBS01.ad3.ad.alcatel.com> In-Reply-To: <4AF7EE81.9090705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bishnoi-mpls-mldp-opaque-types-01.txt and figuring out all these types .. Thread-Index: AcphJ0Se4lSnHNueS1mYdMVVDmbg/QAcy6IA References: <4AF7EE81.9090705@cisco.com> From: "BISHNOI Sandeep" To: "Luca Martini" X-OriginalArrivalTime: 10 Nov 2009 00:32:42.0406 (UTC) FILETIME=[50A26460:01CA619D] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Cc: mpls@ietf.org Subject: Re: [mpls] draft-bishnoi-mpls-mldp-opaque-types-01.txt and figuring out all these types .. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:32:18 -0000 Luca, Interface ID TLV from RFC3472 and 3471 are unrelated. Interface ID TLV is for control and data plane association in GMPLS. P2MP LDP LSP identifier that 'draft-martini-pwe3-p2mp-pw-01' refers is actually defined in 'draft-ietf-mpls-ldp-p2mp-08'.=20 'draft-ietf-l3vpn-2547bis-mcast-bgp-08' is just referring to P2MP LDP LSP identifier defined in 'draft-ietf-mpls-ldp-p2mp-08'. There is only single 'generic ID space' defined in 'draft-ietf-mpls-ldp-p2mp-08' and most related drafts refer to it. Our proposal is to have multiple P2MP LDP LSP identifiers for each application (optional - unique for each application that dynamically request mLDP LSP setup). Recommendation is to have separate ID for static mLDP P2MP LSPs that would avoid overlap among multiple applications. This would also avoid carving out single space by multiple vendors that may not be compatible with each other. Thanks, Sandeep -----Original Message----- From: Luca Martini [mailto:lmartini@cisco.com]=20 Sent: Monday, November 09, 2009 2:27 AM To: BISHNOI Sandeep Cc: mpls@ietf.org Subject: draft-bishnoi-mpls-mldp-opaque-types-01.txt and figuring out all these types .. Sandeep, As I mentioned in the meting here are the many versions of these things : sec 5 in draft-ietf-mpls-ldp-upstream-04.txt quotes an RFC3472 TLV which is defined in sec 8.1.1. in RFC3472. This rfc defines an interface ID TLV , and 3471 defines an interface ID. In draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03.txt it quotes draft-ietf-mpls-ldp-upstream-04.txt . Then we have draft-martini-pwe3-p2mp-pw-01.txt , which is the merge of the draft-Journay-niger , and draft-martini-pwe3-p2mp-pw-00.txt ,and I have yet another definition of the LSP identifier , which comes from the L3VPN draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt document. ( this is going to be changed in the next version) ok, Now I'm really confused ! :-) The problem: We are looking at somehow identifying an P2MP or M2MP LSP. I would like to state that the specific encoding is trivial, as long as we can get a unique ID we can all agree on. I do not agree that we MUST not share the LSP. If there are applications that are all going to the same locations, I do not see why we cannot share the tree. Why are we attempting to centralize the definition of these LDP LSP identifiers ? Maybe we just need a simple document defining an IANA registry, and rules to get assignments from it . This is very similar to the PW AII definitions, and history shows us that a simple registry is a good way to solve this problem. Luca From root@core3.amsl.com Mon Nov 9 20:00:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7B1173A694D; Mon, 9 Nov 2009 20:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091110040001.7B1173A694D@core3.amsl.com> Date: Mon, 9 Nov 2009 20:00:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-identifiers-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Identifiers Author(s) : M. Bocci, G. Swallow Filename : draft-ietf-mpls-tp-identifiers-00.txt Pages : 15 Date : 2009-11-09 This document specifies identifiers for MPLS-TP objects. Included are identifiers conformant to existing ITU conventions and identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-identifiers-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-mpls-tp-identifiers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-09195911.I-D@ietf.org> --NextPart-- From ice@cisco.com Mon Nov 9 22:24:10 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C3B28C118 for ; Mon, 9 Nov 2009 22:24:10 -0800 (PST) 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 uKf9JQ3G1aBb for ; Mon, 9 Nov 2009 22:24:09 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id AA1043A6899 for ; Mon, 9 Nov 2009 22:24:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAA66pSP026664; Tue, 10 Nov 2009 07:06:52 +0100 (CET) Received: from tky-vpn-client-231-36.cisco.com (tky-vpn-client-231-36.cisco.com [10.70.231.36]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAA66kAZ020661; Tue, 10 Nov 2009 07:06:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911092113.nA9LDVj06437@magenta.juniper.net> Date: Tue, 10 Nov 2009 15:06:40 +0900 Content-Transfer-Encoding: 7bit Message-Id: <300207E2-80B3-47EC-B2E1-B0192926347D@cisco.com> References: <200911061233.nA6CXIj49945@magenta.juniper.net> <0C06E411-77C6-49EB-9FED-C5FBF28CEDA8@cisco.com> <200911081431.nA8EVhj41501@magenta.juniper.net> <45661C01-5325-4A3E-B10D-A79F7E57CF8C@cisco.com> <200911091408.nA9E8vj83127@magenta.juniper.net> <9E100C2D-AF7D-4E27-A944-519EBCDDAE42@cisco.com> <200911092113.nA9LDVj06437@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:24:10 -0000 Yakov, > > If you do not want to state in the draft that supporting PIM-SM in > ASM mode is out of scope, then the draft needs to explicitly spell > out how exactly MSDP will be used in the scenarios like the one I > showed above. Saying that "IP multicast source trees can either be > created via PIM operating in SSM mode [RFC4607] or ASM mode [RFC4601] > (for example via last hop behavior or MSDP [RFC3618])", *as that > is all what section 2.1 said about MSDP*, is not sufficient. I thought that how MSDP would be used is fairly obvious. But I can enhance the section. Thx, Ice. From wwwrun@core3.amsl.com Tue Nov 10 01:25:21 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4978B3A6978; Tue, 10 Nov 2009 01:25:20 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091110092521.4978B3A6978@core3.amsl.com> Date: Tue, 10 Nov 2009 01:25:21 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, kam.lam@alcatel-lucent.com, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS110 - Comments on MPLS-TP NM Framework -01 (ref # 008.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:25:21 -0000 Title: LS110 - Comments on MPLS-TP NM Framework -01 (ref # 008.02) Submission Date: 2009-11-10 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=613 Please reply by 2010-03-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: kam.lam@alcatel-lucent.com Purpose: For action Body: Thank you for your liaison statement (ref # 008.01) soliciting early review by ITU-T of the MPLS-TP NM Framework draft. The experts of Q14/15 have reviewed draft-ietf-mpls-tp-nm-framework-01.txt by correspondence and suggested changes be made as shown in the attached mark-up draft. These suggestions reflect the consensus view of the experts. Attachment(s): LS110 - Comments on MPLS-TP NM Framework -01 (ref # 008.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file730.pdf) LS110 - Comments on MPLS-TP NM Framework -01 (ref # 008.02) - pdf attachment (https://datatracker.ietf.org/documents/LIAISON/file731.pdf) From wwwrun@core3.amsl.com Tue Nov 10 02:09:33 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 374EA3A6A86; Tue, 10 Nov 2009 02:09:33 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091110100933.374EA3A6A86@core3.amsl.com> Date: Tue, 10 Nov 2009 02:09:33 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 10:09:33 -0000 Title: LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02) Submission Date: 2009-11-10 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=614 Please reply by 2010-01-02 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@huawei.com Purpose: For action Body: Thank you for your liaison statement (ref # 009.01) requesting an early review by the ITU-T of the MPLS-TP framework draft. The experts of Q.12/15 have reviewed draft-ietf-mpls-tp-framework-06 by correspondence and have some comments and proposed changes shown in the attached marked up draft. These proposals reflect the consensus view of the experts. We have also received some further (late) comments that are still under consideration in Q.12. We will convey these further comments on or before 25th November 2009. Attachment(s): LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file732.pdf) LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02) - pdf attachment (https://datatracker.ietf.org/documents/LIAISON/file733.pdf) From pekkas@netcore.fi Tue Nov 10 05:04:47 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F106D3A686A; Tue, 10 Nov 2009 05:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] 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 gBQtW87Fe+5T; Tue, 10 Nov 2009 05:04:46 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id D829D3A69F0; Tue, 10 Nov 2009 05:04:16 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id nAAD4Z1q021464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 15:04:35 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id nAAD4Z3U021460; Tue, 10 Nov 2009 15:04:35 +0200 Date: Tue, 10 Nov 2009 15:04:35 +0200 (EET) From: Pekka Savola To: ietf@ietf.org In-Reply-To: <20091027155427.65B3B3A6822@core3.amsl.com> Message-ID: References: <20091027155427.65B3B3A6822@core3.amsl.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at otso.netcore.fi X-Virus-Status: Clean Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-mpls-and-gmpls-security-framework@tools.ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-mpls-and-gmpls-security-framework (Security Framework for MPLS and GMPLS Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:04:48 -0000 On Tue, 27 Oct 2009, The IESG wrote: > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > > - 'Security Framework for MPLS and GMPLS Networks ' > as an Informational RFC This is an assigned ops-dir review. The document is somewhat lengthy but easy-to-read description of various security threats and mitigation techniques applicable to MPLS and GMPLS networks. A lot of the material is focused on higher-layer issues, i.e., VPNs. I would argue that the document would be more focused if security framework for VPNs and for lower-layer stuff like MPLS and signaling would be separated. But I also understand and can live with keeping them combined. Specifically, I think there is a lot of duplication with RFC 4111 (Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)) here and it's acknowledged in the document. There are a couple of places where the document appears to be overly verbose and veers into tangential issues (e.g. providing description of IPsec and IKE algorithms, modes; or 4 pages of router filtering or firewalling discussion) and I'd suggest summarizing. There are a couple of minor technical errors or omissions. IMHO, the document should be revised prior to publication. Some higher-level observations ------------------------------ In S 5.2, P-to-P or P-to-PE protection is touched on only very briefly, and PWE3 protection is deemed out of scope. While these are declared out of scope or left for future study, it would have been useful to have a paragraph or subsection in Security Considerations section that underlines these remainder threats. In S 5.3, there are 4 pages dedicated to explaining how packet filtering and firewalling works. I'd argue most of that is tangential to this document and should be removed. A succint description should be possible in 0.5-1 pages. If you add informative reference to (expired, dead) I-D draft-ietf-opsec-filter-caps-09, it should cover the background. S 6 appears to discuss only SNMP/syslog type monitoring and detection mechanisms but these can only detect few attacks (usually resulting from flapping protocol adjacencies, CPU overload scenarios, etc.). The rest will fly below the radar. Other techniques such as netflow-based traffic fingerprinting are needed for more detailed detection and reporting. S 7.1.1 describes control plane protection but I believe this document should mention uRPF/ACLs towards customers and ACLs at the edges. It does mention destination-address based filtering as one possibility, but this has its own set of issues. If you're able to do comprehensive source-address based filtering, you're in a much better position to block someone spoofing your own (management or routers') IP address. The key point here is that if you're able to prevent anyone from spoofing your infrastructure IP addresses at ingress, you don't need (or you get an additional layer of protection) TCP-MD5, iBGP, IGP etc. protection. FWIW, draft-savola-rtgwg-backbone-attacks-03 describes this approach, and it may be applicable especially with smaller and reasonably well-defined service provider networks. (Some of the topics described in the draft are also touched on in S 7.2; this should also be added to S 9.3.1 point 1) S 8 does not discuss the differences of MPLS domain cross-connection in various established models, see e.g. RFC4364 S 10 options a)-c) and RFC4761 (L2VPN) section 3.4 options a)-c). One of th key issues not discussed here is whether a signalling protocol is run between service providers, or whether everything is demultiplexed/multiplexed at the border. This also has an impact on some of the security properties of the network. It seems as if the document is assuming that a signaling protocol is run between the providers; this may or may not be due to MPLS-ICI specifications but I don't know. Some more detailed comments --------------------------- In S 4.3, Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing. .. I'd observe that the TTL check in BFD is not primarily an anti-replay mechanism (the same also in S 8.1.1). Also it's not clear if the MPLS-ICI specification imposes the requirements in the last sentence, or whether these are from this document. (If these are "originated" by this document, this may be an issue because this is targeting Informational.) The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the SNMP SET command). .. lacking a reference, it seems a bit of guesswork to say this has been the main reason. In our case, we've prevented this forging yet still don't see the need to use SNMP sets; authentication and confidentiality is a bigger issue but for us the root issue is that it's more cumbersome to use than using CLI and related automated scripts. I wonder if there's a consensus-driven document that describes this. ... In general I felt S 4.3 to be a good summary but most of it was a description of general TCP/IP issues about host and TCP/IP security, and I wonder whether there should be additional references here, or if some of the material could be removed. In S 4.4 on insider attacks, Protection against insider attacks is largely for future study in MPLS and GMPLS networks. Some protection can be obtained by providing strict security for software upgrades, and preventing general (e.g. FTP) access to LSRs. Further protection can be achieved by strict control of user (i.e. operator) access to LSRs. Lastly, software tools may be used to monitor and report network behavior and activity in order to quickly spot any irregularities that may be the result of an insider attack. .. the "general access" (with FTP example) may be misleading. Are you referring to general access to the whole internet or (I suppose so) general access to all the OAM staff? A better phrasing might help. Additionally, this section could be improved. IMHO it would be especially important to mention (software) configuration management and change tracking mechanisms. This is similar to spotting irregularities as already described, but from configuration rather than from externally visible behaviour. In some cases, configuration change approval processes etc. may also be warranted. In our case, CVS diffs are produced from configuration changes and there are scripts which look for misconfigurations and irregularities as well. In S 5.2, - If the user requires remote access to its site from a system at a location that is not a customer location (for example, access by a traveler) there may be a requirement for cryptographically protecting the traffic between that system and an access point or a customer's site. If the MPLS/GMPLS provider supplies the access point, then the customer must cooperate with the provider to handle the access control services for the remote users. These access control services are usually protected cryptographically, as well. .. this appears to be a generic "VPN concentrator" case, and has (AFAICS) very little to do with MPLS/GMPLS security. Maybe this should be removed or reworded so that the issue is clearer? E.g. if the point is that the VPN concentrator has access to multiple VPNs, it's important to authenticate the user appropriately so that it won't get access to other VPNs. But even with this kind of formulation, the scope for this document is not clear. In S 5.2.1, IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] is the security protocol of choice for protection at the IP layer. .. adding an informative reference to draft-ietf-ipsecme-roadmap-xx might also be useful; I suppose it would give a more up-to-date overview than RFC2411. In S 5.2.1, Encryption algorithms generally come with two parameters: mode such as Cipher Block Chaining and key length such as AES-192. (This should not be confused with two other senses in which the word "mode" is used: IPsec itself can be used in Tunnel Mode or Transport Mode, and IKE [version 1] uses Main Mode, Aggressive Mode, or Quick Mode). It should be stressed that IPsec encryption without an integrity check is a state of sin. .. this appears to be mostly tangential and out of scope of this spec, and should be considered for removal. There is also other material in S 5.2.1 that IMHO goes beyond the basics of IPsec (mostly relating to IPsec modes and hashing/integrity algorithms) that seem unnecessary here. 5.2.2. MPLS / GMPLS DiffServ and IPsec Using IPsec without IKE or IKEv2 (the better choice) is not advisable. [...] .. over half of this section has nothing to do with DiffServ, it's mostly discussion of IKE protocol suite and key management. The title needs to be changed, these need to be moved somewhere else (e.g. S 5.2.1) or this should be removed. In S 5.3.1, Stateful filtering maintains packet-specific state information to aid in determining whether a filter rule has been met. For example, a device might apply stateless filtering to the first fragment of a fragmented IPv4 packet. If the filter matches, then the data unit ID may be remembered and other fragments of the same packet may then be considered to match the same filter. Stateful filtering is more commonly done in firewalls, although firewall technology may be added to routers. Data unit ID can also be Fragment Extension Header Identification field in IPv6. .. what is this "data unit ID"? Are you referring to the IP identification field or something else? Note that stateless IP fragmentation filtering is very difficult or impossible to do securely e.g. due to overlapping fragments and other issues (e.g. rfc 1858, 3128,..) - Rate Limit In some cases the set of packets matching a particular filter may be limited to a specified bandwidth. In this case, packets or bytes would be counted, and would be forwarded normally up to the specified limit. Excess packets may be discarded or may be marked (for example by setting a "discard eligible" bit in the IPv4 ToS field or the MPLS EXP field). .. there is no such thing as "discard eligible" bit in the IPv4 ToS field! In S 5.3.2, As with other access control techniques, the value of firewalls depends on a clear understanding of the topologies of the MPLS/GMPLS core network, the user networks, and the threat model. Their effectiveness depends on a topology with a clearly defined inside (secure) and outside (not secure). .. in todays security models, there often isn't such a clear separation of inside=secure and outside=insecure perimeter. In S 6, MPLS/GMPLS devices. Syslog WG is specifying "Logging Capabilities for IP Network Infrastructure". (The specific references will be made only if the draft(s) became RFC before this draft.) .. actually, I suppose you refer to OPSEC WG and http://tools.ietf.org/html/draft-ietf-opsec-logging-caps which was discontinued due to (afaik) lack of interest. I don't see why this couldn't be referenced as an informational reference even if the work was discontinued. In S 7(?), Isolation mechanisms might also be bypassed by IPv4 Router Alert or IPv6 using Next Header 0 packets. A solution could consists of disabling the processing of IP options. This drops or ignores all IP packets with IPv4 options, including the router alert option used by RSVP; however, this may have an impact on other protocols using IPv4 options. An alternative is to configure access-lists on all incoming interfaces dropping IPv4 protocol or IPv6 next header 46 (RSVP). ... did you mean s/Next Header 0/Next Header 46/ ? ... Can you actually configure such an ACL? At least with some vendors, you can only match the router alert option and can't know what's beyond that? RSVP neighbor filtering at the data plane level, with an access list to accept IP packets with port 46 only for specific neighbors requires Router Alert mode to be deactivated and does not protect against spoofing. .. "port 46" ? More confusion here... I suppose you mean "protocol" but see above, this may not be filterable? 7.1.3. Control Plane Protection with LDP The approaches to protect MPLS routers against LDP-based attacks are similar to those for RSVP, ... ... while true to some extent, it's much easier to protect LDP because it's not using router-alert option. From lmartini@cisco.com Tue Nov 10 13:11:41 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E483A67C2 for ; Tue, 10 Nov 2009 13:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 zlEDepFW7xCn for ; Tue, 10 Nov 2009 13:11:40 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 582333A62C1 for ; Tue, 10 Nov 2009 13:11:40 -0800 (PST) Received: from rasputin.monoski.com (host-113-189.meeting.ietf.org [133.93.113.189]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id nAALBvkG025504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 14:12:00 -0700 (MST) Message-ID: <4AF9D71D.7070704@cisco.com> Date: Tue, 10 Nov 2009 14:11:57 -0700 From: Luca Martini User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: mpls@ietf.org, mpls-tp@ietg.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 67.41.208.110 Subject: [mpls] WEBEX Meeting information for ietf76 MPLS-TP meeting X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:11:41 -0000 Topic: MPLS-TP Slide Sharing Meeting Date: Wednesday, November 11, 2009 Time: 9:00 am, Japan Time (Tokyo, GMT+09:00) Meeting Number: 207 655 358 Meeting Password: mpls ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://new-webex.webex.com/new-webex/j.php?ED=128946292&UID=0&PW=NMzRmNzVhYzEw&RT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: mpls 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://new-webex.webex.com/new-webex/j.php?ED=128946292&UID=0&PW=NMzRmNzVhYzEw&ORT=MiM0OQ%3D%3D ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://new-webex.webex.com/new-webex/mc 2. On the left navigation bar, click "Support". You can contact me at: To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://new-webex.webex.com/new-webex/j.php?ED=128946292&UID=0&ICS=UMI&LD=1&RD=2&ST=1&SHA2=FezzXFqQ6qupB1o2vYg9inLinUiThAPkXll-zKYg4II=&RT=MiM0OQ%3D%3D WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://new-webex.webex.com/new-webex/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://new-webex.webex.com/new-webex/systemdiagnosis.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. From root@core3.amsl.com Tue Nov 10 20:30:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C700A3A6C09; Tue, 10 Nov 2009 20:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091111043001.C700A3A6C09@core3.amsl.com> Date: Tue, 10 Nov 2009 20:30:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-igp-sync-bcast-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP IGP Synchronization for broadcast networks Author(s) : W. Lu, S. Kini Filename : draft-ietf-mpls-ldp-igp-sync-bcast-00.txt Pages : 7 Date : 2009-11-10 [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic (e.g. VPN) when IGP is operational on a link but LDP is not. If this mechanism is applied to broadcast links that have more than one LDP/IGP peer, the cost-out procedure can only be applied to the link as a whole but not an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-igp-sync-bcast-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-mpls-ldp-igp-sync-bcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-10202146.I-D@ietf.org> --NextPart-- From erosen@cisco.com Thu Nov 12 09:22:58 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD7C3A6BB4 for ; Thu, 12 Nov 2009 09:22:58 -0800 (PST) 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.000, 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 AyjTLmfPiulO for ; Thu, 12 Nov 2009 09:22:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9AD483A6AF2 for ; Thu, 12 Nov 2009 09:22:57 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,729,1249257600"; d="scan'208";a="67725031" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Nov 2009 17:23:26 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nACHNQW3006184; Thu, 12 Nov 2009 17:23:26 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id nACHNPRY017172; Thu, 12 Nov 2009 12:23:25 -0500 To: Yakov Rekhter In-reply-to: Your message of Mon, 09 Nov 2009 13:13:31 -0800. <200911092113.nA9LDVj06437@magenta.juniper.net> Date: Thu, 12 Nov 2009 12:23:25 -0500 Message-ID: <17171.1258046605@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, IJsbrand Wijnands Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 17:22:58 -0000 Yakov> What I showed in my example above is a fairly simple PIM-SM in ASM Yakov> mode scenario. Since as you said above, supporting this scenario "is Yakov> out of scope", the draft has to say that supporting PIM-SM in ASM Yakov> mode is "out of scope". That doesn't follow. Supporting PIM-SM in ASM mode does require that there be a way to discover the active sources, but joining a shared tree is not the only way to do that. It is fair to ask the draft to say something like the following: "When PIM-SM is used in ASM mode, the usual means of discovering active sources is to join a sparse mode shared tree. However, this document does not provide any method of transporting a sparse mode shared tree across an MPLS network. To apply the technique of this document to PIM-SM in ASM mode, there must be some other means of discovering the active sources. One possible means is the use of MSDP, but specification of such means is outside the scope of this document". Yakov> the draft needs to explicitly spell out how exactly MSDP will be used Yakov> in the scenarios like the one I showed above. Well, then it wouldn't be out of scope, would it? The notion of discovering the active sources without using a shared tree isn't exactly new; see, e.g., section 14 of draft-ietf-l3vpn-2547bis-mcast- bgp. From Adrian.Farrel@huawei.com Thu Nov 12 15:12:29 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F25B3A6AD1; Thu, 12 Nov 2009 15:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_20=-0.74, STOX_REPLY_TYPE=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 0TiSEAKHnIkj; Thu, 12 Nov 2009 15:12:28 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id B510F3A683B; Thu, 12 Nov 2009 15:12:28 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT000AS1R5LAV@usaga01-in.huawei.com>; Thu, 12 Nov 2009 15:12:58 -0800 (PST) Received: from your029b8cecfe (host-16-167.meeting.ietf.org [133.93.16.167]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KT000LC3R5JQN@usaga01-in.huawei.com>; Thu, 12 Nov 2009 15:12:57 -0800 (PST) Date: Thu, 12 Nov 2009 23:12:47 +0000 From: Adrian Farrel To: mpls-tp@ietf.org Message-id: <1831E07D877841779F627A8057822A53@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: mpls@ietf.org, pwe3@ietf.org Subject: [mpls] Which jabber room for MPLS-TP Friday morning? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 23:12:29 -0000 From root@core3.amsl.com Mon Nov 16 07:45:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 68C6F3A6A86; Mon, 16 Nov 2009 07:45:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091116154501.68C6F3A6A86@core3.amsl.com> Date: Mon, 16 Nov 2009 07:45:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-nm-framework-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Network Management Framework Author(s) : S. Mansfield, et al. Filename : draft-ietf-mpls-tp-nm-framework-02.txt Pages : 18 Date : 2009-11-16 This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-framework-02.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-mpls-tp-nm-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-16073249.I-D@ietf.org> --NextPart-- From yakov@juniper.net Mon Nov 16 08:02:06 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A193A6767 for ; Mon, 16 Nov 2009 08:02:06 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-RlxbeY0EvH for ; Mon, 16 Nov 2009 08:02:05 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 012C128C16F for ; Mon, 16 Nov 2009 08:02:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSwF3U6EwQwQj+2N22X0nAIxX+rVdQxqQ@postini.com; Mon, 16 Nov 2009 08:02:04 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 16 Nov 2009 07:51:48 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 07:51:48 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 07:51:48 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 07:51:47 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAGFplj69200; Mon, 16 Nov 2009 07:51:47 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911161551.nAGFplj69200@magenta.juniper.net> To: erosen@cisco.com In-Reply-To: <17171.1258046605@erosen-linux> References: <17171.1258046605@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Thu, 12 Nov 2009 12:23:25 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18065.1258386707.1@juniper.net> Date: Mon, 16 Nov 2009 07:51:47 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 16 Nov 2009 15:51:47.0938 (UTC) FILETIME=[B4694C20:01CA66D4] Cc: mpls@ietf.org, IJsbrand Wijnands Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:02:06 -0000 Eric, > Yakov> What I showed in my example above is a fairly simple PIM-SM in ASM > Yakov> mode scenario. Since as you said above, supporting this scenario "is > Yakov> out of scope", the draft has to say that supporting PIM-SM in ASM > Yakov> mode is "out of scope". > > That doesn't follow. Supporting PIM-SM in ASM mode does require that there > be a way to discover the active sources, but joining a shared tree is not > the only way to do that. Let's be a bit more precise... PIM-SM is specified in rfc4601. Support for the ASM service model with PIM-SM, as defined in rfc4601, *does require a shared tree* to discover the active sources. There are other ways to discovery the active sources in the ASM service model, but they are outside the scope of rfc4601, and thus are outside the scope of PIM-SM. > It is fair to ask the draft to say something like the following: > > "When PIM-SM is used in ASM mode, the usual means of discovering > active sources is to join a sparse mode shared tree. When PIM-SM is used to support the ASM service model joining a sparse mode shared tree is not "the usual means", but *the required* mean. > However, this > document does not provide any method of transporting a sparse mode > shared tree across an MPLS network. That is certainly correct. > To apply the technique of this > document to PIM-SM in ASM mode, there must be some other means of > discovering the active sources. Either that, or a method of transporting a sparse mode shared tree across an MPLS network. > One possible means is the use of > MSDP, but specification of such means is outside the scope of this > document". Not only "specification of such means is outside the scope of this document", but also the interaction of such means with the MPLS network is outside the scope of this document. Wrt MSDP as "one possible means" please note that the MSDP spec (rfc3618) specifies just two possible deployment scenarios: (1) between PIM domains, and (2) between Anycast-RPs. If one proposes to use MSDP to support the ASM service model over an MPLS network, then one has to spell out how these two deployment scenarios apply in this context. With the above comments in mind, I'd like to propose to add the following to the draft: Supporting the ASM service model with PIM-SM [RFC4601] requires a sparse mode shared tree as the way of discovering active sources. However, this document does not provide any method of transporting a sparse mode shared tree across an MPLS network. To apply the technique of this document to the ASM service model, there must be either (a) some other means of discovering active sources, outside of PIM-SM, or (b) a method of transporting a sparse mode shared tree across an MPLS network. The specification of such means and their interaction with an MPLS network is outside the scope of this document. Likewise, the specification of a method of transporting a sparse mode shared tree across an MPLS network is outside the scope of this document. Thus, supporting the ASM service model over an MPLS network is outside the scope of this document. > Yakov> the draft needs to explicitly spell out how exactly MSDP will be used > Yakov> in the scenarios like the one I showed above. > > Well, then it wouldn't be out of scope, would it? > > The notion of discovering the active sources without using a shared tree > isn't exactly new; see, e.g., section 14 of draft-ietf-l3vpn-2547bis-mcast- > bgp. That is correct. Please see draft-rekhter-pim-sm-over-mldp-00.txt for more details. Yakov. From Martin.Vigoureux@alcatel-lucent.com Tue Nov 17 02:52:12 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9B43A693C; Tue, 17 Nov 2009 02:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 mxAwPcCk4lum; Tue, 17 Nov 2009 02:52:11 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 905D33A68CE; Tue, 17 Nov 2009 02:52:11 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAHAq5BX004461; Tue, 17 Nov 2009 11:52:07 +0100 Received: from [172.27.205.212] ([172.27.205.212]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 11:51:16 +0100 Message-ID: <4B028023.5030505@alcatel-lucent.com> Date: Tue, 17 Nov 2009 11:51:15 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2009 10:51:16.0186 (UTC) FILETIME=[E3100BA0:01CA6773] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: [mpls] IETF 76 Minutes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:52:12 -0000 All, I have uploaded the minutes for all presentations (mpls and mpls-tp) http://www.ietf.org/proceedings/09nov/minutes/mpls.txt These are preliminary minutes. Please check. The open discussion that went on Friday is not yet captured. We are working with Dave S. on that matter. regards, martin From erosen@cisco.com Tue Nov 17 09:41:20 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FEA28C0EA for ; Tue, 17 Nov 2009 09:41:20 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsupO9VUeCPF for ; Tue, 17 Nov 2009 09:41:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BEFBA3A6AE4 for ; Tue, 17 Nov 2009 09:41:18 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,759,1249257600"; d="scan'208";a="68502503" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2009 17:41:17 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHHfG5B007608; Tue, 17 Nov 2009 17:41:17 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id nAHHfGtR009924; Tue, 17 Nov 2009 12:41:16 -0500 To: Yakov Rekhter In-reply-to: Your message of Mon, 16 Nov 2009 07:51:47 -0800. <200911161551.nAGFplj69200@magenta.juniper.net> Date: Tue, 17 Nov 2009 12:41:16 -0500 Message-ID: <9923.1258479676@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, IJsbrand Wijnands Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:41:20 -0000 Eric> Supporting PIM-SM in ASM mode does require that there be a way to Eric> discover the active sources, but joining a shared tree is not the only Eric> way to do that. Yakov> PIM-SM is specified in rfc4601. Support for the ASM service model Yakov> with PIM-SM, as defined in rfc4601, *does require a shared tree* to Yakov> discover the active sources. Please see RFC 4611, which explains how to support the ASM service model with PIM-SM and MSDP. In this BCP, active sources are not always discovered via the shared tree, yet PIM-SM is still used. You may also wish to look at draft-rekhter-pim-sm-over-mldp-00.txt, which specifies another way of using PIM-SM in ASM mode without using a shared tree to discover the active sources. Yakov> supporting the ASM service model over an MPLS network is outside Yakov> the scope of this document. I don't really see what's wrong with what I proposed: "When PIM-SM is used in ASM mode, the usual means of discovering active sources is to join a sparse mode shared tree. However, this document does not provide any method of transporting a sparse mode shared tree across an MPLS network. To apply the technique of this document to PIM-SM in ASM mode, there must be some other means of discovering the active sources. One possible means is the use of MSDP, but specification of such means is outside the scope of this document". We'd be happy to add that another possible means of dicovering the active sources is specified in draft-rekhter-pim-sm-over-mldp-00.txt. From venkatflex@gmail.com Tue Nov 17 11:12:20 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E123A699D; Tue, 17 Nov 2009 11:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] 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 RkX-Udzd8KBV; Tue, 17 Nov 2009 11:12:19 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 38A4E3A699C; Tue, 17 Nov 2009 11:12:19 -0800 (PST) Received: by pwi6 with SMTP id 6so181837pwi.29 for ; Tue, 17 Nov 2009 11:12:15 -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:content-type; bh=JwSAOm+2IBK3Y/tZan6Z/JUJL80nlEN/6gbV6xgy1KU=; b=Y/D+rpgAVrwFDutFmiQ4go5+ppjS4GjCrXdifsGcihGZx1nPgUzVbGIbC2HMonTIQt hYps8vWD1iw6EoSrELFHJaPRHX+ntp+V6V+zf2v04tXqeFGMbF+s0mEZGYi422oJ/lJE tSy663lzn4CvrfSSO56ZEziZ9kSwIHOq+RbDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qn1dh99XTsiB7eTsaVNqgLybc//QTr/OUsAF2/a9G1MJS4tRmN9XWcat7kCw6ciz5e /uBzQRJzXHFwGeuKANczgvqg6ZA28vpb8498YzXky4ZdnSzbUCsIjwfujlH0LtP1bko7 HHS0XQKRdDgHVIgqjtKukp40vdVqyCkVWwi+0= MIME-Version: 1.0 Received: by 10.142.209.12 with SMTP id h12mr1059372wfg.53.1258485135649; Tue, 17 Nov 2009 11:12:15 -0800 (PST) Date: Wed, 18 Nov 2009 00:42:15 +0530 Message-ID: <715756490911171112j51ccfb07yac3feffaff08d6ec@mail.gmail.com> From: venkatesan mahalingam To: mpls , mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32e12772df4047895e7ca Subject: [mpls] MPLS-TP MS-PW X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:12:20 -0000 --000e0cd32e12772df4047895e7ca Content-Type: text/plain; charset=ISO-8859-1 Hi All, As per IETF draft draft-ietf-pwe3-dynamic-ms-pw-10.txt, A Multi-Segment PW is defined as a set of two or more * contiguous PW segments* that behave and function as a single point- to-point PW, but in the MPLS-TP overview-22.ppt document, *Intra-domain MS-PW - it seems that continguous PW segments (Pw1-Pw2) are not followed, instead stacking PWs labels are used [Pw1-Pw1 (Pw2)-Pw1(Pw2)-Pw1] Please help me to understand. Thanks in advance, Regards, Venkat. * --000e0cd32e12772df4047895e7ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi All,

As per IETF draft 
draft-ietf-pwe3-dynamic-ms-pw-10.=
txt,
A Multi-Segment PW is defined as a set of two or more
   c=
ontiguous PW segments that behave and function as a single point-
   to-point PW,
but in the MPLS-TP overview-22.ppt document, 
.O
	{color:black;}
a:link
	{color:#83A2CF !important;}
a:active
	{color:#B21A1A !important;}
a:visited
	{color:#EFB525 !important;}


Intra-domain MS-PW - it seems that continguous PW =
segments (Pw1-Pw2) are not followed, 
instead stacking PWs labels are us=
ed [Pw1-Pw1 (Pw2)-Pw1(Pw2)-Pw1]


Please help me to understand. 

Thanks in advance,

Regards=
,
Venkat.
=A0
<=
br>

--000e0cd32e12772df4047895e7ca-- From yakov@juniper.net Tue Nov 17 11:49:44 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE94B3A6BDA for ; Tue, 17 Nov 2009 11:49:44 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo4kgbWvqO54 for ; Tue, 17 Nov 2009 11:49:44 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id DA0D83A6BD3 for ; Tue, 17 Nov 2009 11:49:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSwL+VI3wAVrh/VEkFC6Hnptqj0PuhXSB@postini.com; Tue, 17 Nov 2009 11:49:43 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 17 Nov 2009 11:47:07 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 11:47:08 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 11:47:07 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 11:47:06 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAHJl6j45714; Tue, 17 Nov 2009 11:47:06 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911171947.nAHJl6j45714@magenta.juniper.net> To: erosen@cisco.com In-Reply-To: <9923.1258479676@erosen-linux> References: <9923.1258479676@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Tue, 17 Nov 2009 12:41:16 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75701.1258487226.1@juniper.net> Date: Tue, 17 Nov 2009 11:47:06 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 17 Nov 2009 19:47:06.0788 (UTC) FILETIME=[BE509640:01CA67BE] Cc: mpls@ietf.org, IJsbrand Wijnands Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:49:45 -0000 Eric, > Eric> Supporting PIM-SM in ASM mode does require that there be a way to > Eric> discover the active sources, but joining a shared tree is not the only > Eric> way to do that. > > Yakov> PIM-SM is specified in rfc4601. Support for the ASM service model > Yakov> with PIM-SM, as defined in rfc4601, *does require a shared tree* to > Yakov> discover the active sources. > > Please see RFC 4611, which explains how to support the ASM service model > with PIM-SM and MSDP. In this BCP, active sources are not always discovered > via the shared tree, yet PIM-SM is still used. To support the ASM service model over an MPLS network the combination of PIM-SM (rfc4601) and rfc4611 is insufficient, as the deployment scenarios described in rfc4611 do not cover MPLS network. > You may also wish to look at draft-rekhter-pim-sm-over-mldp-00.txt, which > specifies another way of using PIM-SM in ASM mode without using a shared > tree to discover the active sources. Thanks for repeating what I said in my previous e-mail: Eric> The notion of discovering the active sources without using Eric> a shared tree isn't exactly new; see, e.g., section 14 of Eric> draft-ietf-l3vpn-2547bis-mcast-bgp. Yakov> That is correct. Please see draft-rekhter-pim-sm-over-mldp-00.txt Yakov> for more details. > Yakov> supporting the ASM service model over an MPLS network is outside > Yakov> the scope of this document. > > I don't really see what's wrong with what I proposed: > > "When PIM-SM is used in ASM mode, the usual means of discovering > active sources is to join a sparse mode shared tree. However, this > document does not provide any method of transporting a sparse mode > shared tree across an MPLS network. To apply the technique of this > document to PIM-SM in ASM mode, there must be some other means of > discovering the active sources. One possible means is the use of > MSDP, but specification of such means is outside the scope of this > document". What's wrong with what you proposed is that it still refuses to explicitly spell out that supporting the ASM service model over an MPLS network is outside the scope of this document. In other words, what is missing in what you proposed is the following sentence: Supporting the ASM service model over an MPLS network is outside the scope of this document. > We'd be happy to add that another possible means of dicovering the active > sources is specified in draft-rekhter-pim-sm-over-mldp-00.txt. That would be fine. Yakov. From root@core3.amsl.com Tue Nov 17 20:30:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B997E3A6918; Tue, 17 Nov 2009 20:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091118043001.B997E3A6918@core3.amsl.com> Date: Tue, 17 Nov 2009 20:30:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-explicit-resource-control-bundle-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Component Link Recording and Resource Control for TE Link Bundles Author(s) : Z. Ali, D. Papadimitriou Filename : draft-ietf-mpls-explicit-resource-control-bundle-06.txt Pages : 12 Date : 2009-11-17 Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service A.Zamfir et al. - Expires May 2010 [page 1] Component Link Record. & Resource Control for TE Link Bundles providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-resource-control-bundle-06.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-mpls-explicit-resource-control-bundle-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-17202909.I-D@ietf.org> --NextPart-- From ice@cisco.com Wed Nov 18 06:02:00 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1D23A6A8D for ; Wed, 18 Nov 2009 06:02:00 -0800 (PST) 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 DDrit4qipUzJ for ; Wed, 18 Nov 2009 06:02:00 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B41B73A6959 for ; Wed, 18 Nov 2009 06:01:59 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAIE1uqc013864; Wed, 18 Nov 2009 15:01:56 +0100 (CET) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAIE1uti015171; Wed, 18 Nov 2009 15:01:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <200911171947.nAHJl6j45714@magenta.juniper.net> Date: Wed, 18 Nov 2009 15:01:55 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <9923.1258479676@erosen-linux> <200911171947.nAHJl6j45714@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:02:01 -0000 Yakov, >> >> I don't really see what's wrong with what I proposed: >> >> "When PIM-SM is used in ASM mode, the usual means of discovering >> active sources is to join a sparse mode shared tree. However, >> this >> document does not provide any method of transporting a sparse >> mode >> shared tree across an MPLS network. To apply the technique of >> this >> document to PIM-SM in ASM mode, there must be some other means >> of >> discovering the active sources. One possible means is the use >> of >> MSDP, but specification of such means is outside the scope of >> this >> document". > > What's wrong with what you proposed is that it still refuses to > explicitly spell out that supporting the ASM service model over an > MPLS network is outside the scope of this document. In other words, > what is missing in what you proposed is the following sentence: > > Supporting the ASM service model over an MPLS network > is outside the scope of this document. I already tried to explain to you that this is too restrictive. Only a specific part of the ASM model is out of scope, that that is what Eric proposed in the text above. Its wrong to claim the whole ASM service model is out of scope. One example, in ASM the (S,G) inherits the (*,G) O-list. This is typical behavior that is needed in combination with MSDP and BGP A-D S-A's. You're response to this is probably that the draft needs to spell this out. However, this is basic PIM ASM behavior that does not belong in this draft. All the PIM ASM procedures apply, except what has been written above by Eric. Thx, Ice. From erosen@cisco.com Wed Nov 18 06:54:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48833A6A3F for ; Wed, 18 Nov 2009 06:54:33 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iottxqfun1rP for ; Wed, 18 Nov 2009 06:54:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 070F23A6957 for ; Wed, 18 Nov 2009 06:54:32 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,765,1249257600"; d="scan'208";a="68749359" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2009 14:54:30 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAIEsUqI027745; Wed, 18 Nov 2009 14:54:30 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id nAIEsUAv020765; Wed, 18 Nov 2009 09:54:30 -0500 To: "John G. Scudder" In-reply-to: Your message of Mon, 09 Nov 2009 18:10:27 +0900. Date: Wed, 18 Nov 2009 09:54:30 -0500 Message-ID: <20764.1258556070@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, ice@cisco.com Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:54:34 -0000 John> contrast to the existing CsC solutions if possible That's a fair request. The solution described in sections 15, 11.1.2 and 11.3.2 of draft-ietf-l3vpn-2547bis-mcast-bgp presupposes the use of mLDP on the interface between the "outer carrier" and the "inner carrier". It uses BGP C-multicast routing to convey the outer carrier's mLDP signaling information, and uses BGP S-PMSI A-D routes to assign the outer carrier's mLDP-based P2MP LSPs to P-tunnels of the inner carrier. If a particular deployment supports upstream-assigned MPLS labels, this can be used to allow aggregation of multiple P2MP LSPs from the outer carrier into a single P-tunnel of the inner carrier. Now consider a deployment scenario with the following properties: - The inner carrier has not deployed and/or does not want to deploy BGP C-multicast routing. - The inner carrier and the outer carrier both use mLDP for their P-tunnels. - The inner carrier is not concerned about aggregation (either because upstream-assigned labels are not available, or because it doesn't want the sub-optimal routing that comes with aggregation). In this scenario, the simple "in-band" signaling of draft-wijnands-mpls- mldp-csc provides a much simpler solution. We think this will be a quite common deployment scenario. Of course, if a carrier's carrier does want to do aggregation and does want to deploy BGP C-multicast routing, those options are certainly available in the overall solution set. From wwwrun@core3.amsl.com Wed Nov 18 10:35:55 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 304E83A694D; Wed, 18 Nov 2009 10:35:54 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091118183555.304E83A694D@core3.amsl.com> Date: Wed, 18 Nov 2009 10:35:55 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, Ghani.Abbas@ericsson.com, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS112 - MPLS-TP Survivability Framework reviewed (ref # 012.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:35:55 -0000 Title: LS112 - MPLS-TP Survivability Framework reviewed (ref # 012.02) Submission Date: 2009-11-18 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=618 Please reply by 2010-04-30 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Ghani.Abbas@ericsson.com hhelvoort@huawei.com Purpose: For action Body: Thank you for your liaison statement (ref # 012.01) requesting an early review by the ITU-T of the MPLS-TP survivability framework draft. The experts of Q.9/15 have reviewed draft-ietf-mpls-tp-survive-fwk-02.txt by correspondence and have some comments and proposed changes shown in the attached marked up draft. These proposals reflect the consensus view of the experts. Due to the large number of comments Q9/15 experts made we request to have an opportunity to review the updated draft before it goes for WG LC in the IETF process. See attachment OLS-112att Attachment(s): LS112 - MPLS-TP Survivability Framework reviewed (ref # 012.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file738.pdf) LS112 - MPLS-TP Survivability Framework reviewed (ref # 012.02) - pdf attachment (https://datatracker.ietf.org/documents/LIAISON/file739.pdf) From loa@pi.nu Thu Nov 19 04:19:18 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7AA3A6B2F for ; Thu, 19 Nov 2009 04:19:18 -0800 (PST) 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 TzWUkPtUdPb3 for ; Thu, 19 Nov 2009 04:19:17 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 6FEB53A6A00 for ; Thu, 19 Nov 2009 04:19:17 -0800 (PST) Received: from [192.36.158.66] (wdhcp-158-66.verkstad.net [192.36.158.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 2FAAFD4056; Thu, 19 Nov 2009 13:19:12 +0100 (CET) Message-ID: <4B0537BC.7050807@pi.nu> Date: Thu, 19 Nov 2009 13:19:08 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org, George Swallow , Adrian Farrel , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:19:18 -0000 All, this is to start a two week poll in making draft-wijnands-mpls-in-band-signaling-02 an MPLS working group document. Send a mail to the working group (mpls@ietf.org) mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Dec 6, 2009. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wim.henderickx@alcatel-lucent.be Thu Nov 19 05:32:13 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73533A6A9A for ; Thu, 19 Nov 2009 05:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 0fpxfppctTdb for ; Thu, 19 Nov 2009 05:32:12 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 7D5EA3A68E7 for ; Thu, 19 Nov 2009 05:32:12 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAJDW53l009088; Thu, 19 Nov 2009 14:32:05 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 14:32:05 +0100 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 Date: Thu, 19 Nov 2009 14:32:03 +0100 Message-ID: In-Reply-To: <4B0537BC.7050807@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document Thread-Index: AcppEpS+0ZSWsWR5Sv++sMDonfSsOAAChQPQ References: <4B0537BC.7050807@pi.nu> From: "HENDERICKX Wim" To: "Loa Andersson" , , "George Swallow" , "Adrian Farrel" , "VIGOUREUX MARTIN" X-OriginalArrivalTime: 19 Nov 2009 13:32:05.0038 (UTC) FILETIME=[AF0D84E0:01CA691C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:32:13 -0000 support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: donderdag 19 november 2009 13:19 To: mpls@ietf.org; George Swallow; Adrian Farrel; VIGOUREUX MARTIN Subject: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document All, this is to start a two week poll in making draft-wijnands-mpls-in-band-signaling-02 an MPLS working group document. Send a mail to the working group (mpls@ietf.org) mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Dec 6, 2009. /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Thu Nov 19 06:08:29 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031B63A68CC for ; Thu, 19 Nov 2009 06:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 CJjR-bMg1kDJ for ; Thu, 19 Nov 2009 06:08:28 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E25043A680C for ; Thu, 19 Nov 2009 06:08:27 -0800 (PST) Received: by bwz23 with SMTP id 23so2491414bwz.29 for ; Thu, 19 Nov 2009 06:08:22 -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:content-type; bh=UmCG4ZgzeLOhfn1v1qjPt1GobpTNmObnI5dpfnWjC2I=; b=LgC1u/0ot5Hwj1DYO+fOFaSr0p5wGcFS33CAut+fjPBBP4SrNqUBSrBOzPXc6SyMbd 8yzQTMNXxZ305hpy2S19Fvq083Y5wkd7xkZJSizi7r40kZRevYmVDr7S15SlnrbPH707 3820hoLOJn10Fcj6566+b/SKP2YV+pdQ3yo8Y= 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=nYLCgGTGmFZsAQtIbA13IcbIBkixwAFg/bPyDqkuMv4smTn60G9NDrnlNrnolh/M6D ppSprBtPPAUO4GcbpSTl+H2t056NZWBuxJbXvlu4+Ibsrx5GUe+fL+ihKKcz1t4P0bzC rXVfghq1tk0HnAt/AaN8ki1mGDpoNuItUIhiI= MIME-Version: 1.0 Received: by 10.204.34.5 with SMTP id j5mr59076bkd.5.1258639702673; Thu, 19 Nov 2009 06:08:22 -0800 (PST) In-Reply-To: <4B0537BC.7050807@pi.nu> References: <4B0537BC.7050807@pi.nu> Date: Thu, 19 Nov 2009 06:08:22 -0800 Message-ID: <787be2780911190608r42cdb67dm5d26ad25da9d7313@mail.gmail.com> From: Greg Mirsky To: mpls@ietf.org Content-Type: multipart/alternative; boundary=00032555af7660ca770478b9e4b9 Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:08:29 -0000 --00032555af7660ca770478b9e4b9 Content-Type: text/plain; charset=ISO-8859-1 support On Thu, Nov 19, 2009 at 4:19 AM, Loa Andersson wrote: > All, > > this is to start a two week poll in making > > draft-wijnands-mpls-in-band-signaling-02 > > an MPLS working group document. > > Send a mail to the working group (mpls@ietf.org) mailing list, > indicating "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Dec 6, 2009. > > /Loa > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --00032555af7660ca770478b9e4b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable support


On Thu, Nov 19, 2009 at 4:19 = AM, Loa Andersson <loa@pi= .nu> wrote:
All,

this is to start a two week poll in making

draft-wijnands-mpls-in-band-signaling-02

an MPLS working group document.

Send a mail to the working group (mpls@ietf.org) mailing list,
indicating "yes/support" or "no/do not support".

Comments on the content of the draft should be sent to the same
mailing list with a different subject line.

The poll ends Sun Dec 6, 2009.

/Loa
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--00032555af7660ca770478b9e4b9-- From zali@cisco.com Thu Nov 19 08:07:12 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D683D3A6971 for ; Thu, 19 Nov 2009 08:07:12 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1Z5UszDlvIw for ; Thu, 19 Nov 2009 08:07:11 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 71E7E3A693C for ; Thu, 19 Nov 2009 08:07:11 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD77BEutJV2c/2dsb2JhbAC+I5dvAoQ5BA X-IronPort-AV: E=Sophos;i="4.44,771,1249257600"; d="scan'208";a="68919055" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2009 16:06:56 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id nAJG6pBo006854; Thu, 19 Nov 2009 16:06:51 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:06:51 -0600 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 Date: Thu, 19 Nov 2009 10:06:50 -0600 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B29181B@XMB-RCD-103.cisco.com> In-Reply-To: <4B0537BC.7050807@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document thread-index: AcppEomNl1Myi5xATZWde93YkFaFhAAGocCw References: <4B0537BC.7050807@pi.nu> From: "Zafar Ali (zali)" To: "Loa Andersson" , , "George Swallow (swallow)" , "Adrian Farrel" , "Martin Vigoureux" X-OriginalArrivalTime: 19 Nov 2009 16:06:51.0067 (UTC) FILETIME=[4DF518B0:01CA6932] Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:07:13 -0000 yes/support Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, November 19, 2009 7:19 AM > To: mpls@ietf.org; George Swallow (swallow); Adrian Farrel;=20 > Martin Vigoureux > Subject: [mpls] poll on making=20 > draft-wijnands-mpls-in-band-signaling-02 an mpls wg document >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-wijnands-mpls-in-band-signaling-02 >=20 > an MPLS working group document. >=20 > Send a mail to the working group (mpls@ietf.org) mailing=20 > list, indicating "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Sun Dec 6, 2009. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From N.Leymann@telekom.de Thu Nov 19 10:32:44 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6683A6962 for ; Thu, 19 Nov 2009 10:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Xglu4zLMk695 for ; Thu, 19 Nov 2009 10:32:43 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id DAA1B3A682F for ; Thu, 19 Nov 2009 10:32:42 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 19 Nov 2009 19:32:34 +0100 Received: from S4DE9JSAAIB.ost.t-com.de ([10.125.177.167]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 19:32:34 +0100 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 Date: Thu, 19 Nov 2009 19:32:31 +0100 Message-ID: <4395962A7C18D84191B205AD708969830553001C@S4DE9JSAAIB.ost.t-com.de> In-Reply-To: <4B0537BC.7050807@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document Thread-Index: AcppEpYunU3IufRUTDa+ufkS9tvF7AANAGlw References: <4B0537BC.7050807@pi.nu> From: To: , , , , X-OriginalArrivalTime: 19 Nov 2009 18:32:34.0112 (UTC) FILETIME=[A937E400:01CA6946] Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:32:44 -0000 Support! Nic=20 -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von = Loa Andersson Gesendet: Donnerstag, 19. November 2009 13:19 An: mpls@ietf.org; George Swallow; Adrian Farrel; Martin Vigoureux Betreff: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 = an mpls wg document All, this is to start a two week poll in making draft-wijnands-mpls-in-band-signaling-02 an MPLS working group document. Send a mail to the working group (mpls@ietf.org) mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Dec 6, 2009. /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From wwwrun@core3.amsl.com Thu Nov 19 11:21:05 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1725228C0DE; Thu, 19 Nov 2009 11:21:04 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091119192105.1725228C0DE@core3.amsl.com> Date: Thu, 19 Nov 2009 11:21:05 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] Updated Liaison Statement, "LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:21:05 -0000 Title: LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02) Submission Date: 2009-11-10 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=614 Please reply by 2010-01-02 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@huawei.com Purpose: For action Body: Thank you for your liaison statement (ref # 009.01) requesting an early review by the ITU-T of the MPLS-TP framework draft. The experts of Q.12/15 have reviewed draft-ietf-mpls-tp-framework-06 by correspondence and have some comments and proposed changes shown in the attached marked up draft. These proposals reflect the consensus view of the experts. We have also received some further (late) comments that are still under consideration in Q.12. We will convey these further comments on or before 25th November 2009. Attachment(s): LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file732.pdf) LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02) - pdf attachment with comments (https://datatracker.ietf.org/documents/LIAISON/file740.pdf) From yakov@juniper.net Thu Nov 19 12:49:44 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71143A6847 for ; Thu, 19 Nov 2009 12:49:44 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIo67MTDzsaJ for ; Thu, 19 Nov 2009 12:49:43 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 869903A6828 for ; Thu, 19 Nov 2009 12:49:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSwWvZNPoJbvF1fduBcTJGMcjwJNADda3@postini.com; Thu, 19 Nov 2009 12:49:41 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 19 Nov 2009 12:45:25 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:45:26 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:45:25 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:45:25 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAJKjOj80526; Thu, 19 Nov 2009 12:45:24 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911192045.nAJKjOj80526@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: References: <9923.1258479676@erosen-linux> <200911171947.nAHJl6j45714@magenta.juniper.net> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Wed, 18 Nov 2009 15:01:55 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66543.1258663524.1@juniper.net> Date: Thu, 19 Nov 2009 12:45:24 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 19 Nov 2009 20:45:25.0218 (UTC) FILETIME=[385E2420:01CA6959] Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:49:44 -0000 Ice, > >> > >> I don't really see what's wrong with what I proposed: > >> > >> "When PIM-SM is used in ASM mode, the usual means of discovering > >> active sources is to join a sparse mode shared tree. However, this > >> document does not provide any method of transporting a sparse mode > >> shared tree across an MPLS network. To apply the technique of this > >> document to PIM-SM in ASM mode, there must be some other means of > >> discovering the active sources. One possible means is the use of > >> MSDP, but specification of such means is outside the scope of this > >> document". > > > > What's wrong with what you proposed is that it still refuses to > > explicitly spell out that supporting the ASM service model over an > > MPLS network is outside the scope of this document. In other words, > > what is missing in what you proposed is the following sentence: > > > > Supporting the ASM service model over an MPLS network > > is outside the scope of this document. > > I already tried to explain to you that this is too restrictive. Only a > specific part of the ASM model is out of scope, that that is what Eric > proposed in the text above. Its wrong to claim the whole ASM service > model is out of scope. One example, in ASM the (S,G) inherits the > (*,G) O-list. This is typical behavior that is needed in combination > with MSDP and BGP A-D S-A's. > > You're response to this is probably that the draft needs to spell this > out. However, this is basic PIM ASM behavior that does not belong in > this draft. All the PIM ASM procedures apply, except what has been > written above by Eric. Since as you said above part of the ASM model is out of scope, then the document should say the following: This document specifies support for some, but not all parts of the ASM service model. Yakov. From yakov@juniper.net Thu Nov 19 12:57:55 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD32B28C111 for ; Thu, 19 Nov 2009 12:57:55 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sazAEmp132te for ; Thu, 19 Nov 2009 12:57:55 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 74CE228C103 for ; Thu, 19 Nov 2009 12:57:50 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSwWxSefJ1EVHLYxTSBp88rSK2SoM+WiP@postini.com; Thu, 19 Nov 2009 12:57:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 19 Nov 2009 12:55:22 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:55:23 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:55:22 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:55:21 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAJKtLj84222; Thu, 19 Nov 2009 12:55:21 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911192055.nAJKtLj84222@magenta.juniper.net> To: Loa Andersson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67504.1258664120.1@juniper.net> Date: Thu, 19 Nov 2009 12:55:21 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 19 Nov 2009 20:55:21.0621 (UTC) FILETIME=[9BDA0450:01CA695A] Cc: mpls@ietf.org Subject: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:57:55 -0000 Loa, > this is to start a two week poll in making > > draft-wijnands-mpls-in-band-signaling-02 > > an MPLS working group document. > > Send a mail to the working group (mpls at ietf.org) mailing list, > indicating "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Dec 6, 2009. Given that the authors of the draft agreed to make make certain changes wrt clarifying procedures for handling PIM-Bidir, and given that the draft still does not clearly spell out its applicability wrt the ASM service model, I think it would be more appropriate to let the authors revised the draft, and then issue the poll on the *revised* document. Yakov. From zali@cisco.com Thu Nov 19 13:29:47 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277A53A6864 for ; Thu, 19 Nov 2009 13:29:47 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL-HPTEX1xfG for ; Thu, 19 Nov 2009 13:29:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 421B73A6851 for ; Thu, 19 Nov 2009 13:29:46 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB5IBUurRN+K/2dsb2JhbAC+FZd1hDsE X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="436277012" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2009 21:29:44 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAJLTiLH025524; Thu, 19 Nov 2009 21:29:44 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:29:43 -0600 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 Date: Thu, 19 Nov 2009 15:29:41 -0600 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B291A09@XMB-RCD-103.cisco.com> In-Reply-To: <200911192055.nAJKtLj84222@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 anmpls wg document thread-index: AcppWxe+0W9Y1W6FSnCsfOKSYjzqoAAAJk2A References: <200911192055.nAJKtLj84222@magenta.juniper.net> From: "Zafar Ali (zali)" To: "Yakov Rekhter" , "Loa Andersson" X-OriginalArrivalTime: 19 Nov 2009 21:29:43.0597 (UTC) FILETIME=[68E295D0:01CA695F] Cc: mpls@ietf.org Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 anmpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:29:47 -0000 Yokov-=20 As you know better than most of us that being a WG document does not mean that document will be frozen. In fact as you know WG documents are owned by the WG (instead of authors) making sure all comments are addressed and not lost is even more easier. Furthermore you mentioned that authors have agreed to address the comment, your point becomes more mute. The document is a good starting point and we should accept the draft and work the issues you have raised through the normal WG process. =20 Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Yakov Rekhter > Sent: Thursday, November 19, 2009 3:55 PM > To: Loa Andersson > Cc: mpls@ietf.org > Subject: [mpls] poll on making=20 > draft-wijnands-mpls-in-band-signaling-02 anmpls wg document >=20 > Loa, >=20 > > this is to start a two week poll in making > >=20 > > draft-wijnands-mpls-in-band-signaling-02 > >=20 > > an MPLS working group document. > >=20 > > Send a mail to the working group (mpls at ietf.org) mailing list,=20 > > indicating "yes/support" or "no/do not support". > >=20 > > Comments on the content of the draft should be sent to the same=20 > > mailing list with a different subject line. > >=20 > > The poll ends Sun Dec 6, 2009. >=20 > Given that the authors of the draft agreed to make make=20 > certain changes wrt clarifying procedures for handling=20 > PIM-Bidir, and given that the draft still does not clearly=20 > spell out its applicability wrt the ASM service model, I=20 > think it would be more appropriate to let the authors revised=20 > the draft, and then issue the poll on the > *revised* document. >=20 > Yakov. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From erosen@cisco.com Thu Nov 19 13:56:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B747D3A6A21 for ; Thu, 19 Nov 2009 13:56:33 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2eW6Ev15Jze for ; Thu, 19 Nov 2009 13:56:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CB3123A69E2 for ; Thu, 19 Nov 2009 13:56:32 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,773,1249257600"; d="scan'208";a="68985501" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2009 21:56:29 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAJLuT7N028224; Thu, 19 Nov 2009 21:56:29 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id nAJLuSF4004439; Thu, 19 Nov 2009 16:56:29 -0500 To: Loa Andersson In-reply-to: Your message of Thu, 19 Nov 2009 13:19:08 +0100. <4B0537BC.7050807@pi.nu> Date: Thu, 19 Nov 2009 16:56:28 -0500 Message-ID: <4438.1258667788@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:56:33 -0000 Support. From ice@cisco.com Thu Nov 19 23:13:39 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4973A69E3 for ; Thu, 19 Nov 2009 23:13:39 -0800 (PST) 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 jt5rQ7F82NgM for ; Thu, 19 Nov 2009 23:13:37 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9F0653A63C9 for ; Thu, 19 Nov 2009 23:13:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAK79l7h003894; Fri, 20 Nov 2009 08:09:47 +0100 (CET) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAK79kLo012600; Fri, 20 Nov 2009 08:09:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed From: IJsbrand Wijnands In-Reply-To: <200911192045.nAJKjOj80526@magenta.juniper.net> Date: Fri, 20 Nov 2009 08:09:46 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0E44463A-22BC-4F90-BBF2-A4727D17E2DA@cisco.com> References: <9923.1258479676@erosen-linux> <200911171947.nAHJl6j45714@magenta.juniper.net> <200911192045.nAJKjOj80526@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 07:13:39 -0000 Yakov, > Since as you said above part of the ASM model is out of scope, then > the document should say the following: > > This document specifies support for some, but not all parts > of the ASM service model. Yes, that is fine. Thx, Ice. From Joerg.Kuechemann@telekom.de Mon Nov 23 00:11:55 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8ACF3A68FD for ; Mon, 23 Nov 2009 00:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, 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 HZUr4QPZ7yL2 for ; Mon, 23 Nov 2009 00:11:53 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 575953A68C5 for ; Mon, 23 Nov 2009 00:11:53 -0800 (PST) Received: from s4de8dsaamv.krf.telekom.de (HELO S4DE8DSAAMV.west.t-com.de) ([10.134.164.131]) by tcmail81.telekom.de with ESMTP; 23 Nov 2009 09:11:44 +0100 Received: from s4de8dsaanq.west.t-com.de ([10.134.164.176]) by S4DE8DSAAMV.west.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:11:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Nov 2009 09:11:32 +0100 Message-ID: In-Reply-To: <4B0537BC.7050807@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document Thread-Index: AcppEpZLYt7CfUiyQfa7WxqVShhcQQDAcVrg References: <4B0537BC.7050807@pi.nu> From: To: X-OriginalArrivalTime: 23 Nov 2009 08:11:35.0036 (UTC) FILETIME=[92BB13C0:01CA6C14] Subject: Re: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:11:56 -0000 Support JK=20 -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von = Loa Andersson Gesendet: Donnerstag, 19. November 2009 13:19 An: mpls@ietf.org; George Swallow; Adrian Farrel; Martin Vigoureux Betreff: [mpls] poll on making draft-wijnands-mpls-in-band-signaling-02 = an mpls wg document All, this is to start a two week poll in making draft-wijnands-mpls-in-band-signaling-02 an MPLS working group document. Send a mail to the working group (mpls@ietf.org) mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Dec 6, 2009. /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Mon Nov 23 01:49:43 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224B13A63C9 for ; Mon, 23 Nov 2009 01:49:43 -0800 (PST) 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 wlW4eJs2WUny for ; Mon, 23 Nov 2009 01:49:42 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 438563A657C for ; Mon, 23 Nov 2009 01:49:42 -0800 (PST) Received: from [192.36.158.49] (corky-wl.verkstad.net [192.36.158.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B6376D404B; Mon, 23 Nov 2009 10:49:34 +0100 (CET) Message-ID: <4B0A5AAF.9060508@pi.nu> Date: Mon, 23 Nov 2009 10:49:35 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org, George Swallow , Adrian Farrel , Martin Vigoureux References: <4B0537BC.7050807@pi.nu> In-Reply-To: <4B0537BC.7050807@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] CORRECTION: poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:49:43 -0000 All, I made a mistake when I started this poll, the draft I'm asking about is: http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-signaling-02 It is odd that we made the same mistake both on the agenda in and in the tentative minutes from Hiroshima. But as far as I understand the comments we've had are on the correct draft. I will extend the poll to Sun Dec 14 to compensate for my mistake. /Loa Loa Andersson wrote: > All, > > this is to start a two week poll in making > > draft-wijnands-mpls-in-band-signaling-02 > > an MPLS working group document. > > Send a mail to the working group (mpls@ietf.org) mailing list, > indicating "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Dec 6, 2009. > > /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From ice@cisco.com Mon Nov 23 02:23:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D139A3A68B5 for ; Mon, 23 Nov 2009 02:23:33 -0800 (PST) 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 2eKuALvOiKN1 for ; Mon, 23 Nov 2009 02:23:33 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id C56173A6851 for ; Mon, 23 Nov 2009 02:23:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nANAFtex004368; Mon, 23 Nov 2009 11:15:56 +0100 (CET) Received: from ams-iwijnand-8714.cisco.com (ams-iwijnand-8714.cisco.com [10.55.191.149]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nANAFpB6005577; Mon, 23 Nov 2009 11:15:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: IJsbrand Wijnands In-Reply-To: <4B0A5AAF.9060508@pi.nu> Date: Mon, 23 Nov 2009 11:15:51 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4B0537BC.7050807@pi.nu> <4B0A5AAF.9060508@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1075.2) Cc: mpls@ietf.org Subject: Re: [mpls] CORRECTION: poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 10:23:33 -0000 Loa, > I made a mistake when I started this poll, the draft I'm asking > about is: > > http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-signaling-02 > > It is odd that we made the same mistake both on the agenda in and in > the tentative minutes from Hiroshima. But as far as I understand the > comments we've had are on the correct draft. This is probably due to a mistake I made. Sorry about that, Thx, Ice. > > I will extend the poll to Sun Dec 14 to compensate for my mistake. > > /Loa > > Loa Andersson wrote: >> All, >> this is to start a two week poll in making >> draft-wijnands-mpls-in-band-signaling-02 >> an MPLS working group document. >> Send a mail to the working group (mpls@ietf.org) mailing list, >> indicating "yes/support" or "no/do not support". >> Comments on the content of the draft should be sent to the same >> mailing list with a different subject line. >> The poll ends Sun Dec 6, 2009. >> /Loa > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From venkatflex@gmail.com Mon Nov 23 12:13:28 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5483A69E9; Mon, 23 Nov 2009 12:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.346, 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 3gQDk36jPjNl; Mon, 23 Nov 2009 12:13:27 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 8D0253A6921; Mon, 23 Nov 2009 12:13:27 -0800 (PST) Received: by pwi6 with SMTP id 6so3934536pwi.29 for ; Mon, 23 Nov 2009 12:13:21 -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:content-type; bh=Hc+KvzeOjrAl9Wnl7Q7+HbUfL+O+G/EEgA5NGEhalgA=; b=QYnAHKGEdMKu5ZmxQ1OFW5eqsofWaB+7HlCBW+TAhpKR3SR9NqOq0VGDgsK8oP1jO1 AdHPg3nBHMGjqJQ5AsydYl+ZegZhyC8uBK7uMYX36QTcguDsMMvfBxuZuMWRKSG7fX6a Nva0enN6eZLTI1kimtp7mv7rB0QL7/jfhjo6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ORnR7UzXs2dWU9CENQyeFHL1RKzkLbupqBLHHViVNSrzMUmC0DqnXIRdLLEsD9s16b BuU4GLkt/+Ex3fEn0mXYHDILe69ZD61lkkkie/MbJchazSpzyHR99kzgVOdJAgouVOAn dQ/fCBYu5/ZsLGtdfA1epwRrXmsp8BMb837zI= MIME-Version: 1.0 Received: by 10.142.6.27 with SMTP id 27mr575411wff.319.1259007201280; Mon, 23 Nov 2009 12:13:21 -0800 (PST) Date: Tue, 24 Nov 2009 01:43:21 +0530 Message-ID: <715756490911231213i1f15af00md66b0e7f39e0e827@mail.gmail.com> From: venkatesan mahalingam To: mpls-tp@ietf.org, mpls Content-Type: multipart/alternative; boundary=00504502b09400854f04790f7554 Subject: [mpls] MPLS-TP tunnel X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:13:28 -0000 --00504502b09400854f04790f7554 Content-Type: text/plain; charset=ISO-8859-1 Dear MPLS-TP members, Please reply to my below query, I'm still not clear about the MPLS-TP tunnel. How do we maintain the MPLS-TP tunnel informations in the existing MPLS framework? mplsTunnelTable -> currently used for static, RSVP and CR-LDP. Can this TE tunnel table be used for enhancing this MPLS-TP tunnel or new table will be defined to generically handle MPLS TE and NON-TE tunnels together for transport networks? We assume this mplsTunnelTable's Tunnel instances can be used for TE working LSP and protection LSP. But we are not sure of the NON-TE MPLS-TP tunnel handling. Please provide some inputs. Is this MPLS-TP tunnel TE or NON-TE or both LSP? Thanks in advance, BR Venkat. --00504502b09400854f04790f7554 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear MPLS-TP members,
Please reply to my below query,

I'm sti= ll not clear about the MPLS-TP tunnel.

How do we maintain the MPLS-T= P tunnel informations in the existing MPLS framework?

mplsTunnelTabl= e -> currently used for static, RSVP and CR-LDP.

Can this TE tunnel table be used for enhancing this MPLS-TP tunnel or n= ew table will be defined to generically handle MPLS TE and NON-TE tunnels t= ogether for transport networks?

We assume this mplsTunnelTable's= Tunnel instances can be used for TE working LSP and protection LSP. But we= are not sure of the NON-TE MPLS-TP tunnel handling. Please provide some in= puts.

Is this MPLS-TP tunnel TE or NON-TE or both LSP?

Thanks in advan= ce,

BR
Venkat.

--00504502b09400854f04790f7554-- From eric.gray@ericsson.com Mon Nov 23 13:07:29 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FD73A6A1A for ; Mon, 23 Nov 2009 13:07:29 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP6qC1sCSMzC for ; Mon, 23 Nov 2009 13:07:28 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 8BE783A6A7B for ; Mon, 23 Nov 2009 13:07:28 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nANL7LqM029417; Mon, 23 Nov 2009 15:07:21 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 23 Nov 2009 16:07:21 -0500 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" , George Swallow , Adrian Farrel , Martin Vigoureux Date: Mon, 23 Nov 2009 16:07:20 -0500 Thread-Topic: [mpls] CORRECTION: poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document Thread-Index: AcpsIlsXB83H+W2OQQmPPJxFpx41kQAXd5lw Message-ID: References: <4B0537BC.7050807@pi.nu> <4B0A5AAF.9060508@pi.nu> In-Reply-To: <4B0A5AAF.9060508@pi.nu> 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 Subject: Re: [mpls] CORRECTION: poll on making draft-wijnands-mpls-in-band-signaling-02 an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:07:29 -0000 I support this draft's becoming a WG draft. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, November 23, 2009 4:50 AM To: mpls@ietf.org; George Swallow; Adrian Farrel; Martin Vigoureux Subject: [mpls] CORRECTION: poll on making draft-wijnands-mpls-in-band-sign= aling-02 an mpls wg document All, I made a mistake when I started this poll, the draft I'm asking about is: http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-signaling-02 It is odd that we made the same mistake both on the agenda in and in the tentative minutes from Hiroshima. But as far as I understand the comments we've had are on the correct draft. I will extend the poll to Sun Dec 14 to compensate for my mistake. /Loa Loa Andersson wrote: > All, >=20 > this is to start a two week poll in making >=20 > draft-wijnands-mpls-in-band-signaling-02 >=20 > an MPLS working group document. >=20 > Send a mail to the working group (mpls@ietf.org) mailing list, > indicating "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. >=20 > The poll ends Sun Dec 6, 2009. >=20 > /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yakov@juniper.net Mon Nov 23 13:26:42 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCD728C1B0 for ; Mon, 23 Nov 2009 13:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 qKQP7URtCmbZ for ; Mon, 23 Nov 2009 13:26:41 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 32D853A692B for ; Mon, 23 Nov 2009 13:26:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSwr+DDtRQmrgcd67mmaNI5wnUQj3Jm3M@postini.com; Mon, 23 Nov 2009 13:26:37 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 23 Nov 2009 13:21:51 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:21:51 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:21:51 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:21:51 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nANLLoj23490; Mon, 23 Nov 2009 13:21:50 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200911232121.nANLLoj23490@magenta.juniper.net> To: erosen@cisco.com In-Reply-To: <20764.1258556070@erosen-linux> References: <20764.1258556070@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Wed, 18 Nov 2009 09:54:30 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41390.1259011310.1@juniper.net> Date: Mon, 23 Nov 2009 13:21:50 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 23 Nov 2009 21:21:51.0105 (UTC) FILETIME=[F8E90710:01CA6C82] Cc: mpls@ietf.org, ice@cisco.com Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:26:42 -0000 Eric, > John> contrast to the existing CsC solutions if possible > > That's a fair request. > > The solution described in sections 15, 11.1.2 and 11.3.2 of > draft-ietf-l3vpn-2547bis-mcast-bgp presupposes the use of mLDP on the > interface between the "outer carrier" and the "inner carrier". It uses BGP > C-multicast routing to convey the outer carrier's mLDP signaling > information, and uses BGP S-PMSI A-D routes to assign the outer carrier's > mLDP-based P2MP LSPs to P-tunnels of the inner carrier. If a particular > deployment supports upstream-assigned MPLS labels, this can be used to allow > aggregation of multiple P2MP LSPs from the outer carrier into a single > P-tunnel of the inner carrier. > > Now consider a deployment scenario with the following properties: > > - - The inner carrier has not deployed and/or does not want to deploy BGP > C-multicast routing. > > - - The inner carrier and the outer carrier both use mLDP for their P-tunnels. This is supported by the solution specified in draft-ietf-l3vpn-2547bis-mcast-bgp. > - - The inner carrier is not concerned about aggregation (either because > upstream-assigned labels are not available, or because it doesn't want the > sub-optimal routing that comes with aggregation). The inner carrier doesn't have to use aggregation with the solution specified in draft-ietf-l3vpn-2547bis-mcast-bgp > In this scenario, the simple "in-band" signaling of draft-wijnands-mpls- > mldp-csc provides a much simpler solution. We think this will be a quite > common deployment scenario. > > Of course, if a carrier's carrier does want to do aggregation and does want > to deploy BGP C-multicast routing, those options are certainly available in > the overall solution set. The MVPN solution that L3VPN WG has to produce is based on the requirements developed in L3VPN WG, as specified in rfc4834, and *not* on what you think "will be a quite common deployment scenario". With this in mind, supporting carrier that "does not want to deploy BGP C-multicast routing", which you use as a justification for the approach specified in draft-wijnands-mpls-mldp-csc, is *not* one of the requirements listed in that rfc. On the other hand, as John pointed out in his e-mail, the approach specified in draft-wijnands-mpls-mldp-csc does *not* meet two of the "SHOULD" requirements specified in rfc4834. Yakov. From root@core3.amsl.com Tue Nov 24 09:15:02 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0C05D3A68DA; Tue, 24 Nov 2009 09:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091124171502.0C05D3A68DA@core3.amsl.com> Date: Tue, 24 Nov 2009 09:15:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-tp-process-04.txt Pages : 23 Date : 2009-11-24 The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) in cooperation between the IETF and the ITU-T is document in RFC 5317 as the decision of the Joint Working Team on MPLS-TP. This document provides additional detail of the processes for the development of IETF RFCs on MPLS-TP. It provides an adaptation of the IETF working group process; identifies the expected participation in the process by the ITU-T; and clarifies the rules and conventions regarding MPLS-TP documents. This document does not specify any ITU-T process; ITU-T activities will be done according to ITU-T process/rules. This document does not specify or modify the normal IETF working group process. It is limited to the specific adaptations of that process to facilitate the cooperation agreement between the IETF and the ITU-T on MPLS-TP, and to ensure a good and consistent document review across the two organizations. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-process-04.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-mpls-tp-process-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-24090905.I-D@ietf.org> --NextPart--