From mpls-bounces@lists.ietf.org Tue Nov 01 08:47:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwUL-0005mT-OW; Tue, 01 Nov 2005 08:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwUJ-0005iq-Ii for mpls@megatron.ietf.org; Tue, 01 Nov 2005 08:47:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21357 for ; Tue, 1 Nov 2005 08:47:23 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWwii-0005RJ-80 for mpls@ietf.org; Tue, 01 Nov 2005 09:02:36 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 3A751E0000DA; Tue, 1 Nov 2005 13:47:32 +0000 (GMT) Received: from Puppy ([217.158.132.194] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 13:39:17 +0000 Message-ID: <011001c5deea$12af0260$4e919ed9@Puppy> From: "Adrian Farrel" To: "Loa Andersson" , References: <436624FC.2000805@pi.se> Subject: Re: [mpls] wg agenda for the Vancouver meeting Date: Tue, 1 Nov 2005 13:41:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 01 Nov 2005 13:39:18.0123 (UTC) FILETIME=[A83CCBB0:01C5DEE9] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Loa, You might consider placing 7 before 5. If we allow Jean Louis to describe the requirements we may have a better grasp of the solution discussion. Cheers, Adrian ----- Original Message ----- From: "Loa Andersson" To: Sent: Monday, October 31, 2005 2:06 PM Subject: [mpls] wg agenda for the Vancouver meeting > All, > > I've uploaded an agenda (for some value of agenda), to > > http://www3.ietf.org/proceedings/05nov/agenda/mpls.txt > > it is still extremely preliminary, and will be updated > shortly. > > Please, if you requested a agenda slot, check that your > request has been addressed. > > /Loa > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Nov 01 08:54:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwbE-0000BA-0e; Tue, 01 Nov 2005 08:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwbA-00009K-OY for mpls@megatron.ietf.org; Tue, 01 Nov 2005 08:54:48 -0500 Received: from pfwhqs101.ncr.disa.mil (pfwhqs1.ncr.disa.mil [209.22.99.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21969 for ; Tue, 1 Nov 2005 08:54:28 -0500 (EST) Message-ID: From: "Nguyen, Thomas" To: "'mpls@lists.ietf.org'" Date: Tue, 1 Nov 2005 08:54:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: Subject: [mpls] RE: mpls Digest, IETF 64th Agenda X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org -----Original Message----- From: mpls-request@lists.ietf.org [mailto:mpls-request@lists.ietf.org] Sent: None To: mpls@lists.ietf.org Subject: mpls Digest, Vol 18, Issue 21 Send mpls mailing list submissions to mpls@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/mpls or, via email, send a message with subject or body 'help' to mpls-request@lists.ietf.org You can reach the person managing the list at mpls-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mpls digest..." Today's Topics: 1. wg agenda for the Vancouver meeting (Loa Andersson) ---------------------------------------------------------------------- Message: 1 Date: Mon, 31 Oct 2005 15:06:52 +0100 From: Loa Andersson Subject: [mpls] wg agenda for the Vancouver meeting To: mpls@ietf.org Message-ID: <436624FC.2000805@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed All, I've uploaded an agenda (for some value of agenda), to http://www3.ietf.org/proceedings/05nov/agenda/mpls.txt it is still extremely preliminary, and will be updated shortly. Please, if you requested a agenda slot, check that your request has been addressed. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se ------------------------------ _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 18, Issue 21 ************************************ _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Nov 02 06:55:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXHCn-0006ON-2y; Wed, 02 Nov 2005 06:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXHCi-0006Ma-Tp for mpls@megatron.ietf.org; Wed, 02 Nov 2005 06:54:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29674 for ; Wed, 2 Nov 2005 06:54:35 -0500 (EST) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXHRH-0005q7-T1 for mpls@ietf.org; Wed, 02 Nov 2005 07:10:01 -0500 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id jA2BqOP9028235 for ; Wed, 2 Nov 2005 12:52:24 +0100 Received: from [127.0.0.1] ([172.16.2.217]) by mail1.imc.kth.se; Wed, 02 Nov 2005 12:51:58 +0100 Message-ID: <4368A85D.4080704@pi.se> Date: Wed, 02 Nov 2005 12:51:57 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Note on upstream label allocation X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, the question asked to this mailing list on drafts draft-raggarwa-mpls-ldp-upstream-01.txt draft-raggarwa-mpls-rsvp-upstream-01.txt First revealed a (not very strong) support for making these documents working group documents. There were almost no expressed opposition. From this point of view there is no problem making the documents working group documents. However, an IPR search has revealed existing patents on upstream label allocation. The decision has therefore been deferred until after the discussion at the working group meeting in Vancouver. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Nov 02 08:07:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIKq-0005xq-Ht; Wed, 02 Nov 2005 08:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIKn-0005wA-H8 for mpls@megatron.ietf.org; Wed, 02 Nov 2005 08:07:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04627 for ; Wed, 2 Nov 2005 08:06:59 -0500 (EST) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXIZN-0000N9-5y for mpls@ietf.org; Wed, 02 Nov 2005 08:22:26 -0500 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id jA2D51Y3029567 for ; Wed, 2 Nov 2005 14:05:01 +0100 Received: from [127.0.0.1] ([172.16.2.217]) by mail1.imc.kth.se; Wed, 02 Nov 2005 14:04:30 +0100 Message-ID: <4368B95C.9000809@pi.se> Date: Wed, 02 Nov 2005 14:04:28 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: [Fwd: RE: [mpls] Note on upstream label allocation] Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oberon.imc.kth.se id jA2D51Y3029567 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, jean-Louis, pointed out that the question that related to upstream label allocation was on raft-rosen-mpls-multicast-encaps draft-raggarwa-mpls-upstream-label and not the signaling drafts, this is true and the mistake a result of me trying to get too much done before I head out for the IETF meeting. However, the same logic applies. /Loa -------- Original Message -------- Subject: RE: [mpls] Note on upstream label allocation Date: Wed, 2 Nov 2005 13:35:42 +0100 From: LE ROUX Jean-Louis RD-CORE-LAN To: Loa Andersson Hi Loa Actually you polled the WG on draft-rosen-mpls-multicast-encaps and draft-raggarwa-mpls-upstream-label, but not on the two signaling drafts. JL > -----Message d'origine----- > De : mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] De la part de Loa Andersson > Envoy=E9 : mercredi 2 novembre 2005 12:52 > =C0 : mpls@ietf.org > Objet : [mpls] Note on upstream label allocation >=20 > All, >=20 > the question asked to this mailing list on drafts >=20 > draft-raggarwa-mpls-ldp-upstream-01.txt > draft-raggarwa-mpls-rsvp-upstream-01.txt >=20 > First revealed a (not very strong) support for making these=20 > documents working group documents. There were almost no=20 > expressed opposition. >=20 > From this point of view there is no problem making the=20 > documents working group documents. >=20 > However, an IPR search has revealed existing patents on=20 > upstream label allocation. The decision has therefore been=20 > deferred until after the discussion at the working group=20 > meeting in Vancouver. >=20 > Loa and George >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Nov 03 00:03:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXXFe-0002YS-Ul; Thu, 03 Nov 2005 00:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXXFb-0002Xf-St for mpls@megatron.ietf.org; Thu, 03 Nov 2005 00:02:59 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02072 for ; Thu, 3 Nov 2005 00:02:38 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EXXFa-00059Y-UO; Thu, 03 Nov 2005 00:02:58 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 03 Nov 2005 00:02:58 -0500 Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org The IESG has approved the following document: - 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-05.txt Technical Summary This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. Working Group Summary The WG had a consensus on advancing thid document. Protocol Quality The document has been reviewed by Mike Shand and Ross Callon for the RTG directorate. The document has been reviewed by Alex Zinin for the IESG. RFC Editor Note Remove section 11.4 "SESSION_ATTRIBUTE Flags Field" _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Nov 03 22:52:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsdN-0007cv-P3; Thu, 03 Nov 2005 22:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsdL-0007Yi-MG for mpls@megatron.ietf.org; Thu, 03 Nov 2005 22:52:55 -0500 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18327 for ; Thu, 3 Nov 2005 22:52:31 -0500 (EST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2005 19:52:25 -0800 X-IronPort-AV: i="3.97,289,1125903600"; d="scan'208"; a="671794785:sNHT24756208" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA43qLNl006461; Thu, 3 Nov 2005 19:52:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 19:52:21 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 19:52:20 -0800 Message-Id: <4.3.2.7.2.20051103214946.02b74ef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Nov 2005 21:52:19 -0500 To: mpls@ietf.org, George Swallow , Loa Andersson From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Nov 2005 03:52:21.0181 (UTC) FILETIME=[288B26D0:01C5E0F3] Cc: jmpolk@cisco.com, "Peterson, Jon" , khchan@nortel.com Subject: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org MPLS WG The chairs of TSVWG have started a WGLC on the following ID: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-classes-01.txt This document is being put forth as an Informational document. Because of the nature of this document, it has the potential to affect other efforts outside of TSVWG's influence and/or review, therefore comments are being solicited from other WGs on this document. Comments regarding this document either belong on the TSVWG list, or at the very least, please include all the addresses in the From and CC headers of this message so we authors and chairs can track such comments. Thank you! This WGLC will end on November 18th. Allison Jon James IETF TSVWG co-chairs _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat Nov 05 17:03:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYW8H-0002wQ-5p; Sat, 05 Nov 2005 17:03:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYW8C-0002vh-A6; Sat, 05 Nov 2005 17:03:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22705; Sat, 5 Nov 2005 17:02:59 -0500 (EST) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYWNS-0004w3-ME; Sat, 05 Nov 2005 17:19:11 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-131.messagelabs.com!1131228140!647630!5 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 4330 invoked from network); 5 Nov 2005 22:03:13 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-131.messagelabs.com with SMTP; 5 Nov 2005 22:03:13 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA001E7F94; Sat, 5 Nov 2005 17:03:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC Date: Sat, 5 Nov 2005 16:03:11 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9624@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC Thread-Index: AcXg84w4o1nKZVMARuOSFcGrBfivqwBX6Iiw From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: "Peterson, Jon" , mpls@ietf.org, "James M. Polk" , khchan@nortel.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, FYI. This I-D http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-cl asses-01.txt is under cross-area review and of possible interest to NSIS. Also may be relevant to QSPEC, Y.1541-QOSM, 3GPP-QOSM RE mappings of service classes. Y.1541 is mentioned only once (Section 2.3), and probably should be referenced. Thanks, Jerry -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of James M. Polk Sent: Thursday, November 03, 2005 9:52 PM To: mpls@ietf.org; George Swallow; Loa Andersson Cc: jmpolk@cisco.com; Peterson, Jon; khchan@nortel.com Subject: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC MPLS WG The chairs of TSVWG have started a WGLC on the following ID: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-cl asses-01.txt=20 This document is being put forth as an Informational document. Because of the nature of this document, it has the potential to affect=20 other efforts outside of TSVWG's influence and/or review, therefore=20 comments are being solicited from other WGs on this document. Comments=20 regarding this document either belong on the TSVWG list, or at the very=20 least, please include all the addresses in the From and CC headers of this=20 message so we authors and chairs can track such comments. Thank you! This WGLC will end on November 18th. Allison Jon James IETF TSVWG co-chairs _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Nov 07 21:10:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIwm-0007pj-NG; Mon, 07 Nov 2005 21:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIwk-0007pK-R5 for mpls@megatron.ietf.org; Mon, 07 Nov 2005 21:10:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01288 for ; Mon, 7 Nov 2005 21:10:24 -0500 (EST) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJCT-0002KJ-Fo for mpls@ietf.org; Mon, 07 Nov 2005 21:27:05 -0500 Received: from pp110-230.bctel.ca ([209.52.110.230]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EZIwZ-0001xs-6w; Tue, 08 Nov 2005 03:10:41 +0100 Message-ID: <43700887.4000308@pi.se> Date: Tue, 08 Nov 2005 03:08:07 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] IPRs on Upstream Label Allocation X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working Group, we have received a couple of Internet Drafts suggesting that we should specify the use of Upstream Label Allocation for MPLS Multicast. However, a not very scientific patent search generates the following list of patents that could be within the area of standardization: PAT. NO. Title 1 6,888,846 Full-Text Data transfer in an optical network communication system 2 6,512,744 Full-Text Virtual-channel merging 3 6,501,754 Full-Text Scheme for label switched path loop detection at node device 4 6,483,833 Full-Text Method for transmitting label switching control information using the open shortest path first opaque link state advertisement option protocol 5 6,466,985 Full-Text Method and apparatus for providing quality of service using the internet protocol 6 6,374,303 Full-Text Explicit route and multicast tree setup using label distribution 7 6,336,129 Full-Text Packet transfer method and node device using resourcereservation or priority transfer control without requiring virtual connection merging 8 6,879,594 Full-Text System and method for loop avoidance in multi-protocol label switching 9 6,735,190 Full-Text Packet transport method device utilizing header removal fields internet protocol 10 6,408,001 Full-Text Method for determining label assignments for a router I've not checked the relevance of all cases or if the the ones that actually are in the area is disclosed. Varying the search slightly reveals more potential candidates. I've notified the IETF secretariat of these patents, and trust that they will do whatever they need to. /Loa PS. The above represents the necessary procedure, but I will send another mail trying to clarify my own position. Alex has also promissed to talk to this a bit tomorrow. -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Nov 07 21:16:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ2G-0000KE-V6; Mon, 07 Nov 2005 21:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ2F-0000K9-MY for mpls@megatron.ietf.org; Mon, 07 Nov 2005 21:16:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01705 for ; Mon, 7 Nov 2005 21:16:01 -0500 (EST) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJHu-0002TH-HD for mpls@ietf.org; Mon, 07 Nov 2005 21:32:43 -0500 Received: from pp110-230.bctel.ca ([209.52.110.230]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EZJ20-0001z6-3H for mpls@ietf.org; Tue, 08 Nov 2005 03:16:18 +0100 Message-ID: <437009D8.9050403@pi.se> Date: Tue, 08 Nov 2005 03:13:44 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 TW_TD BODY: Odd Letter Triples with TD X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] upstream label allocation IPRs X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Chair hat off! I would surprise me quite a bit if there is a show stopper for Upstream Label allocation because of these patents. After all there is prior art to any of these patents e.g. http://www.watersprings.org/pub/id/draft-doolan-tdp-spec-00.txt However, once IPRs are brought to our attention we need to follow process. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Nov 08 20:39:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZew1-0004OK-FH; Tue, 08 Nov 2005 20:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZevz-0004MW-EK for mpls@megatron.ietf.org; Tue, 08 Nov 2005 20:39:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01959 for ; Tue, 8 Nov 2005 20:39:04 -0500 (EST) Received: from ns.ft.solteria.net ([210.142.173.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfBt-0003Kt-Gy for mpls@ietf.org; Tue, 08 Nov 2005 20:55:58 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id C702E38712; Wed, 9 Nov 2005 10:39:06 +0900 (JST) Message-ID: <43715337.1080703@ft.solteria.net> Date: Wed, 09 Nov 2005 10:39:03 +0900 From: "S.Matsushima" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] BGP P2MP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi all, Today I have a presentation of BGP for P2MP-LSP. It was a first opportunity for p2mp-lsp using BGP, which never be discussed before in mpls-wg. The document is available at following url: http://www.ietf.org/internet-drafts/draft-satoru-mpls-bgp-multipoint-02.txt There are several points of this proposal: - Discover/Notify P2MP capable branch and egress nodes - P2MP LSP can be used over P2P/MP2P LSP - Policy based P2MP tree decision and making in per LSP basis - Separate data-plane of P2MP entity as P2MP instance These are useful for interwork, migrate or co-existing with other p2mp-lsp solution to expand the coverage of p2mp capable network. that are good to start the BGP P2MP discussion, but document is not so mature. So I'd like to have wg review of this draft and discuss about it to make good solution. Any comments or questions are welcome. Thanks, -- Satoru Matsushima _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Nov 10 20:16:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNX8-0001cU-Jm; Thu, 10 Nov 2005 20:16:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNX6-0001cF-OE for mpls@megatron.ietf.org; Thu, 10 Nov 2005 20:16:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00038 for ; Thu, 10 Nov 2005 20:16:20 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaNnN-0002XX-Ux for mpls@ietf.org; Thu, 10 Nov 2005 20:33:40 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2005 17:16:14 -0800 X-IronPort-AV: i="3.99,115,1131350400"; d="scan'208"; a="363652517:sNHT1969129602" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAB1GCZC026835 for ; Thu, 10 Nov 2005 17:16:13 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 20:16:12 -0500 Received: from pp109-83.bctel.ca ([10.86.242.6]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 20:15:56 -0500 Received: from cisco.com (localhost [127.0.0.1]) by pp109-83.bctel.ca (Postfix) with ESMTP id 7CA7512B228 for ; Thu, 10 Nov 2005 20:15:53 -0500 (EST) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Thu, 10 Nov 2005 20:15:53 -0500 Message-Id: <20051111011553.7CA7512B228@pp109-83.bctel.ca> X-OriginalArrivalTime: 11 Nov 2005 01:16:09.0698 (UTC) FILETIME=[7F989420:01C5E65D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4297a3b9ddbbc388d94c1425bc2288b8 Cc: Subject: [mpls] Last-last call on LSR Self Test X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This begins a one week last call on LSR Self Test, draft-ietf-mpls-lsr-self-test-06.txt The last call ends 17 NOV 2005 24:00 UTC. The last call is limited to the changes made as a result of the previous last call. Attached are the diffs from version 05 to 06. ...George Section 1., para. 1: OLD: This document defines a means for a Label-Switching Router (LSR) to verify that its dataplane is functioning for certain key Multi-Proto- col Label Switching (MPLS) applications, including unicast forwarding based on LDP [LDP] and traffic engineering tunnels based on [RSVP- TE]. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] are extended to do the actual probing. The pings are sent to an upstream neighbor, looped back through the LSR under test and intercepted, by means of TTL expiration by a downstream neighbor. Extensions to LSP- Ping [LSP-Ping] are defined to allow the down stream neighbor to report the test results. NEW: This document defines a means for a Label-Switching Router (LSR) to verify that its data plane is functioning for certain key Multi-Pro- tocol Label Switching (MPLS) applications, including unicast forward- ing based on LDP [LDP] and traffic engineering tunnels based on [RSVP-TE]. MPLS Verification Request and MPLS Verification Reply messages are defined to do the actual probing. The pings are sent to an upstream neighbor, looped back through the LSR under test and intercepted, by means of TTL expiration by a downstream neighbor. Section 1., para. 2: OLD: In order to minimize the load on upstream LSRs a new loopback FEC is defined. Receipt of a packet labeled with a loopback label will cause the advertising LSR to pop the label off the label stack and send the packet out the advertised interface. NEW: In order to minimize the load on upstream LSRs a loopback FEC Type is defined. Labels advertised with this FEC Type are referred to as loopback labels. Receipt of a packet labeled with a loopback label will cause the advertising LSR to pop the label off the label stack and send the packet out the advertised interface. Section 1., para. 3: OLD: Note that use of a loopback allows an LSR to test label entries for which the LSR is not currently some neighbor's next hop. In this way label entries can be verified prior to the occurrence of a routing change. NEW: Use of a loopback mechnism allows an LSR to test label entries which are not currently in use. For example many LSRs advertise label map- pings for all IPv4 routes to all of their neighbors. For some por- tion of these their neighbor LSR is not currently upstream and the label entry is not used. But if the neighbors best path to a desti- nation changes, that route and the associated label entry will be used. An LSR can loop traffic through a "non-upstream" LSR because that LSR is acting only on the loopback label and not on the underly- ing label associated with the actual FEC being tested. In this way label entries can be verified prior to the occurrence of a routing change. Section 1., para. 4: OLD: Some routing protocls, most notably OSPF have no means of exchanging the "Link Local Identifiers" used to identify unnumbered links and components of bundled links. These test procedures can be used to associate the neighbor's interfaces with the probing LSRs interfaces. This is achieved by simply having the TTL of the MPLS Ping expire one hop sooner, i.e. at the testing LSR itself. NEW: Some routing protocols, most notably OSPF have no means of exchanging the "Link Local Identifiers" used to identify unnumbered links and components of bundled links. These test procedures can be used to associate the neighbor's interfaces with the probing LSRs interfaces. This is achieved by simply having the TTL of the MPLS Ping expire one hop sooner, i.e. at the testing LSR itself. Section 2., para. 1: OLD: The Loopback FEC type is defined to enable an upstream neighbor to assist in LSR self-testing at very low cost. This FEC causes the loopback to occur in the dataplane without control plane involvement beyond the initial LDP exchange and dataplane setup. The FEC also carries information to indicate the desired encapsulation should it be the only label in a received label stack. Values are defined for IPv4 and IPv6. NEW: The Loopback FEC type is defined to enable an upstream neighbor to assist in LSR self-testing at very low cost. This FEC causes the loopback to occur in the dataplane without control plane involvement beyond the initial LDP exchange and data-plane setup. The FEC also carries information to indicate the desired encapsulation should it be the only label in a received label stack. Values are defined for IPv4 and IPv6. Section 2.1., para. 3: OLD: Must be set to zero on transmission and ignored on receipt. NEW: MUST be set to zero on transmission and ignored on receipt. Section 2.1., para. 6: OLD: Note that this type also indicates the encapsulation type for payloads that have a label stack contain the one loopback label. NEW: Note that these type values also indicate the encapsulation (IPv4 or IPv6) for payloads that have a label stack containing only a loopback label. Section 2.2., para. 1: OLD: It is RECOMMENDED that loopback labels only be distributed in response to a Label Request message, irrespective of the label adver- tisement mode of the LDP session. However it is recognized that in certain cases such as OSPF with unnumbered links, the upstream LSR may not have sufficiently detailed information of the neighbor's link identifier to form the request. In these cases, the downstream LSR will need to be configured to make unsolicited advertisements. NEW: It is RECOMMENDED that loopback labels only be distributed in response to a Label Request message, irrespective of the label adver- tisement mode of the LDP session. However it is recognized that in certain cases such as OSPF with unnumbered links, the upstream LSR may not have sufficiently detailed information of the neighbor's link identifier to form the request. In these cases, the downstream LSR MAY be configured to make unsolicited advertisements. Section 3., para. 1: OLD: A self test operation involves three LSRs, the LSR doing the test, an upstream neighbor and a downstream neighbor. We refer to these as LSRs T, U, and D respectively. In order to minimize the processing load on LSR-D, two new LSP Ping messages are defined, called the MPLS Data Plane Verification Request and the MPLS Data Plane Verification Reply. These messages are used to allow LSR-T to obtain the label stack, address and interface information of LSR-D. If FEC verification is required, the MPLS Echo Request and Reply mes- sages are used. NEW: A self test operation involves three LSRs, the LSR doing the test, an upstream neighbor and a downstream LSR. Upstream here is with respect to the flow of the test (which in some cases could be differ- ent than the normal sense of upstream in IP routing). We refer to these as LSRs T, U, and D respectively. In order to minimize the processing load on LSR-D, two new LSP Ping messages are defined, called the MPLS Data Plane Verification Request and the MPLS Data Plane Verification Reply. These messages are used to allow LSR-T to obtain the label stack, address and interface information of LSR-D. Section 3.1., para. 6: OLD: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Reply mode | Return Code | Return Subcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MPLS Data Plane Verification Request message MAY contain the fol- lowing objects: NEW: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | MUST Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Reply mode | Return Code | Return Subcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MPLS Data Plane Verification Request message MAY contain the fol- lowing objects: Section 3.1., para. 7: OLD: Type # Object ------ ----------- 3 Pad 5 Vendor Enterprise Code 11 (provisional) IPv4 Reply-to Object 12 (provisional) IPv6 Reply-to Object NEW: Type # Object ------ ----------- 3 Pad 10 Reply TOS Byte 11 (provisional) IPv4 Reply-to Address 12 (provisional) IPv6 Reply-to Address 64512-65535 Vendor Private TLVs Section 3.1., para. 9: OLD: Type # Object ------ ----------- 3 Pad 4 Error Code 5 Vendor Enterprise Code 7 IPv4 Interface and Label Stack Object 8 IPv6 Interface and Label Stack Object NEW: Type # Object ------ ----------- 7 Interface and Label Stack 9 Errored TLVs 64512-65535 Vendor Private TLVs Section 3.2., para. 1: OLD: MPLS Data Plane Verification Request messages MAY be sent to port 3503 as is used for [LSP-PING]. However to aid implementations that wish to handle these messages at a lower level than MPLS Echo Request messages another UDP port, tbd, is provided. Port tbd SHOULD be used by default. The source UDP port, as in [LSP-PING] is chosen by the sender. NEW: MPLS Data Plane Verification Request messages MAY be sent to port 3503 as is used for [LSP-PING]. However to aid implementations that wish to handle these messages at a lower level than MPLS Echo Request messages another UDP port, , is provided. Port SHOULD be used by default. The source UDP port, as in [LSP-PING] is chosen by the sender. Section 3.2., para. 2: OLD: 3.3. Reply-To Object NEW: 3.3. Reply-To Address Object Section 3.2., para. 4: OLD: 3.3.1. IPv4 Reply-To Object NEW: 3.3.1. IPv4 Reply-To Address Object Section 3.2., para. 5: OLD: The length of an IPv4 Reply-To Object is 4 octets; the value field has the following format: NEW: The length of an IPv4 Reply-to Address object is 4 octets; the value field has the following format: Section 3.2., para. 9: OLD: 3.3.2. IPv6 Reply-To Object NEW: 3.3.2. IPv6 Reply-To Address Object Section 3.2., para. 10: OLD: The length of an IPv6 Reply-To Object is 16 octets; the value field has the following format: NEW: The length of an IPv6 Reply-to Address object is 16 octets; the value field has the following format: Section 3.4., para. 2: OLD: The LSR creates an MPLS Data Plane Verification Request message and includes a Data Plane Verification Object. Optionally a FEC Stack TLV may be included. In this case an MPLS Echo Request Message MUST be used. NEW: The LSR creates an MPLS Data Plane Verification Request message. Section 3.4., para. 3: OLD: In normal use, the source address is set to an address belonging to the LSR and the destination set to an address in the range of 127/8. The incoming label stack (if any) is prepended to the packet. The TTL of these labels and the packet header SHOULD be set to appropri- ate values - 2 for those labels and/or header which will be processed by this node when the packet is looped back; 1 for those labels and/or header which will be carried through. Finally the loopback label bound to the incoming interface is prepended to the packet. In the case of an otherwise unlabeled packet the label's FEC MUST indi- cate the appropriate IP version. The TTL is set such that it will have the value of 3 on the wire. NEW: In normal use, the source address is set to an address belonging to the LSR and the destination set to an address in the range of 127/8. The incoming label stack (if any) is prepended to the packet. The TTL of these labels and the packet header SHOULD be set to appropri- ate values - 2 for those labels and/or header which will be processed by this node when the packet is looped back; 1 for those labels and/or header which will be carried through. Finally the loopback label bound to the incoming interface is prepended to the packet. In the case of an otherwise unlabeled packet the label's FEC MUST indi- cate the appropriate IP version. The TTL is set such that it will have the value of 3 on the wire. Section 3.4., para. 5: OLD: In diagnostic situations, the source and destination addresses MAY be set to any value. In this case, a Reply-to IPv4 or IPv6 Object MUST be included. The IP TTL MUST be set to 1. The TTL of labels other than the loopback label MUST be set to appropriate values - 2 for those labels which will be process by this LSR when the packet is looped back; 1 for those labels which will be carried through. NEW: In diagnostic situations, the source and destination addresses MAY be set to any value. In this case, a Reply-to IPv4 or IPv6 Address object MUST be included. The IP TTL MUST be set to 1. The TTL of labels other than the loopback label MUST be set to appropriate val- ues - 2 for those labels which will be process by this LSR when the packet is looped back; 1 for those labels which will be carried through. Section 3.4., para. 6: OLD: In some MPLS deployments TTL hiding is used to make a providers net- work appear as a single hop. That is the TTL in the imposed label does not refect the TTL of the received packet. It is RECOMMENDED that testing of label imposition SHOULD NOT be performed in such cir- cumstances as the Echo Request will in most case travel multiple hops. NEW: In some MPLS deployments TTL hiding is used to make a providers net- work appear as a single hop. That is the TTL in the imposed label does not reflect the TTL of the received packet. It is RECOMMENDED that testing of label imposition SHOULD NOT be performed in such cir- cumstances as the Verification Request will in most case travel mul- tiple hops. Section 3.5., para. 2: OLD: X then parses the packet to ensure that it is a well-formed packet, and that the TLVs that are not marked "Ignore" are understood. If not, X SHOULD send an MPLS echo reply with the Return Code set to "Malformed echo request received" or "TLV not understood" (as appro- priate), and the Subcode set to zero. In the latter case, the misun- derstood TLVs (only) are included in the reply. NEW: X then parses the packet to ensure that it is a well-formed packet, and that the TLVs that are not marked "Ignore" are understood. If not, X SHOULD set the Return Code set to "Malformed echo request received" or "TLV not understood" (as appropriate), and the Subcode set to zero. In the latter case, the misunderstood TLVs (only) are included in the reply. Section 3.5., para. 3: OLD: If the echo request is good, X notes the interface I over which the echo was received, and the label stack with which it came. If the MPLS echo request contained a Downstream Verification object, then X must format this information as a Downstream Verification object and include it in its MPLS echo reply message. NEW: If the Verification Request is good, X MUST note the interface and label stack of the received Verification Request and format this information as a Downstream Verification object. This object is included in the MPLS Verification Reply message. The Return Code and Subcode MUST be set to zero, indicating "No return code". Section 3.5., para. 4: OLD: The source address of the Reply message MUST be an address of the replying LSR. If the request included a Reply-to IPv4 or IPv6 Object, the MPLS Data Plane Verification Reply message MUST be sent to that address. Otherwise the Reply message is sent to the source address of the Verification Request message. NEW: The source address of the Reply message MUST be an address of the replying LSR. If the request included a Reply-to IPv4 or IPv6 Address object, the MPLS Data Plane Verification Reply message MUST be sent to that address. Otherwise the Reply message is sent to the source address of the Verification Request message. Section 5., para. 4: OLD: LSP Ping Object Type 11 IPv4 Reply-to Object LSP Ping Object Type 12 IPv6 Reply-to Object NEW: LSP Ping Object Type 11 IPv4 Reply-to Address LSP Ping Object Type 12 IPv6 Reply-to Address Section 7.2., para. 2: OLD: Authors' Addresses NEW: 8. Authors' Addresses Section 7.2., para. 11: OLD: January 2006 NEW: April 2006 ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Nov 11 15:26:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EafTI-0006Pe-97; Fri, 11 Nov 2005 15:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EafTG-0006PO-8t for mpls@megatron.ietf.org; Fri, 11 Nov 2005 15:26:02 -0500 Received: from rediffmail.com (webmail29.rediffmail.com [203.199.83.39] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03087 for ; Fri, 11 Nov 2005 15:25:32 -0500 (EST) Received: (qmail 29106 invoked by uid 510); 11 Nov 2005 20:25:53 -0000 Date: 11 Nov 2005 20:25:53 -0000 Message-ID: <20051111202553.29105.qmail@webmail29.rediffmail.com> Received: from unknown (208.246.215.5) by rediffmail.com via HTTP; 11 nov 2005 20:25:53 -0000 MIME-Version: 1.0 From: "S S" To: mpls@ietf.org Cc: Subject: [mpls] soft-preemption in cisco routers X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: S S List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0449251265==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multipart mime message --===============0449251265== Content-type: multipart/alternative; boundary="Next_1131740753---0-203.199.83.39-29100" This is a multipart mime message --Next_1131740753---0-203.199.83.39-29100 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0ADo cisco routers support soft-preemption (draft-ietf-mpls-soft-pre= emption-06.txt ). There is some documentation available in old IOS releases= which talk about support for soft preemption(draft-ietf-mpls-soft-preempti= on-00.txt to be exact). Checked out their feature navigator - no luck. I do= know that juniper supports full fledged soft-preemption. Could anyone dire= ct me to some cisco documentation which talks about soft preemption support= /configuration etc.=0A=0ARegards,=0AShiv=0A --Next_1131740753---0-203.199.83.39-29100 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0ADo cisco routers support soft-preemption (draft-ietf= -mpls-soft-preemption-06.txt ). There is some documentation available in ol= d IOS releases which talk about support for soft preemption(draft-ietf-mpls= -soft-preemption-00.txt to be exact). Checked out their feature navigator -= no luck. I do know that juniper supports full fledged soft-preemption. Cou= ld anyone direct me to some cisco documentation which talks about soft pree= mption support/configuration etc.
=0A
=0ARegards,
=0AShiv
=0A= =0A

=0A

=0A=0A --Next_1131740753---0-203.199.83.39-29100-- --===============0449251265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0449251265==-- From mpls-bounces@lists.ietf.org Sun Nov 13 12:19:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbLVc-0004xj-1J; Sun, 13 Nov 2005 12:19:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbLVa-0004xe-Bg for mpls@megatron.ietf.org; Sun, 13 Nov 2005 12:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20058 for ; Sun, 13 Nov 2005 12:18:44 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbLmQ-0002Ip-Cj for mpls@ietf.org; Sun, 13 Nov 2005 12:36:40 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2005 18:19:01 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jADHIw5x017653 for ; Sun, 13 Nov 2005 18:18:59 +0100 (MET) Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 13 Nov 2005 18:18:58 +0100 Received: from 10.21.81.186 ([10.21.81.186]) by xmb-ams-33a.emea.cisco.com ([144.254.231.85]) via Exchange Front-End Server EMAIL.CISCO.COM ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Nov 2005 17:18:58 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 13 Nov 2005 11:00:25 -0500 Subject: Re: [mpls] Last-last call on LSR Self Test From: Monique Morrow To: George Swallow , Message-ID: In-Reply-To: <20051111011553.7CA7512B228@pp109-83.bctel.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2005 17:18:58.0549 (UTC) FILETIME=[55573250:01C5E876] X-Spam-Score: 0.0 (/) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Support last call. /monique On 10/11/05 8:15 pm, "George Swallow" wrote: > This begins a one week last call on LSR Self Test, > draft-ietf-mpls-lsr-self-test-06.txt > > The last call ends 17 NOV 2005 24:00 UTC. > > The last call is limited to the changes made as a result of the previous > last call. Attached are the diffs from version 05 to 06. > > ...George > > > Section 1., para. 1: > OLD: > > This document defines a means for a Label-Switching Router (LSR) to > verify that its dataplane is functioning for certain key Multi-Proto- > col Label Switching (MPLS) applications, including unicast forwarding > based on LDP [LDP] and traffic engineering tunnels based on [RSVP- > TE]. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] are > extended to do the actual probing. The pings are sent to an upstream > neighbor, looped back through the LSR under test and intercepted, by > means of TTL expiration by a downstream neighbor. Extensions to LSP- > Ping [LSP-Ping] are defined to allow the down stream neighbor to > report the test results. > > NEW: > > This document defines a means for a Label-Switching Router (LSR) to > verify that its data plane is functioning for certain key Multi-Pro- > tocol Label Switching (MPLS) applications, including unicast forward- > ing based on LDP [LDP] and traffic engineering tunnels based on > [RSVP-TE]. MPLS Verification Request and MPLS Verification Reply > messages are defined to do the actual probing. The pings are sent to > an upstream neighbor, looped back through the LSR under test and > intercepted, by means of TTL expiration by a downstream neighbor. > > > Section 1., para. 2: > OLD: > > In order to minimize the load on upstream LSRs a new loopback FEC is > defined. Receipt of a packet labeled with a loopback label will cause > the advertising LSR to pop the label off the label stack and send the > packet out the advertised interface. > > NEW: > > In order to minimize the load on upstream LSRs a loopback FEC Type is > defined. Labels advertised with this FEC Type are referred to as > loopback labels. Receipt of a packet labeled with a loopback label > will cause the advertising LSR to pop the label off the label stack > and send the packet out the advertised interface. > > > Section 1., para. 3: > OLD: > > Note that use of a loopback allows an LSR to test label entries for > which the LSR is not currently some neighbor's next hop. In this way > label entries can be verified prior to the occurrence of a routing > change. > > NEW: > > Use of a loopback mechnism allows an LSR to test label entries which > are not currently in use. For example many LSRs advertise label map- > pings for all IPv4 routes to all of their neighbors. For some por- > tion of these their neighbor LSR is not currently upstream and the > label entry is not used. But if the neighbors best path to a desti- > nation changes, that route and the associated label entry will be > used. An LSR can loop traffic through a "non-upstream" LSR because > that LSR is acting only on the loopback label and not on the underly- > ing label associated with the actual FEC being tested. In this way > label entries can be verified prior to the occurrence of a routing > change. > > > Section 1., para. 4: > OLD: > > Some routing protocls, most notably OSPF have no means of exchanging > the "Link Local Identifiers" used to identify unnumbered links and > components of bundled links. These test procedures can be used to > associate the neighbor's interfaces with the probing LSRs interfaces. > This is achieved by simply having the TTL of the MPLS Ping expire one > hop sooner, i.e. at the testing LSR itself. > > NEW: > > Some routing protocols, most notably OSPF have no means of exchanging > the "Link Local Identifiers" used to identify unnumbered links and > components of bundled links. These test procedures can be used to > associate the neighbor's interfaces with the probing LSRs interfaces. > This is achieved by simply having the TTL of the MPLS Ping expire one > hop sooner, i.e. at the testing LSR itself. > > > Section 2., para. 1: > OLD: > > The Loopback FEC type is defined to enable an upstream neighbor to > assist in LSR self-testing at very low cost. This FEC causes the > loopback to occur in the dataplane without control plane involvement > beyond the initial LDP exchange and dataplane setup. The FEC also > carries information to indicate the desired encapsulation should it > be the only label in a received label stack. Values are defined for > IPv4 and IPv6. > > NEW: > > The Loopback FEC type is defined to enable an upstream neighbor to > assist in LSR self-testing at very low cost. This FEC causes the > loopback to occur in the dataplane without control plane involvement > beyond the initial LDP exchange and data-plane setup. The FEC also > carries information to indicate the desired encapsulation should it > be the only label in a received label stack. Values are defined for > IPv4 and IPv6. > > > Section 2.1., para. 3: > OLD: > > Must be set to zero on transmission and ignored on receipt. > > NEW: > > MUST be set to zero on transmission and ignored on receipt. > > > Section 2.1., para. 6: > OLD: > > Note that this type also indicates the encapsulation type for > payloads > that have a label stack contain the one loopback label. > > NEW: > > Note that these type values also indicate the encapsulation (IPv4 or > IPv6) for payloads that have a label stack containing only a > loopback > label. > > > Section 2.2., para. 1: > OLD: > > It is RECOMMENDED that loopback labels only be distributed in > response to a Label Request message, irrespective of the label adver- > tisement mode of the LDP session. However it is recognized that in > certain cases such as OSPF with unnumbered links, the upstream LSR > may not have sufficiently detailed information of the neighbor's link > identifier to form the request. In these cases, the downstream LSR > will need to be configured to make unsolicited advertisements. > > NEW: > > It is RECOMMENDED that loopback labels only be distributed in > response to a Label Request message, irrespective of the label adver- > tisement mode of the LDP session. However it is recognized that in > certain cases such as OSPF with unnumbered links, the upstream LSR > may not have sufficiently detailed information of the neighbor's link > identifier to form the request. In these cases, the downstream LSR > MAY be configured to make unsolicited advertisements. > > > Section 3., para. 1: > OLD: > > A self test operation involves three LSRs, the LSR doing the test, an > upstream neighbor and a downstream neighbor. We refer to these as > LSRs T, U, and D respectively. In order to minimize the processing > load on LSR-D, two new LSP Ping messages are defined, called the MPLS > Data Plane Verification Request and the MPLS Data Plane Verification > Reply. These messages are used to allow LSR-T to obtain the label > stack, address and interface information of LSR-D. > > If FEC verification is required, the MPLS Echo Request and Reply mes- > sages are used. > > NEW: > > A self test operation involves three LSRs, the LSR doing the test, an > upstream neighbor and a downstream LSR. Upstream here is with > respect to the flow of the test (which in some cases could be differ- > ent than the normal sense of upstream in IP routing). We refer to > these as LSRs T, U, and D respectively. In order to minimize the > processing load on LSR-D, two new LSP Ping messages are defined, > called the MPLS Data Plane Verification Request and the MPLS Data > Plane Verification Reply. These messages are used to allow LSR-T to > obtain the label stack, address and interface information of LSR-D. > > > Section 3.1., para. 6: > OLD: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Must Be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | Reply mode | Return Code | Return Subcode| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender's Handle | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLVs ... | > . . > . . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > The MPLS Data Plane Verification Request message MAY contain the fol- > lowing objects: > > NEW: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | MUST Be Zero | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | Reply mode | Return Code | Return Subcode| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender's Handle | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLVs ... | > . . > . . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > The MPLS Data Plane Verification Request message MAY contain the fol- > lowing objects: > > > Section 3.1., para. 7: > OLD: > > Type # Object > ------ ----------- > 3 Pad > 5 Vendor Enterprise Code > 11 (provisional) IPv4 Reply-to Object > 12 (provisional) IPv6 Reply-to Object > > NEW: > > Type # Object > ------ ----------- > 3 Pad > 10 Reply TOS Byte > 11 (provisional) IPv4 Reply-to Address > 12 (provisional) IPv6 Reply-to Address > 64512-65535 Vendor Private TLVs > > > Section 3.1., para. 9: > OLD: > > Type # Object > ------ ----------- > 3 Pad > 4 Error Code > 5 Vendor Enterprise Code > 7 IPv4 Interface and Label Stack Object > 8 IPv6 Interface and Label Stack Object > > NEW: > > Type # Object > ------ ----------- > 7 Interface and Label Stack > 9 Errored TLVs > 64512-65535 Vendor Private TLVs > > > Section 3.2., para. 1: > OLD: > > MPLS Data Plane Verification Request messages MAY be sent to port > 3503 as is used for [LSP-PING]. However to aid implementations that > wish to handle these messages at a lower level than MPLS Echo Request > messages another UDP port, tbd, is provided. Port tbd SHOULD be used > by default. The source UDP port, as in [LSP-PING] is chosen by the > sender. > > NEW: > > MPLS Data Plane Verification Request messages MAY be sent to port > 3503 as is used for [LSP-PING]. However to aid implementations that > wish to handle these messages at a lower level than MPLS Echo Request > messages another UDP port, , is provided. Port SHOULD be > used by default. The source UDP port, as in [LSP-PING] is chosen by > the sender. > > > Section 3.2., para. 2: > OLD: > > 3.3. Reply-To Object > > NEW: > > 3.3. Reply-To Address Object > > > Section 3.2., para. 4: > OLD: > > 3.3.1. IPv4 Reply-To Object > > NEW: > > 3.3.1. IPv4 Reply-To Address Object > > > Section 3.2., para. 5: > OLD: > > The length of an IPv4 Reply-To Object is 4 octets; the value field > has the following format: > > NEW: > > The length of an IPv4 Reply-to Address object is 4 octets; the value > field has the following format: > > > Section 3.2., para. 9: > OLD: > > 3.3.2. IPv6 Reply-To Object > > NEW: > > 3.3.2. IPv6 Reply-To Address Object > > > Section 3.2., para. 10: > OLD: > > The length of an IPv6 Reply-To Object is 16 octets; the value field > has the following format: > > NEW: > > The length of an IPv6 Reply-to Address object is 16 octets; the value > field has the following format: > > > Section 3.4., para. 2: > OLD: > > The LSR creates an MPLS Data Plane Verification Request message and > includes a Data Plane Verification Object. Optionally a FEC Stack > TLV may be included. In this case an MPLS Echo Request Message MUST > be used. > > NEW: > > The LSR creates an MPLS Data Plane Verification Request message. > > > Section 3.4., para. 3: > OLD: > > In normal use, the source address is set to an address belonging to > the LSR and the destination set to an address in the range of 127/8. > The incoming label stack (if any) is prepended to the packet. The > TTL of these labels and the packet header SHOULD be set to appropri- > ate values - 2 for those labels and/or header which will be processed > by this node when the packet is looped back; 1 for those labels > and/or header which will be carried through. Finally the loopback > label bound to the incoming interface is prepended to the packet. In > the case of an otherwise unlabeled packet the label's FEC MUST indi- > cate the appropriate IP version. The TTL is set such that it will > have the value of 3 on the wire. > > NEW: > > In normal use, the source address is set to an address belonging to > the LSR and the destination set to an address in the range of 127/8. > > The incoming label stack (if any) is prepended to the packet. The > TTL of these labels and the packet header SHOULD be set to appropri- > ate values - 2 for those labels and/or header which will be processed > by this node when the packet is looped back; 1 for those labels > and/or header which will be carried through. Finally the loopback > label bound to the incoming interface is prepended to the packet. In > the case of an otherwise unlabeled packet the label's FEC MUST indi- > cate the appropriate IP version. The TTL is set such that it will > have the value of 3 on the wire. > > > Section 3.4., para. 5: > OLD: > > In diagnostic situations, the source and destination addresses MAY be > set to any value. In this case, a Reply-to IPv4 or IPv6 Object MUST > be included. The IP TTL MUST be set to 1. The TTL of labels other > than the loopback label MUST be set to appropriate values - 2 for > those labels which will be process by this LSR when the packet is > looped back; 1 for those labels which will be carried through. > > NEW: > > In diagnostic situations, the source and destination addresses MAY be > set to any value. In this case, a Reply-to IPv4 or IPv6 Address > object MUST be included. The IP TTL MUST be set to 1. The TTL of > labels other than the loopback label MUST be set to appropriate val- > ues - 2 for those labels which will be process by this LSR when the > packet is looped back; 1 for those labels which will be carried > through. > > > Section 3.4., para. 6: > OLD: > > In some MPLS deployments TTL hiding is used to make a providers net- > work appear as a single hop. That is the TTL in the imposed label > does not refect the TTL of the received packet. It is RECOMMENDED > that testing of label imposition SHOULD NOT be performed in such cir- > cumstances as the Echo Request will in most case travel multiple > hops. > > NEW: > > In some MPLS deployments TTL hiding is used to make a providers net- > work appear as a single hop. That is the TTL in the imposed label > does not reflect the TTL of the received packet. It is RECOMMENDED > that testing of label imposition SHOULD NOT be performed in such cir- > cumstances as the Verification Request will in most case travel mul- > tiple hops. > > > Section 3.5., para. 2: > OLD: > > X then parses the packet to ensure that it is a well-formed packet, > and that the TLVs that are not marked "Ignore" are understood. If > not, X SHOULD send an MPLS echo reply with the Return Code set to > "Malformed echo request received" or "TLV not understood" (as appro- > priate), and the Subcode set to zero. In the latter case, the misun- > derstood TLVs (only) are included in the reply. > > NEW: > > X then parses the packet to ensure that it is a well-formed packet, > and that the TLVs that are not marked "Ignore" are understood. If > not, X SHOULD set the Return Code set to "Malformed echo request > received" or "TLV not understood" (as appropriate), and the Subcode > set to zero. In the latter case, the misunderstood TLVs (only) are > included in the reply. > > > Section 3.5., para. 3: > OLD: > > If the echo request is good, X notes the interface I over which the > echo was received, and the label stack with which it came. If the > MPLS echo request contained a Downstream Verification object, then X > must format this information as a Downstream Verification object and > include it in its MPLS echo reply message. > > NEW: > > If the Verification Request is good, X MUST note the interface and > label stack of the received Verification Request and format this > information as a Downstream Verification object. This object is > included in the MPLS Verification Reply message. The Return Code and > Subcode MUST be set to zero, indicating "No return code". > > > Section 3.5., para. 4: > OLD: > > The source address of the Reply message MUST be an address of the > replying LSR. If the request included a Reply-to IPv4 or IPv6 > Object, the MPLS Data Plane Verification Reply message MUST be sent > to that address. Otherwise the Reply message is sent to the source > address of the Verification Request message. > > NEW: > > The source address of the Reply message MUST be an address of the > replying LSR. If the request included a Reply-to IPv4 or IPv6 > Address object, the MPLS Data Plane Verification Reply message MUST > be sent to that address. Otherwise the Reply message is sent to the > source address of the Verification Request message. > > > Section 5., para. 4: > OLD: > > LSP Ping Object Type 11 IPv4 Reply-to Object > LSP Ping Object Type 12 IPv6 Reply-to Object > > NEW: > > LSP Ping Object Type 11 IPv4 Reply-to Address > LSP Ping Object Type 12 IPv6 Reply-to Address > > > Section 7.2., para. 2: > OLD: > > Authors' Addresses > > NEW: > > 8. Authors' Addresses > > > Section 7.2., para. 11: > OLD: > > January 2006 > > NEW: > > April 2006 > > > > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Nov 13 23:30:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbVzN-0006FM-Bi; Sun, 13 Nov 2005 23:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbVzK-0006EA-Lx for mpls@megatron.ietf.org; Sun, 13 Nov 2005 23:30:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23164 for ; Sun, 13 Nov 2005 23:30:04 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbWGE-0004oL-Ub for mpls@ietf.org; Sun, 13 Nov 2005 23:48:08 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id UAA19084; Sun, 13 Nov 2005 20:30:03 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] soft-preemption in cisco routers Date: Mon, 14 Nov 2005 09:59:26 +0530 Message-ID: Thread-Topic: [mpls] soft-preemption in cisco routers Thread-Index: AcXm/nFaPgGf1YJXSDq9VDo5J7eP2gB1SuVw From: "Balaji, Hemanth" To: "S S" , X-Spam-Score: 3.1 (+++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0416546514==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0416546514== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E8D4.142ED00C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E8D4.142ED00C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am not sure if Cisco or Juniper supports "soft preemption". But I'm sure that "Huawei Routers" do. So try seeking help from someone there. =20 -Hemanth. =20 ________________________________ From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of S S Sent: Saturday, November 12, 2005 1:56 AM To: mpls@ietf.org Subject: [mpls] soft-preemption in cisco routers =20 Hi, Do cisco routers support soft-preemption (draft-ietf-mpls-soft-preemption-06.txt ). There is some documentation available in old IOS releases which talk about support for soft preemption(draft-ietf-mpls-soft-preemption-00.txt to be exact). Checked out their feature navigator - no luck. I do know that juniper supports full fledged soft-preemption. Could anyone direct me to some cisco documentation which talks about soft preemption support/configuration etc. Regards, Shiv ------_=_NextPart_001_01C5E8D4.142ED00C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      =      Hi,

      =  

      =             I am = not sure if Cisco or Juniper supports “soft preemption”. But I’m sure = that “Huawei Routers” do. So try seeking help from

      =      someone there.

 

      =      -Hemanth.

 

From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] = On Behalf Of S S
Sent: Saturday, November = 12, 2005 1:56 AM
To: mpls@ietf.org
Subject: [mpls] = soft-preemption in cisco routers

 

Hi,

Do cisco routers support soft-preemption (draft-ietf-mpls-soft-preemption-06.txt ). There is some documentation available in old IOS releases which talk about support for soft preemption(draft-ietf-mpls-soft-preemption-00.txt to be exact). Checked = out their feature navigator - no luck. I do know that juniper supports full = fledged soft-preemption. Could anyone direct me to some cisco documentation = which talks about soft preemption support/configuration etc.

Regards,
Shiv




------_=_NextPart_001_01C5E8D4.142ED00C-- --===============0416546514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0416546514==-- From mpls-bounces@lists.ietf.org Mon Nov 14 04:35:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbakF-0001pU-S1; Mon, 14 Nov 2005 04:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbakD-0001mf-4E for mpls@megatron.ietf.org; Mon, 14 Nov 2005 04:35:21 -0500 Received: from WEXIT1IMC.wind.root.it ([151.17.59.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08160 for ; Mon, 14 Nov 2005 04:34:48 -0500 (EST) Received: from WEXIT11DB.wind.root.it ([10.55.249.84]) by WEXIT1IMC.wind.root.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 10:34:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: R: [mpls] soft-preemption in cisco routers Date: Mon, 14 Nov 2005 10:34:48 +0100 Message-ID: Thread-Topic: [mpls] soft-preemption in cisco routers Thread-Index: AcXm/wvkSMrIbCi5Tq+Cm1yVbNjjLQB/DnZg From: "Di Carlo Domenica" To: X-OriginalArrivalTime: 14 Nov 2005 09:34:35.0847 (UTC) FILETIME=[A04A0570:01C5E8FE] Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1765597480==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1765597480== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E8FE.A7F0931F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E8FE.A7F0931F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, MPLS-TE soft preemption is not yet available in Cisco IOS; it will be. Juniper technology according to the documentation I have, already = supports it. =20 Regards=20 Domenica =20 =20 -----Messaggio originale----- Da: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]Per = conto di S S Inviato: venerd=EC 11 novembre 2005 21.26 A: mpls@ietf.org Oggetto: [mpls] soft-preemption in cisco routers Hi, Do cisco routers support soft-preemption = (draft-ietf-mpls-soft-preemption-06.txt ). There is some documentation = available in old IOS releases which talk about support for soft = preemption(draft-ietf-mpls-soft-preemption-00.txt to be exact). Checked = out their feature navigator - no luck. I do know that juniper supports = full fledged soft-preemption. Could anyone direct me to some cisco = documentation which talks about soft preemption support/configuration = etc. Regards, Shiv = =20 ------_=_NextPart_001_01C5E8FE.A7F0931F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
MPLS-TE soft preemption is not = yet available in=20 Cisco IOS; it will be.
Juniper technology according to the documentation I have, = already=20 supports it.
 
Regards
Domenica

 

 
-----Messaggio originale-----
Da: = mpls-bounces@lists.ietf.org=20 [mailto:mpls-bounces@lists.ietf.org]Per conto di S = S
Inviato:=20 venerd=EC 11 novembre 2005 21.26
A: = mpls@ietf.org
Oggetto:=20 [mpls] soft-preemption in cisco routers

Hi,

Do cisco routers support soft-preemption=20 (draft-ietf-mpls-soft-preemption-06.txt ). There is some documentation = available=20 in old IOS releases which talk about support for soft=20 preemption(draft-ietf-mpls-soft-preemption-00.txt to be exact). Checked = out=20 their feature navigator - no luck. I do know that juniper supports full = fledged=20 soft-preemption. Could anyone direct me to some cisco documentation = which talks=20 about soft preemption support/configuration=20 etc.

Regards,
Shiv



------_=_NextPart_001_01C5E8FE.A7F0931F-- --===============1765597480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1765597480==-- From mpls-bounces@lists.ietf.org Mon Nov 14 07:36:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdZ6-0006mB-Mz; Mon, 14 Nov 2005 07:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdZ4-0006lt-Tk for mpls@megatron.ietf.org; Mon, 14 Nov 2005 07:36:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17183 for ; Mon, 14 Nov 2005 07:35:31 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebdq6-0002IT-FE for mpls@ietf.org; Mon, 14 Nov 2005 07:53:38 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 13:35:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] soft-preemption in cisco routers Date: Mon, 14 Nov 2005 13:35:46 +0100 Message-ID: Thread-Topic: [mpls] soft-preemption in cisco routers Thread-Index: AcXm/nFaPgGf1YJXSDq9VDo5J7eP2gB1SuVwABELK6A= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Balaji, Hemanth" , "S S" , X-OriginalArrivalTime: 14 Nov 2005 12:35:44.0037 (UTC) FILETIME=[EE3C3550:01C5E917] X-Spam-Score: 0.3 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0866846666==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0866846666== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E917.EE099644" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E917.EE099644 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And I'm sure that this is not the kind of discussions we want to see on = this list.... =20 =20 ________________________________ De : mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] = De la part de Balaji, Hemanth Envoy=E9 : lundi 14 novembre 2005 05:29 =C0 : S S; mpls@ietf.org Objet : RE: [mpls] soft-preemption in cisco routers =09 =09 Hi, =20 I am not sure if Cisco or Juniper supports "soft = preemption". But I'm sure that "Huawei Routers" do. So try seeking help = from someone there. =20 -Hemanth. =20 =09 ________________________________ From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] = On Behalf Of S S Sent: Saturday, November 12, 2005 1:56 AM To: mpls@ietf.org Subject: [mpls] soft-preemption in cisco routers =20 Hi, =09 Do cisco routers support soft-preemption = (draft-ietf-mpls-soft-preemption-06.txt ). There is some documentation = available in old IOS releases which talk about support for soft = preemption(draft-ietf-mpls-soft-preemption-00.txt to be exact). Checked = out their feature navigator - no luck. I do know that juniper supports = full fledged soft-preemption. Could anyone direct me to some cisco = documentation which talks about soft preemption support/configuration = etc. =09 Regards, Shiv =09 =09 =09 =09 ------_=_NextPart_001_01C5E917.EE099644 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
And I'm sure that this is not the kind of = discussions we=20 want to see on this list....
 
 

De : = mpls-bounces@lists.ietf.org=20 [mailto:mpls-bounces@lists.ietf.org] De la part de Balaji,=20 Hemanth
Envoy=E9 : lundi 14 novembre 2005=20 05:29
=C0 : S S; mpls@ietf.org
Objet : = RE: [mpls]=20 soft-preemption in cisco routers

          =20 Hi,

       =20

           =       =20 I am not sure if Cisco or Juniper supports =93soft preemption=94. But = I=92m sure=20 that =93Huawei Routers=94 do. So try seeking help=20 from

          =20 someone there.

 

          =20 -Hemanth.

 

From:=20 mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] = On Behalf Of S S
Sent: Saturday, November 12, = 2005 1:56=20 AM
To:=20 mpls@ietf.org
Subject: [mpls]=20 soft-preemption in cisco routers

 

Hi,

Do cisco routers support = soft-preemption=20 (draft-ietf-mpls-soft-preemption-06.txt ). There is some documentation = available in old IOS releases which talk about support for soft=20 preemption(draft-ietf-mpls-soft-preemption-00.txt to be exact). = Checked out=20 their feature navigator - no luck. I do know that juniper supports = full=20 fledged soft-preemption. Could anyone direct me to some cisco = documentation=20 which talks about soft preemption support/configuration=20 etc.

Regards,
Shiv




= ------_=_NextPart_001_01C5E917.EE099644-- --===============0866846666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0866846666==-- From mpls-bounces@lists.ietf.org Fri Nov 18 10:37:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8JJ-00045I-T9; Fri, 18 Nov 2005 10:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8JH-00040d-JG for mpls@megatron.ietf.org; Fri, 18 Nov 2005 10:37:55 -0500 Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24132 for ; Fri, 18 Nov 2005 10:37:19 -0500 (EST) Received: by xproxy.gmail.com with SMTP id t12so223710wxc for ; Fri, 18 Nov 2005 07:37:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Hljlg5OQIUn4ARXhW70eKUi2LLLVBhz4bbBEzD3LNjHZ2AD4aXVs3BCdX563OcCIoAXxgo7e15YRurXOkFmbtzCIXj40KIO4OQLfDgQBRK+FZOqgwoQk2o+YFNANJ5/lkd6gBUI9bJmjLL5PrlX3cpuZnm6taMuo07rsak+PEKY= Received: by 10.70.42.1 with SMTP id p1mr6704741wxp; Fri, 18 Nov 2005 07:37:54 -0800 (PST) Received: by 10.70.20.4 with HTTP; Fri, 18 Nov 2005 07:37:54 -0800 (PST) Message-ID: Date: Fri, 18 Nov 2005 20:37:54 +0500 From: Fahad Dogar To: mpls@ietf.org MIME-Version: 1.0 Cc: Subject: [mpls] On Preemption in a DiffServ aware MPLS-TE environment X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0316086149==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0316086149== Content-Type: multipart/alternative; boundary="----=_Part_6629_23589493.1132328274676" ------=_Part_6629_23589493.1132328274676 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Regarding preemption, I wonder if anyone can comment on how likely is that we will need to preempt several LSPs to accommodate a new LSP? We are currently considering the problem of preemption in a DiffServ aware MPLS environment. Various preemption schemes exist (in literature) some of which try to minimize the number of preempted LSPs. All such schemes assume that the average bandwidth of lower priority requests is *much* smaller as compared to the mean size of higher priority requests and, therefore, imply that multiple lower priority requests need to be preempted to accommodate a higher priority request. Is it reasonable to assume that in a multi-class environment, large variation in traffic patterns of different classes would exist? Any measurements or studies out there? Any justifications for assuming different mean sizes for traffic requests belonging to different classes? In contrast to the popular assumption, if the traffic distribution of different classes is similar in terms of mean bandwidth, it is very *likely= * that accommodating one high-priority LSP would require preempting just one low-priority LSP, especially when the number of LSPs is large. This significantly reduces the complexity of preemption algorithm. How likely is it that for a given traffic request, typically we would need to preempt several LSPs (and not just one) in order to accommodate the new request. Thanks in advance, Fahad ------=_Part_6629_23589493.1132328274676 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi,=
 
Reg= arding preemption, I wonder if anyone can comment on how likely i= s that we will need to preempt several LSPs to accommodate a new LSP?
 
We = are currently considering the problem of preemption in a DiffServ aware MPL= S environment. Various preemption schemes exist (in literature) some of whi= ch try to minimize the number of preempted LSPs. All such schemes assu= me that the average bandwidth of lower priority requests is *much* smaller = as compared to the mean size of higher priority requests and, therefore,&nb= sp;imply that multiple lower priority requests need to be preempted to acco= mmodate a higher priority request. Is it reasonable to assume that in a mul= ti-class environment, large variation in traffic patterns of different= classes would exist? Any measurements or studies out there? Any justificat= ions for assuming different mean sizes for traffic requests belonging = to different classes?
 
In = contrast to the popular assumption, if the traffic distribution of differen= t classes is similar in terms of mean bandwidth, it is very *likely* that a= ccommodating one high-priority LSP would require preempting just one low-pr= iority LSP, especially when the number of LSPs is large. This signific= antly reduces the complexity of preemption algorithm.
 
How likely is it that for a given traffic request, typically we would ne= ed to preempt several LSPs (and not just one) in order to accommodate the n= ew request .
 
Thanks in advance,
Fahad ------=_Part_6629_23589493.1132328274676-- --===============0316086149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0316086149==-- From mpls-bounces@lists.ietf.org Tue Nov 22 10:20:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZwV-0007gF-CM; Tue, 22 Nov 2005 10:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZwT-0007gA-BS for mpls@megatron.ietf.org; Tue, 22 Nov 2005 10:20:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29525 for ; Tue, 22 Nov 2005 10:19:43 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeaF6-0000OV-Vz for mpls@ietf.org; Tue, 22 Nov 2005 10:39:39 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 55B88E00047F for ; Tue, 22 Nov 2005 15:19:56 +0000 (GMT) Received: from Puppy ([217.158.132.128] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 15:01:50 +0000 Message-ID: <042f01c5ef76$22ad4f90$fb849ed9@Puppy> From: "Adrian Farrel" To: Date: Tue, 22 Nov 2005 15:05:00 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_042C_01C5EF76.1BC23920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Nov 2005 15:01:51.0872 (UTC) FILETIME=[AB93A800:01C5EF75] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [mpls] Fw: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_042C_01C5EF76.1BC23920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI GenArt review of this I-D. Adrian ----- Original Message ----- From: "Harald Tveit Alvestrand" To: Cc: ; ; ; ; ; ; ; ; ; ; "Alex Zinin" ; "Bill Fenner" ; ; Sent: Tuesday, November 22, 2005 1:32 PM Subject: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03 ------=_NextPart_000_042C_01C5EF76.1BC23920 Content-Type: text/plain; name="ATT01057.txt" Content-Disposition: attachment; filename="ATT01057.txt" Content-Transfer-Encoding: quoted-printable Document: draft-ietf-mpls-p2mp-sig-requirement-03.txt Reviewer: Harald Alvestrand Date: Nov 22, 2005 Summary: Not ready for publication. Fixable. (Impressively long authors' section!) This is not an unreasonable document. However, I cannot recommend that = it=20 be published as-is. The chief reason is that it does not properly define its target mission. = For a document that is a requirements document for point-to-multipoint=20 signalling, it strangely never defines what a point-to-multipoint = service=20 is. >From context, it appears to be an unidirectional service capable of=20 delivering a signal (a lightstream, bitstream or packet stream?) to=20 multiple destinations. But it never discusses the metric that = distinguish=20 such a service from a P2P service - namely, whether or not there is a=20 requirement for a consistent service to all destinations, or whether the = consistency is part of the quality constraints that the solution has to=20 allow explicit engineering for. The control model of the service is also unclear. >From context, it appears that one envisions that recipients can join = and=20 leave the tree while it's running; it's not clear whether the = requirement=20 is like that for a P2P path, where establishment always involves the=20 head-end of the path, or whether a reasonable solution to the = requirements=20 can allow grafting and pruning down the tree without the head-end being=20 involved (as happens in the "traditional IP multicast" service). Section 4.20 (on GMPLS) is a surprise. While the rest of the document = has=20 been carefully phrased in technology-avoiding language (although = concepts=20 that I think of as RSVP-TE shine through on a regular basis), this = section=20 blatantly specifies specific RSVP-TE objects and features that "have to = be"=20 supported. This seems out of place. The document's security section is inadequate. For a requirements = document,=20 I expect the security section to state the security requirements for a=20 solution - in this case, these are likely to be very similar to those = for=20 P2P signalling, which (if I understand it correctly) involve identifying = the LSRs to each other, and validating that the requester of service has = the right to request service (which requires head-end identification to = all=20 downstream nodes in some fashion). In the P2MP context, I would also expect requirements on the listeners - = whether or not the head-end is required to be able to identify all = egress=20 points seems like a security issue to me. I'm also unhappy with the clarity of the writing in a number of places - = I'll follow up with another message containing a marked-up copy of the=20 draft. Hope this is helpful. ------=_NextPart_000_042C_01C5EF76.1BC23920 Content-Type: application/octet-stream; name="ATT01060.dat" Content-Disposition: attachment; filename="ATT01060.dat" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDgx3ROMj+2+WY0F4RApH0AJ9NqugdZT1gtdnuAPaTQ0uTgN0w2wCfVDb4 9D1KrvLD7oNafFjb01J2294= =ALeA -----END PGP SIGNATURE----- ------=_NextPart_000_042C_01C5EF76.1BC23920 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_042C_01C5EF76.1BC23920-- From mpls-bounces@lists.ietf.org Wed Nov 23 04:26:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeqtg-00043K-3R; Wed, 23 Nov 2005 04:26:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeqte-00042L-66 for mpls@megatron.ietf.org; Wed, 23 Nov 2005 04:26:34 -0500 Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02931 for ; Wed, 23 Nov 2005 04:25:53 -0500 (EST) Received: from itmail02.netfr.alcatel.fr (itmail02.netfr.alcatel.fr [155.132.182.198]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id jAN9Q0pV016814 for ; Wed, 23 Nov 2005 10:26:00 +0100 Received: from [151.98.40.23] ([151.98.40.23]) by itmail02.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2005112310255857:2446 ; Wed, 23 Nov 2005 10:25:58 +0100 Message-ID: <4384366D.9070909@alcatel.it> Date: Wed, 23 Nov 2005 10:29:17 +0100 From: Paolo.Villa@alcatel.it User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/23/2005 10:25:58, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/23/2005 10:26:00, Serialize complete at 11/23/2005 10:26:00 X-Alcanet-MTA-scanned-and-authorized: yes Cc: Subject: [mpls] MPLS Interface over Link Aggregation X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0990410848==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0990410848== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi, I have a quick question regarding MPLS Interface built upon underlying Link Aggregation 
layer (IEEE 802.3 - Chapter 43).

Is it possible to support a per-interface MPLS label space for a MPLS Interface  in this configuration ? or only per-platform
MPLS Label space ?

Any feedbacks (or any constraints) from current MPLS implementations  regarding this configuration ?

Thanks

Paolo
--===============0990410848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0990410848==-- From mpls-bounces@lists.ietf.org Wed Nov 23 08:34:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeulB-0005b6-NX; Wed, 23 Nov 2005 08:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeulA-0005Zi-B3 for mpls@megatron.ietf.org; Wed, 23 Nov 2005 08:34:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00443 for ; Wed, 23 Nov 2005 08:33:24 -0500 (EST) Received: from web26703.mail.ukl.yahoo.com ([217.146.176.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eev3z-0001Iy-03 for mpls@ietf.org; Wed, 23 Nov 2005 08:53:34 -0500 Received: (qmail 67616 invoked by uid 60001); 23 Nov 2005 13:33:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2YInPsYjJwHeoJEuPgzgXhdlRVlwSjWZEz2h4yb0JeWDWw12BiBDNUpbj/DVxqIlMKA1XtvB8/RHHfFqoYuj3YjaMteJVTZGyNnNeKaHKyCcnLkeIVTSBNstU6hes6qKeSu6t0piZoIYwc9uP5RRMe52lUqllE7nQMgHUV+uyMA= ; Message-ID: <20051123133346.67614.qmail@web26703.mail.ukl.yahoo.com> Received: from [59.145.141.130] by web26703.mail.ukl.yahoo.com via HTTP; Wed, 23 Nov 2005 13:33:46 GMT Date: Wed, 23 Nov 2005 13:33:46 +0000 (GMT) From: Spice Sylvia Subject: RE: [mpls] soft-preemption in cisco routers To: mpls@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA00443 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org after having been made to study those "N-layers" with the various cable types and pins that go with it.. --- LE ROUX Jean-Louis RD-CORE-LAN wrote: > And I'm sure that this is not the kind of > discussions we want to see on this list.... > =20 > =20 >=20 >=20 > ________________________________ >=20 > De : mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org] De la part de > Balaji, Hemanth > Envoy=E9 : lundi 14 novembre 2005 05:29 > =C0 : S S; mpls@ietf.org > Objet : RE: [mpls] soft-preemption in cisco routers > =09 > =09 >=20 > Hi, >=20 > =20 >=20 > I am not sure if Cisco or Juniper > supports "soft preemption". But I'm sure that > "Huawei Routers" do. So try seeking help from >=20 > someone there. >=20 > =20 >=20 > -Hemanth. >=20 > =20 >=20 > =09 > ________________________________ >=20 >=20 > From: mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of S > S > Sent: Saturday, November 12, 2005 1:56 AM > To: mpls@ietf.org > Subject: [mpls] soft-preemption in cisco routers >=20 > =20 >=20 > Hi, > =09 > Do cisco routers support soft-preemption > (draft-ietf-mpls-soft-preemption-06.txt ). There is > some documentation available in old IOS releases > which talk about support for soft > preemption(draft-ietf-mpls-soft-preemption-00.txt to > be exact). Checked out their feature navigator - no > luck. I do know that juniper supports full fledged > soft-preemption. Could anyone direct me to some > cisco documentation which talks about soft > preemption support/configuration etc. > =09 > Regards, > Shiv >=20 =09 ___________________________________________________________=20 To help you stay safe and secure online, we've developed the all new Yaho= o! Security Centre. http://uk.security.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Nov 23 21:02:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6Rk-0000Jv-Me; Wed, 23 Nov 2005 21:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewPr-0006rc-QF; Wed, 23 Nov 2005 10:20:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14400; Wed, 23 Nov 2005 10:19:31 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eewij-0007rW-Mf; Wed, 23 Nov 2005 10:39:42 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id E71D9E000681; Wed, 23 Nov 2005 15:19:48 +0000 (GMT) Received: from Puppy ([217.158.132.140] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 15:17:32 +0000 Message-ID: <052801c5f041$7f9af790$fb849ed9@Puppy> From: "Adrian Farrel" To: "Harald Tveit Alvestrand" , References: Date: Wed, 23 Nov 2005 15:16:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Nov 2005 15:17:33.0816 (UTC) FILETIME=[076EA780:01C5F041] X-Spam-Score: 0.1 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 23 Nov 2005 21:02:47 -0500 Cc: jeanlouis.leroux@francetelecom.com, mjork@quarrytech.com, mpls@ietf.org, andy.malis@tellabs.com, Bill Fenner , jpv@cisco.com, dimitri.papadimitriou@alcatel.be Subject: [mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Harald, Thanks for your comments on this I-D. > (Impressively long authors' section!) > > This is not an unreasonable document. However, I cannot recommend > that it be published as-is. > > The chief reason is that it does not properly define its target mission. > For a document that is a requirements document for point-to- > multipoint signalling, it strangely never defines what a point-to- > multipoint service is. > > From context, it appears to be an unidirectional service capable of > delivering a signal (a lightstream, bitstream or packet stream?) to > multiple destinations. Would the following text help? A point-to-multipoint (P2MP) TE LSP is a TE LSP in the definitions of [RFC2702] and [RFC3031] that has a single ingress, one or more egresses, and is unidirecitonal. P2MP services (that deliver data from a single source to one or more receivers) may be supported by any combination of P2P and P2MP LSPs depending on the degree of optimization required within the network, and such LSPs may be Traffic Engineered again depending on the requirements of the network. Further, MP2MP services (that deliver data from more than one source to one or more receivers) may be supported by a combination of P2P and P2MP LSPs. > But it never discusses the metric that distinguish > such a service from a P2P service - namely, whether or not there is a > requirement for a consistent service to all destinations, or whether the > consistency is part of the quality constraints that the solution has to > allow explicit engineering for. I am not convinced that this is the distinction between a P2P service and a P2MP service. I think that the only distinction is that a P2MP service may have more than one receiver. Note that an LSP is *not* a service. It is a building block that may be used to provide a service. I see no reason why one shouldn't have a service that delivers multicast where some receivers have guaranteed quality and others have best-effort quality. It is all a matter of the definition of the service. One might support such a service using multiple LSPs (no change here from P2P services which may be supported by multiple LSPs). Note also that section 4.9 (Variation of LSP Parameters) is very particular about the consistency of the branches of a P2MP LSP, but that does not reflect on the service. I don't propose any changes for this issue. > The control model of the service is also unclear. > > From context, it appears that one envisions that recipients can > join and leave the tree while it's running; it's not clear whether > the requirement is like that for a P2P path, where establishment > always involves the head-end of the path, or whether a reasonable > solution to the requirements can allow grafting and pruning down > the tree without the head-end being involved (as happens in the > "traditional IP multicast" service). I think the comparison with a P2P path is a distraction! It is impossible to have any path without involvement of the data source, and it becuase of this that it is in the nature of a P2P path that the ingress and the (single) egress are involved in the establishment of the path. But your question is really about whether it is possible for leaves to be added and removed without the knowledge or participation of the ingress. As you say, the document makes no requirements in this regard, and that is deliberate: it is left open to the solution work to select an operational mode that is consistent with the solution technology. I think that this is how the service model for "traditional IP multicast" came about. We could make a statement about this non-requirement. Would that make you more comfortable? We would say something like... It is not a requirement that the ingress must control the addition or removal of leaves from the P2MP tree. > Section 4.20 (on GMPLS) is a surprise. While the rest of the document > has been carefully phrased in technology-avoiding language (although > concepts that I think of as RSVP-TE shine through on a regular basis), > this section blatantly specifies specific RSVP-TE objects and features > that "have to be" supported. This seems out of place. You are correct that the reference to RSVP-TE objects are out of place. The features, however, are not RSVP-TE-specific and should remain. I would propose to change section 4.20 as follows: 4.20 GMPLS The requirement for P2MP services for non-packet switch interfaces is similar to that for Packet-Switch Capable (PSC) interfaces. Therefore, it is a requirement that reasonable attempts must be made to make all the features/mechanisms (and protocol extensions) that will be defined to provide MPLS P2MP TE LSPs equally applicable to P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks over-complicate the PSC solution a decision may be taken to separate the solutions. Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or non-PSC TE-LSPs MUST be backward and forward compatible with the other features of GMPLS including: - control and data plane separation, - full support of numbered and unnumbered TE links, - use of the arbitrary labels for and labels for specific technologies, as well as negotiation of labels where necessary to support limited label processing and swapping capabilities, - the ability to apply external control to the labels selected on each hop of the LSP, and to control the next hop label/port/interface for data after it reaches the egress, - support for graceful and alarm-free enablement and termination of LSPs, - full support for proteciton including link level protection, end-to-end protection and segment protection, - the ability to teardown an LSP from a downstream LSR, in particular from the egress, - support for failure and restart or reconnection of the control plane without any disruption of the data plane. In addition, since non-PSC TE-LSPs may have to be processed in environments where the "P2MP capability" could be limited, specific constraints may also apply during the P2MP TE Path computation. Being technology specific, these constraints are outside the scope of this document. However, technology independent constraints (i.e. constraints that are applicable independently of the LSP class) SHOULD be allowed during P2MP TE LSP message processing. It has to be emphasized that path computation and management techniques shall be as close as possible to those being used for PSC P2P TE LSPs and P2MP TE LSPs. > The document's security section is inadequate. For a requirements > document, I expect the security section to state the security > requirements for a solution - in this case, these are likely to be > very similar to those for P2P signalling, which (if I understand it > correctly) involve identifying the LSRs to each other, and validating > that the requester of service has the right to request service (which > requires head-end identification to all downstream nodes in some > fashion). I am generally a supporter of getting as much detail as possible into security sections early in the process. However, it seems peculiar to me that you should suggest that a requirements I-D that is wholly protocol- and solutions-neutral should need to specify the security issues that might arise if a particular solutions option is chosen. Clearly we couldn't hope to describe the security issues for every possible solution. In order to handle the (likely) case that P2MP MPLS-TE is achieved through extensions to RSVP-TE we included a specific paragraph to raise the flag that P2MP signaling solutions cannot assume that they are as secure as the P2P solutions on which they are built. It should be noted that P2MP signaling mechanisms built on P2P RSVP-TE signaling are likely to inherit all of the security techniques and problems associated with RSVP-TE. These problems may be exacerbated in P2MP situations where security relationships may need to maintained between an ingress and multiple egresses. Such issues are similar to security issues for IP multicast. But all of this is just a specific to RSVP-TE, and you are after someting more generic. How about the following extra paragraph? It is a requirement that any P2MP solution developed to meet some or all of the requirements expressed in this document MUST include mechanisms to enable the secure establishment and management of P2MP MPLS-TE LSPs. This includes, but is not limited to: - mechanisms to ensure that the ingress of a P2MP LSP is identified - mechanisms to ensure that communicating signaling entites can verify each other's identities - mechanisms to ensure that messages are protected against spoofing and tampering - mechanisms to ensure that unauthorised leaves or branches are not added to the P2MP LSP - mechanisms to protect signaling messages from snooping. > In the P2MP context, I would also expect requirements on the > listeners - whether or not the head-end is required to be able to > identify all egress points seems like a security issue to me. Don't think I understand you, but maybe this is covered in my proposed text? > I'm also unhappy with the clarity of the writing in a number of places - > I'll follow up with another message containing a marked-up copy of the > draft. Looking forward to that. > Hope this is helpful. If it has improved the quality of the document in a significant measure then it was helpful. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Nov 24 15:05:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNLS-0002qo-8t; Thu, 24 Nov 2005 15:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJXS-00031K-PG; Thu, 24 Nov 2005 11:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20174; Thu, 24 Nov 2005 11:00:53 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfJqX-0004HZ-KU; Thu, 24 Nov 2005 11:21:18 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 032A82596FB; Thu, 24 Nov 2005 17:00:53 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30493-02; Thu, 24 Nov 2005 17:00:47 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 530AA2596F6; Thu, 24 Nov 2005 17:00:42 +0100 (CET) Date: Thu, 24 Nov 2005 16:59:44 +0100 From: Harald Tveit Alvestrand To: Adrian Farrel , gen-art@ietf.org Message-ID: <1A809237B7C83AD209F425A0@B50854F0A9192E8EC6CDA126> In-Reply-To: <052801c5f041$7f9af790$fb849ed9@Puppy> References: <052801c5f041$7f9af790$fb849ed9@Puppy> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 X-Mailman-Approved-At: Thu, 24 Nov 2005 15:05:25 -0500 Cc: jeanlouis.leroux@francetelecom.com, mjork@quarrytech.com, mpls@ietf.org, andy.malis@tellabs.com, Bill Fenner , jpv@cisco.com, dimitri.papadimitriou@alcatel.be Subject: [mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0787967194==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0787967194== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========AF824AA2FA8B9E252813==========" --==========AF824AA2FA8B9E252813========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 23. november 2005 15:16 +0000 Adrian Farrel =20 wrote: > Hi Harald, > > Thanks for your comments on this I-D. > >> (Impressively long authors' section!) >> >> This is not an unreasonable document. However, I cannot recommend >> that it be published as-is. >> >> The chief reason is that it does not properly define its target mission. >> For a document that is a requirements document for point-to- >> multipoint signalling, it strangely never defines what a point-to- >> multipoint service is. >> >> From context, it appears to be an unidirectional service capable of >> delivering a signal (a lightstream, bitstream or packet stream?) to >> multiple destinations. > > Would the following text help? > > A point-to-multipoint (P2MP) TE LSP is a TE LSP in the definitions of > [RFC2702] > and [RFC3031] that has a single ingress, one or more egresses, and is > unidirecitonal. > P2MP services (that deliver data from a single source to one or more > receivers) may > be supported by any combination of P2P and P2MP LSPs depending on the > degree > of optimization required within the network, and such LSPs may be > Traffic > Engineered again depending on the requirements of the network. = Further, > MP2MP > services (that deliver data from more than one source to one or more > receivers) may > be supported by a combination of P2P and P2MP LSPs. Yes, this makes it very clear. > >> But it never discusses the metric that distinguish >> such a service from a P2P service - namely, whether or not there is a >> requirement for a consistent service to all destinations, or whether the >> consistency is part of the quality constraints that the solution has to >> allow explicit engineering for. > > I am not convinced that this is the distinction between a P2P service and > a P2MP service. I think that the only distinction is that a P2MP service > may have more than one receiver. > > Note that an LSP is *not* a service. It is a building block that may be > used to provide a service. I see no reason why one shouldn't have a > service that delivers multicast where some receivers have guaranteed > quality and others have best-effort quality. It is all a matter of the > definition of the service. > > One might support such a service using multiple LSPs (no change here from > P2P services which may be supported by multiple LSPs). > > Note also that section 4.9 (Variation of LSP Parameters) is very > particular about the consistency of the branches of a P2MP LSP, but that > does not reflect on the service. This talks about the parameters (what's requested). I imply that the=20 requirements include an implicit requirement that the ability to deliver on = that promise should be reasonably consistent across the tree too - but that = may not be necessary to say. > I don't propose any changes for this issue. > >> The control model of the service is also unclear. >> >> From context, it appears that one envisions that recipients can >> join and leave the tree while it's running; it's not clear whether >> the requirement is like that for a P2P path, where establishment >> always involves the head-end of the path, or whether a reasonable >> solution to the requirements can allow grafting and pruning down >> the tree without the head-end being involved (as happens in the >> "traditional IP multicast" service). > > I think the comparison with a P2P path is a distraction! It is impossible > to have any path without involvement of the data source, and it becuase = of > this that it is in the nature of a P2P path that the ingress and the > (single) egress are involved in the establishment of the path. > > But your question is really about whether it is possible for leaves to be > added and removed without the knowledge or participation of the ingress. > As you say, the document makes no requirements in this regard, and that = is > deliberate: it is left open to the solution work to select an operational > mode that is consistent with the solution technology. I think that this = is > how the service model for "traditional IP multicast" came about. > > We could make a statement about this non-requirement. Would that make you > more comfortable? We would say something like... > It is not a requirement that the ingress must control the addition > or removal of leaves from the P2MP tree. That would make me more comfortable indeed. > >> Section 4.20 (on GMPLS) is a surprise. While the rest of the document >> has been carefully phrased in technology-avoiding language (although >> concepts that I think of as RSVP-TE shine through on a regular basis), >> this section blatantly specifies specific RSVP-TE objects and features >> that "have to be" supported. This seems out of place. > > You are correct that the reference to RSVP-TE objects are out of place. > The features, however, are not RSVP-TE-specific and should remain. I = would > propose to change section 4.20 as follows: > > 4.20 GMPLS > > The requirement for P2MP services for non-packet switch interfaces > is similar to that for Packet-Switch Capable (PSC) interfaces. > Therefore, it is a requirement that reasonable attempts must be made > to make all the features/mechanisms (and protocol extensions) that > will be defined to provide MPLS P2MP TE LSPs equally applicable to > P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks > over-complicate the PSC solution a decision may be taken to separate > the solutions. > > Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or > non-PSC TE-LSPs MUST be backward and forward compatible with the > other features of GMPLS including: > > - control and data plane separation, > - full support of numbered and unnumbered TE links, > - use of the arbitrary labels for and labels for specific = technologies, > as well as > negotiation of labels where necessary to support limited label > processing and > swapping capabilities, > - the ability to apply external control to the labels selected on each > hop of the > LSP, and to control the next hop label/port/interface for data after > it reaches > the egress, > - support for graceful and alarm-free enablement and termination of > LSPs, > - full support for proteciton including link level protection, > end-to-end protection > and segment protection, > - the ability to teardown an LSP from a downstream LSR, in particular > from the > egress, > - support for failure and restart or reconnection of the control plane > without any > disruption of the data plane. > > In addition, since non-PSC TE-LSPs may have to be processed in > environments where the "P2MP capability" could be limited, specific > constraints may also apply during the P2MP TE Path computation. > Being technology specific, these constraints are outside the scope > of this document. However, technology independent constraints > (i.e. constraints that are applicable independently of the LSP > class) SHOULD be allowed during P2MP TE LSP message processing. > It has to be emphasized that path computation and management > techniques shall be as close as possible to those being used for > PSC P2P TE LSPs and P2MP TE LSPs. That reads much better to me. > >> The document's security section is inadequate. For a requirements >> document, I expect the security section to state the security >> requirements for a solution - in this case, these are likely to be >> very similar to those for P2P signalling, which (if I understand it >> correctly) involve identifying the LSRs to each other, and validating >> that the requester of service has the right to request service (which >> requires head-end identification to all downstream nodes in some >> fashion). > > I am generally a supporter of getting as much detail as possible into > security sections early in the process. However, it seems peculiar to me > that you should suggest that a requirements I-D that is wholly protocol- > and solutions-neutral should need to specify the security issues that > might arise if a particular solutions option is chosen. Clearly we > couldn't hope to describe the security issues for every possible = solution. > > In order to handle the (likely) case that P2MP MPLS-TE is achieved = through > extensions to RSVP-TE we included a specific paragraph to raise the flag > that P2MP signaling solutions cannot assume that they are as secure as = the > P2P solutions on which they are built. > It should be noted that P2MP signaling mechanisms built on P2P > RSVP-TE signaling are likely to inherit all of the security > techniques and problems associated with RSVP-TE. These problems may > be exacerbated in P2MP situations where security relationships may > need to maintained between an ingress and multiple egresses. Such > issues are similar to security issues for IP multicast. > > But all of this is just a specific to RSVP-TE, and you are after someting > more generic. How about the following extra paragraph? > > It is a requirement that any P2MP solution developed to meet some > or all of the requirements expressed in this document MUST include > mechanisms to enable the secure establishment and management of > P2MP MPLS-TE LSPs. This includes, but is not limited to: > - mechanisms to ensure that the ingress of a P2MP LSP is identified > - mechanisms to ensure that communicating signaling entites can > verify each other's identities > - mechanisms to ensure that messages are protected against spoofing > and tampering > - mechanisms to ensure that unauthorised leaves or branches are not > added to the P2MP LSP > - mechanisms to protect signaling messages from snooping. That's exactly what I was looking for, yes! (in bullet 3, does "messages" mean "signalling messages"? I don't think=20 you've traditionally done security of data plane in RSVP-TE....) > >> In the P2MP context, I would also expect requirements on the >> listeners - whether or not the head-end is required to be able to >> identify all egress points seems like a security issue to me. > > Don't think I understand you, but maybe this is covered in my proposed > text? It is - your fourth bullet covers this. > >> I'm also unhappy with the clarity of the writing in a number of places - >> I'll follow up with another message containing a marked-up copy of the >> draft. > > Looking forward to that. > >> Hope this is helpful. > > If it has improved the quality of the document in a significant measure > then it was helpful. Hope it did..... --==========AF824AA2FA8B9E252813========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDheNwOMj+2+WY0F4RAsoHAKDTRDWGtr5HXOXM5DplJnN5mRIX3ACgxN1c fjLM3qV52/b3mx1Z0tx4vRw= =0BuQ -----END PGP SIGNATURE----- --==========AF824AA2FA8B9E252813==========-- --===============0787967194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0787967194==-- From mpls-bounces@lists.ietf.org Fri Nov 25 12:42:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efhab-0002Qf-3v; Fri, 25 Nov 2005 12:42:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efeug-0007Ni-26; Fri, 25 Nov 2005 09:50:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03524; Fri, 25 Nov 2005 09:50:17 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EffDv-0000y2-9B; Fri, 25 Nov 2005 10:10:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 25 Nov 2005 06:50:46 -0800 X-IronPort-AV: i="3.97,377,1125903600"; d="scan'208,217"; a="678513587:sNHT38783728" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAPEogs2026561; Fri, 25 Nov 2005 06:50:42 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 09:50:41 -0500 Received: from [192.168.1.101] ([10.86.240.101]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 09:50:40 -0500 Mime-Version: 1.0 (Apple Message framework v734) To: ccamp@ops.ietf.org, mpls@ietf.org, idr@ietf.org, Mailing List , isis-wg@ietf.org, pce@ietf.org Message-Id: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> From: JP Vasseur Date: Fri, 25 Nov 2005 09:50:08 -0500 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 25 Nov 2005 14:50:40.0769 (UTC) FILETIME=[9ACEB710:01C5F1CF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Fri, 25 Nov 2005 12:42:23 -0500 Cc: LE ROUX Jean-Louis RD-CORE-LAN , "David Kessens \(E-mail\)" , Bill Fenner , "raymond.zhang" Subject: [mpls] Discussion on Multi-technology protection/restoration schemes X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1665625744==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============1665625744== Content-Type: multipart/alternative; boundary=Apple-Mail-17-4186124 --Apple-Mail-17-4186124 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear WGs, Raymond Zhang, Jean-Louis Le Roux and myself have been discussing for a while about the idea of the formation of a new Working Group at the IETF (under the OPS area) in order to discuss operational issues related to the use of multi-technologies in the context of protection/ restoration. This was motivated by a number of discussions that we had with Service Providers expressing some interest in this topic. For the sake of illustration, (1) How to use Fast IGP in conjunction with MPLS TE FRR ? (2) How to use Graceful Restart with Fast IGP or IPFRR ? (3) Multi-technology protection/restoration OAM - ... Indeed, there are many cases where such protection/restoration/HA technologies may interact thus triggering potential race conditions if not used appropriately. The aim of such potential Working Group would be to discuss these issues, document deployment models, ... and potentially come up with problem statements leading to new protocol requirements. Note that the goal of such WG would NOT be to work on protocol extensions but to analyze the problems statements, document combination strategies, ... Protocol extensions would be worked out in other WGs (likely in Routing area). We had a first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got positive feed-back on the usefulness of this work. In the meantime we also received positive feed-back from a number of other Service Providers. A short ID should be posted soon proposing a problem statement. The OPS Area Directors (Bert and David) gave us the approval to create a mailing list to see whether this topic is of interest to the IETF community in which case a BOF may be approved for the next IETF. If you are interested, please join the mailing list and contribute to this work. mter@ietf.org: https://www1.ietf.org/mailman/listinfo/mter Thanks. JP, Jean-Louis and Raymond. --Apple-Mail-17-4186124 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear WGs,

Raymond = Zhang, Jean-Louis Le Roux and myself have been discussing for a while = about the idea of the formation of a new Working Group at the IETF = (under the OPS area) in order to discuss operational issues related to = the use of multi-technologies in the context of protection/restoration. = This was motivated by a number of discussions that we had with Service = Providers expressing some interest in this topic.=A0

For the sake = of illustration,
=A0 =A0 (1)=A0How to use Fast = IGP in conjunction with MPLS TE FRR ?
=A0 =A0 = (2)=A0How to use Graceful Restart with Fast IGP or IPFRR ?
=A0=A0=A0 (3)=A0Multi-technology = protection/restoration OAM=A0
=A0=A0 =A0 - = ...

Indeed, = there are many cases where such protection/restoration/HA technologies = may interact thus triggering potential race conditions if not used = appropriately.=A0

The aim of such potential Working Group would = be to discuss these issues, document deployment models, ... and = potentially come up with problem statements leading to new protocol = requirements. Note that the goal of such WG would NOT be to work on = protocol extensions but to analyze the problems statements, document = combination strategies, ... Protocol extensions would be worked out = in other WGs (likely in Routing area).

We had a = first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki = (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica = (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto = Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got = positive feed-back on the usefulness of this work.=A0

In the = meantime we also received positive feed-back from a number of other = Service Providers.

A short = ID should be posted soon proposing a problem statement.

The OPS Area = Directors (Bert and David) gave us the approval to create a mailing list = to see whether this topic is of interest to the IETF community in which = case a BOF may be approved for the next IETF. If you are interested, = please join the mailing list and contribute to this work.
=A0=A0=A0 mter@ietf.org:=A0<= A href=3D"https://www1.ietf.org/mailman/listinfo/mter">https://www1.ietf.org/mailman/listinfo/mter


JP, = Jean-Louis and Raymond.
= --Apple-Mail-17-4186124-- --===============1665625744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1665625744==-- From mpls-bounces@lists.ietf.org Fri Nov 25 12:42:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efhac-0002RA-Az; Fri, 25 Nov 2005 12:42:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EffZL-0008OG-KU; Fri, 25 Nov 2005 10:32:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08125; Fri, 25 Nov 2005 10:32:18 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Effsc-0002bm-Ku; Fri, 25 Nov 2005 10:52:55 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2005 16:32:49 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAPFWhAT021375; Fri, 25 Nov 2005 16:32:44 +0100 (MET) Received: from [10.61.81.249] (ams-clip-vpn-dhcp4602.cisco.com [10.61.81.249]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA04671; Fri, 25 Nov 2005 15:32:35 GMT Message-ID: <43872E92.2090600@cisco.com> Date: Fri, 25 Nov 2005 15:32:34 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur References: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> In-Reply-To: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Nov 2005 12:42:23 -0500 Cc: ccamp@ops.ietf.org, mpls@ietf.org, "David Kessens \(E-mail\)" , pce@ietf.org, isis-wg@ietf.org, idr@ietf.org, Bill Fenner , "raymond.zhang" , Mailing List Subject: [mpls] Re: [Pce] Discussion on Multi-technology protection/restoration schemes X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org > Raymond Zhang, Jean-Louis Le Roux and myself have been discussing for > a while about the idea of the formation of a new Working Group at the > IETF (under the OPS area) in order to discuss operational issues > related to the use of multi-technologies in the context of > protection/restoration. This was motivated by a number of discussions > that we had with Service Providers expressing some interest in this > topic. > > For the sake of illustration, > (1) How to use Fast IGP in conjunction with MPLS TE FRR ? > (2) How to use Graceful Restart with Fast IGP or IPFRR ? > (3) Multi-technology protection/restoration OAM > - ... Would the wider application of loop-free IGP convergence as described in http://www.ietf.org/internet-drafts/draft-bryant-shand-lf-applicability-00.txt be in scope? - Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Nov 28 05:45:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EggW4-0000rg-2N; Mon, 28 Nov 2005 05:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EggW2-0000rb-6R for mpls@megatron.ietf.org; Mon, 28 Nov 2005 05:45:46 -0500 Received: from smtp1.iitb.ac.in (smtp2.iitb.ac.in [203.199.51.149] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14357 for ; Mon, 28 Nov 2005 05:44:59 -0500 (EST) Received: (qmail 14623 invoked from network); 28 Nov 2005 16:15:08 +0530 Received: from unknown (HELO ldns1.iitb.ac.in) (10.200.12.1) by smtp1.iitb.ac.in with SMTP; 28 Nov 2005 16:15:08 +0530 Received: (qmail 3090 invoked by uid 509); 28 Nov 2005 10:45:08 -0000 Received: from 10.107.1.1 by ldns1 (envelope-from , uid 501) with qmail-scanner-1.25 (clamdscan: 0.87.1/1195. spamassassin: 3.1.0. Clear:RC:1(10.107.1.1):. Processed in 0.016704 secs); 28 Nov 2005 10:45:08 -0000 Received: from unknown (HELO ee.iitb.ac.in) (10.107.1.1) by ldns1.iitb.ac.in with SMTP; 28 Nov 2005 10:45:08 -0000 Received: from director.ee.iitb.ac.in (sharada.ee.iitb.ac.in [10.107.1.2]) by ee.iitb.ac.in (8.12.4/8.12.4) with ESMTP id jASAj7PC014597 for ; Mon, 28 Nov 2005 16:15:08 +0530 (IST) Received: from gayatri.ee.iitb.ac.in (gayatri.ee.iitb.ac.in [10.107.1.5]) by director.ee.iitb.ac.in (8.12.8/8.12.8) with ESMTP id jASAlu1T009131 for ; Mon, 28 Nov 2005 16:17:57 +0530 Date: Mon, 28 Nov 2005 15:35:29 +0530 (IST) From: "Sheetal A. Vispute_p05274" To: mpls@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: [mpls] Query Regarding some parameters in SNMP MIBs X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, I have certain doubts regarding some parameters in MPLS and DiffServ SNMP MIBs. They are as listed below: 1) mplsInSegmentIndex, 2) diffServClfr, 3) diffServClfrElementtable, 4) diffServMeter, 5) diffServMeterTable, 6) diffServAction, 7)diffServQueue. Could you please give the details of each and every structure listed above? And also want to know the difference between an incoming Segment and Incoming Label.. Please do reply. Thanking you in anticipation, Sheetal Vispute _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Nov 28 09:55:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgkPN-00078o-53; Mon, 28 Nov 2005 09:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgkPK-00078c-Vh for mpls@megatron.ietf.org; Mon, 28 Nov 2005 09:55:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15078 for ; Mon, 28 Nov 2005 09:54:22 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgkjA-0000Cl-CA for mpls@ietf.org; Mon, 28 Nov 2005 10:15:40 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Nov 2005 09:54:23 -0500 X-IronPort-AV: i="3.97,385,1125892800"; d="scan'208"; a="76610401:sNHT59027242426" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id jASEsKlo008845; Mon, 28 Nov 2005 09:54:21 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] Query Regarding some parameters in SNMP MIBs Date: Mon, 28 Nov 2005 09:54:15 -0500 To: "Sheetal A. Vispute_p05274" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org On Nov 28, 2005, at 5:05 AM, Sheetal A. Vispute_p05274 wrote: > Hi, > > I have certain doubts regarding some parameters in MPLS and > DiffServ SNMP MIBs. They are as listed below: > > 1) mplsInSegmentIndex, > 2) diffServClfr, > 3) diffServClfrElementtable, > 4) diffServMeter, > 5) diffServMeterTable, > 6) diffServAction, > 7)diffServQueue. > > Could you please give the details of each and every structure > listed above? Have you read the relevant RFCs that contain the MIB modules for these objects? > And also want to know the difference between an incoming Segment > and Incoming Label.. Insegment is roughly equivallent to an incoming label entry in the LFIB. --Tom > > Please do reply. > > Thanking you in anticipation, > Sheetal Vispute > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Nov 29 21:07:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhHN9-000325-PW; Tue, 29 Nov 2005 21:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhHN8-00031t-2Y for mpls@megatron.ietf.org; Tue, 29 Nov 2005 21:07:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10616 for ; Tue, 29 Nov 2005 21:06:17 -0500 (EST) Received: from jens246.inetcore.com ([202.33.8.246] helo=chappy.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhHhI-00078F-G4 for mpls@ietf.org; Tue, 29 Nov 2005 21:27:54 -0500 Received: from nagami-T42.wide.ad.jp (nt-23 [172.16.2.1]) by chappy.inetcore.com (8.13.3/8.13.3) with ESMTP id jAU26W38004875 for ; Wed, 30 Nov 2005 11:06:33 +0900 (JST) (envelope-from nagami@wide.ad.jp) Message-Id: <6.2.0.14.2.20051130102315.08cf25f0@gw.inetcore.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev2.0 Date: Wed, 30 Nov 2005 11:06:27 +0900 To: mpls@ietf.org From: Ken Nagami Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Comments for fastreroute-mib-04 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Dear authors and all, I have a following comment for the FRR MIB (draft-ietf-mpls-fastreroute-mib-04). Could you reflect this comment in the document? Comment: I would like to get a 2nd label of a bypass tunnel at a PLR in the facility backup. I think a pointer of 1st (top) label of the bypass tunnel at a PLR can be get from the FRR MIB. But the 2nd label can not be get. Because I would like to check a 2nd label of a bypass tunnel and an incoming label at the MP. In the case of the node protection, two label values are normally the same. But if a router has a bug, the value might be different. So, we would like to check those values before local repair from a network management box. Regards, Ken Nagami _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Nov 30 15:39:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYjF-0005by-QX; Wed, 30 Nov 2005 15:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYjC-0005XU-Ox; Wed, 30 Nov 2005 15:38:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10190; Wed, 30 Nov 2005 15:38:13 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZ3Y-0002Aw-2w; Wed, 30 Nov 2005 16:00:00 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 81E31E0010EE; Wed, 30 Nov 2005 20:38:40 +0000 (GMT) Received: from Puppy ([217.158.132.251] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 20:38:34 +0000 Message-ID: <039801c5f5ee$81c637c0$d9849ed9@Puppy> From: "Adrian Farrel" To: "Harald Tveit Alvestrand" References: Date: Wed, 30 Nov 2005 20:40:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 30 Nov 2005 20:38:35.0734 (UTC) FILETIME=[09525760:01C5F5EE] X-Spam-Score: 2.9 (++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, Bill Fenner , gen-art@ietf.org Subject: [mpls] Re: [Gen-art] Marked-up copy of draft-ietf-mpls-p2mp-sig-requirement-03 (fwd) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Harald, Thanks for your detailed review. Seisho and I have been through the comments in fine detail (with Seisho doing the work as editor, and me supplying English language text suggestions). Most of your suggestions are fine and we have been able to make edits which we'll publish as soon as we can close down the remaining points. Details in line. Snipped to just the points of contention. > Note that huge chunks of this document use the term "tree" liberally > - but in section 4.11 you talk about "tree remerge" - which makes > the tree be not a tree. This is confusing; if you assume a tree-shaped > pattern, with no merges, you should say so up front; if not, you should > avoid the term "tree". We don't see a problem. The issue that confused you is exactly the problem issue addressed in 4.11 (and which has taken a huge amount of effort in the solutions work). A tree re-merge is a bad thing, but it can happen and must be handled. > These points are equally applicable to point-to-multipoint traffic > engineering. Points 1. and 7. are particularly important. Note that > point 3. implies that the concept of a point-to-multipoint traffic > trunk is defined and is supported (or mapped onto) P2MP LSPs. > > HTA: Supported or mapped onto? I think it wiser to stick to > "mapped onto" only. Well, "mapped onto" is probably not the clearest phrase and doesn't actually have any meaning! "Supported by" has some meaning and we would prefer to use just that phrase, but since 2702 uses "mapped onto" it is provided here for completeness. > Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE > LSPs so new mechanisms need to be developed. This should be achieved > with maximum re-use of existing MPLS protocols. > > Note that there is a separation between routing and signaling in > MPLS TE. In particular, the path of the MPLS TE LSP is determined by > performing a constraint-based computation (such as CSPF) on a traffic > engineering database (TED). The contents of the TED may be collected > through a variety of mechanisms. > > This document focuses on requirements for establishing and > maintaining P2MP MPLS TE LSPs through signaling protocols; and > routing protocols are out of scope. No assumptions are made about > how the TED used as the basis for path computations for P2MP LSPs is > formed. > > HTA: These three paragraphs add no information - neither make > requirements nor make the problem easier to understand. Suggest > removing. We have given the first paragraph a "SHOULD" to make it conform. The second and third paragraphs are the result of long and painful discussion across several working groups. If they do no harm, then they should stay as removing them would probably upset someone. > o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing > egress LSRs to/from an existing P2MP TE LSP. It is assumed that the > HTA: English - "Tunnel endpoints" is different from "receivers" how? A receiver is an IP multicast or unicast receiver. A tunnel end point is the end of a tunnel. Note that it is usual for a TE tunnel to not extend all the way to the receiver. Text was not clear and we have made changes. > rate of change of leaves of a P2MP service (that is, the rate at > which new egress LSRs join, or old egress LSRs are pruned) is "not > so high" because P2MP TE LSPs are assumed to be utilized for TE > applications. This issue is discussed at greater length in section > 4.18.1. > HTA: Since "TE applications" is undefined, this adds no information. > I'd stick a number in here (10 join/leaves per day) and leave it at > that. If you'd like to come to the MPLS working group and argue that 10 join/leaves per day is reasonable, then you have better asbestos than we do! :-) The referenced section is quite careful about this, and we think that "TE application" is well enough understood in the context of 4207. > 1.1 Non-Objectives [snip] > > The following are non-objectives of this document. > HTA: I don't understand this section. A "non-objective" may be > understood in multiple ways: [snip] > I think it would be simpler if this section said "This document does > not specify any requirements for the following functions". Agreed. > In that case, the "algorithms" point does not fit, and should be > dropped. Huh? This document certainly does not specify any requirements for algorithms. Given that there was a lot of discussion in the WG about whether algorithms were in or out of scope, we wished to explicitly state that they are out of scope. > 3.2. Requirements Overview > > The P2MP TE LSP setup mechanism MUST include the ability to > add/remove egress LSRs to/from an existing P2MP TE LSP and MUST > allow for the support of all the TE LSP management procedures > HTA: Would like to say "all the applicable TE LSP.." - see comment about > the establishment of bidirectional tunnels earlier. Not convinced by your point. First, "all applicable" is no help to the reader. Secondly, we are talking here about LSP management procedures. All of the management procedures in 2702 seem to be applicable. > The following are the objectives of P2MP LSP establishment and use. > > d) If a new receiver (R5) expresses an interest in receiving > traffic, a new tree is determined and a B2L sub-LSP from > LSR2 to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a > branch LSR. > > HTA: It's unclear to me whether the requirements want to say anything > about who does this - is it envisioned that R5 expresses the interest to > either S1 or I-LSR1, and that I-LSR1 initiates the change, or is it > envisioned that R5 can express interest straigtht to LSR2 or E-LSR5, > without involving S1 or I-LSR1 in the process? Both, either, or neither. R5 could express its interest to a third party (e.g. NMS). This is very out of scope. See the second non-objective in section 1.1. > 4.5 Fragmentation > > HTA: This section is extremely strange, in that it seems to warn > against a particular choice in a particular solution - not stating the > requirement at all. I'd suggest just saying > > The solution MUST allow the establishing of large P2MP LSPs > (with a large number of LSRs and recipients being identified). > Note that the set of identified LSRs can grow at transit nodes. > > and leave the packet sizes out of it entirely. It is hard to review this section without the history and politics. Of course, what is going on here is specific to particular solutions, but to leave it out will cause a war because it will appear to allow a "bad" solution to be implemented. Although this section contains far too many words, we don't want to suggest removal of any of them. > 4.11 Tree Remerge > > The solution MUST support the case where of multiple signaling > messages for the same P2MP LSP are received at a single transit LSR > and refer to the same upstream interface. In this case the result of > the protocol procedures SHOULD be a single data flow on the upstream > interface. > > HTA: The more interesting question is whether there's a single data > flow on the downstream interfaces - I think the answer is "yes". Hmmm. The answer is actually no. If there is more than one downstream interface, there had better be more than one data flow. The case you are concerned about (multiple signaling related to the same downstream interface) is described later in the same section. Cheers, Adrian and Seisho PS Word version with change markers available on request. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls