From mpls-bounces@ietf.org Fri Apr 1 15:31:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07432; Fri, 1 Apr 2005 15:31:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSvb-0002C0-JI; Fri, 01 Apr 2005 15:39:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSiy-0002ma-FY; Fri, 01 Apr 2005 15: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 1DHSiu-0002m8-A6; Fri, 01 Apr 2005 15:26:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06123; Fri, 1 Apr 2005 15:26:28 -0500 (EST) Message-Id: <200504012026.PAA06123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 01 Apr 2005 15:26:28 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-soft-preemption-04.txt 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Traffic Engineering Soft preemption Author(s) : M. Meyer, et al. Filename : draft-ietf-mpls-soft-preemption-04.txt Pages : 12 Date : 2005-4-1 This document details MPLS Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/eliminating traffic disruption of preempted Traffic Engineered Label Switched Paths. Initially MPLS RSVP-TE was defined supporting only immediate Label Switched Path displacement upon preemption. The utilization of a preemption pending flag helps more gracefully mitigate the re-route process of preempted Label Switched Paths. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the Label Switched Path can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-soft-preemption-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-soft-preemption-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-1155112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-soft-preemption-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-soft-preemption-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-1155112.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Wed Apr 6 07:47:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01069; Wed, 6 Apr 2005 07:47:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ98I-0003jg-4V; Wed, 06 Apr 2005 07:55:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8tO-000503-72; Wed, 06 Apr 2005 07:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI4Df-0001sO-Cw; Sun, 03 Apr 2005 08:28:48 -0400 Received: from sa7.bezeqint.net (sa7.bezeqint.net [192.115.104.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19188; Sun, 3 Apr 2005 08:28:45 -0400 (EDT) Received: from localhost (unknown [127.0.0.1]) by sa7.bezeqint.net (Bezeq International SMTP out Mail Server) with ESMTP id 7AC5A33B55; Sun, 3 Apr 2005 15:20:43 +0300 (IDT) Received: from sa7.bezeqint.net ([127.0.0.1]) by localhost (sa7 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06400-03; Sun, 3 Apr 2005 15:20:10 +0300 (IDT) Received: from ws10 (unknown [212.179.28.80]) by sa7.bezeqint.net (Bezeq International SMTP out Mail Server) with SMTP; Sun, 3 Apr 2005 15:20:10 +0300 (IDT) Message-ID: <012b01c53848$59cee820$6e8fa90a@DOMAINFORUM.LOCAL> From: "sandra" To: <"Undisclosed-Recipient:;"@sa7.bezeqint.net> Date: Sun, 3 Apr 2005 14:25:55 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: amavisd-new at bezeqint.net X-Mailman-Approved-At: Wed, 06 Apr 2005 07:40:16 -0400 Subject: [mpls] TRAFFEX FAIR, BIRMINGHAM, 19-21.4.05, SPECIAL OFFER FOR ACCOMMODATION 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="===============0859252788==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 This is a multi-part message in MIME format. --===============0859252788== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0126_01C53859.0C138DA0" This is a multi-part message in MIME format. ------=_NextPart_000_0126_01C53859.0C138DA0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable TRAFFEX FAIR, BIRMINGHAM, 19-21.4.05 International traffic engineering, road safety and highway maintenance = exhibition. SPECIAL OFFER FOR ACCOMMODATION Chain Hotel Tourist class hotel includes 63 rooms all of them have: coffee / tea = maker, phone, hair dryer, movie channels, trouser press, radio, wake up = service, remote control TV.=20 Other facilities in the hotel: bar, restaurant, free parking. Rate:=20 SGL room per night 150 $ incl. breakfast. DBL room per night 170 $ incl. breakfast. =09 Location: =20 The hotel has central and convenient location, only 4 km from the = International Convention Center and18 km from the Birmingham airport. Additional to the above: our reservation fee of Euro 35 for the entire = reservation. Cancellation fees: 100% - cancellation not possible anymore once booked = and confirmed. Sandra=09 sandra@exhibitionet.com=20 Arion Touristik & Services GmbH=20 Oberl?rickerstr. 372,40547 D?sseldorf=20 Cel.:0049-174-920-8162=20 Tel.:0211/32 20 77 , Fax:0211/32 20 70=20 ------=_NextPart_000_0126_01C53859.0C138DA0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable SPECIAL OFFER FOR FRUIT LOGISTICA 10-12

TRAFFEX FAIR, BIRMINGHAM, 19-21.4.05

International traffic engineering, road safety and highway = maintenance exhibition.

 

SPECIAL = OFFER FOR ACCOMMODATION

 

 

Chain = Hotel

Tourist class hotel includes 63 rooms all of them have: coffee / = tea maker, phone, hair dryer, movie channels, trouser press, radio, wake up service,  remote control = TV.

Other facilities in the hotel: bar, restaurant, free = parking.

 

Rate: =

SGL room per night   150 $   incl. breakfast.=

DBL room per night   170 $  incl. breakfast.

        = ;   

Location:  

The hotel has central and convenient location, only 4 = km from the International Convention Center and18 km from the Birmingham = airport.

 

Additional to the above: = our reservation fee of Euro 35 for the entire = reservation.

Cancellation fees: 100% - cancellation not possible anymore once = booked and confirmed.

 

Sandra        = ; 
sandra@exhibitionet.com
Arion Touristik & = Services GmbH
Oberlörickerstr. = 372,40547 Düsseldorf
Cel.:0049-174-920-8162 =
Tel.:0211/32 20 77 , = Fax:0211/32 20 70

 

 

 

 

------=_NextPart_000_0126_01C53859.0C138DA0-- --===============0859252788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0859252788==-- From mpls-bounces@ietf.org Wed Apr 6 08:21:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05277; Wed, 6 Apr 2005 08:21:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9fL-0005QJ-2E; Wed, 06 Apr 2005 08:29:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9QT-0001Rh-26; Wed, 06 Apr 2005 08:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9QQ-0001RW-Pv for mpls@megatron.ietf.org; Wed, 06 Apr 2005 08:14:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04766 for ; Wed, 6 Apr 2005 08:14:25 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9Yl-0005BS-Bl for mpls@ietf.org; Wed, 06 Apr 2005 08:23:04 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j36CELg8003161 for ; Wed, 6 Apr 2005 07:14:23 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Apr 2005 17:44:20 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D212488048@ii0015exch002u.iprc.lucent.com> From: "Agiwal, Manoj (Manoj)" To: "'mpls@ietf.org'" Date: Wed, 6 Apr 2005 17:44:13 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [mpls] Diffserv E-LSP expto phbid mapping 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi , In case of DiffServ E-LSP for signaled EXP to PHBid mapping , does the EXP to PHB id mapping remains same at all the nodes in the network participating in the LSP , or at each HOP EXP to PHB id changes , depending on the EXP to PHBid configuration on the interface with each neighbor. And in case if signalled EXP to PHBid mapping does not match the incoming interface configuration then the call is rejected. Manoj _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 7 10:40:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29327; Thu, 7 Apr 2005 10:40:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYK7-00058H-Or; Thu, 07 Apr 2005 10:49:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJY5r-0005Bc-VN; Thu, 07 Apr 2005 10:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJY5p-0005BS-4z for mpls@megatron.ietf.org; Thu, 07 Apr 2005 10:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28795; Thu, 7 Apr 2005 10:34:46 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYEO-0004v2-Ga; Thu, 07 Apr 2005 10:43:41 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2005 10:34:39 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j37EYbjI012034; Thu, 7 Apr 2005 10:34:38 -0400 (EDT) Received: from swallow-mac.cisco.com (che-vpn-cluster-2-158.cisco.com [10.86.242.158]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQL02530; Thu, 7 Apr 2005 10:34:37 -0400 (EDT) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 4833A2945A6; Thu, 7 Apr 2005 10:36:00 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id EF9962945A2; Thu, 7 Apr 2005 10:35:59 -0400 (EDT) To: proceedings@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Thu, 07 Apr 2005 10:35:58 -0400 Message-Id: <20050407143600.4833A2945A6@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: mpls@ietf.org Subject: [mpls] (no subject) 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 IETF 62 MPLS WG Meeting March 9, 2005 ---------------------------------------------------------------- Chairs: George Swallow Loa Andersson Scribes: M.Morrow, M. Eubanks Agenda Bash I. WG Status New RFCs: RFC 3988 MTU Extensions for LDP RFC 4023 Encaps MPLS in IP or GRE In IESG Review: ietf-mpls-bundle ietf-mpls-rsvpte-attributes ietf-mpls-nodeod-subobject-05 ietf-mpls-bgp-mpls-restart ietf-mpls-explicit-null (approved) Comments: A. Farrel - Fast track for RFC process would be welcomed for the Bundle draft Working Group Drafts soft pre-emption (ver -04 in pipe) Comment: J-P Vasseur - Should publish -04 next week for pre-emption mpls over l2tpv3 (new) LSP-Ping - Last Call after this meeting LSR-Self-Test - Last Call after LSP Ping II. Incoming liaisons: G.motnni from ITU-T SG 15 (Steve Trowbridge) Loa: Apologized for chairs dropping the liaison by accident (thus no response) Steve: Genoa meeting, editor MPLS Transport - too much included; transport NNI aspects of MPLS itself as transport technology - was not purpose of the document - should be shorter document and narrower in scope Next meeting is in May (ITU-T) Monique: Cisco pointed out problems with draft and liaison needed to be done MFA: Liaison Relationship with IETF Loa: The IETF already has a liaison relationship with the ATM Forum. The IAB wants to await outcome of proposed merger of ATM Forum and MFA before responding. A. Malis: Merger has to be approved by written vote by both existing orgs and still in progress (end of Mar termination of voting period); III. LDP to Draft Standard (Ina Minei) New rev since last IETF draft-3036-bis-01 Removal of host address FEC proved to be a significant change - Thanks E.Rosen and A.Malis for resolution of issue There were a lot of responses from the operational survey. Thanks to the participants, and to Scott Bradener for being the anonymizer. A new draft based on the survey results is available: Draft-minei-ldp-opertal-exper-00.txt A new version of 3036 bis will be posted soon, and this should be ready for last call. There also needs to be an implementation survey, and we will be working on that. IV. Pt-to-MP Signalling Req Draft (S.Yakusawa), pt2mp-sig requirement Rev -04 Removed application scenarios Remove (and apologized for) offensive remarks about PIM Made the choice of signaling protocols less constrained Renamed draft "signalling" Resolved 3 of the 5 outstanding issues 1) Variation of LSP parameters is not allowed 2) transit LSR's can re-optimize a sub tree 3) clarified case of tree re-merger to prevent egress data duplication Two remaining questions and issues: 1) Can short-term data duplication be tolerated 2) Absolute limits and design targets number of recipients number of branch points rate of Join / prune rate of change of tree topology Seisho proposed that the remaining questions be resolved through discussion on the list. Draft to be complete for last call in May or June. Loa: Preferable to have ready in May so that a last call can be completed before Paris. V. Extensions to G/RSVP-TE for P2MP TE LSP's (D. Papadimitriou) draft-ietf-mpls-rsvp-re-p2mp-01 Terminology adapted to requirements doc; Document structure has been reorganized. Open Issues: 1) Style usage (SE vs FF style) 2) Review text for re-merge/cross-over conds 3) Re-optimization (requires consensus whether re-opt may be done on a P2P sub-LSP and / or sub-tree basis) 4) Pruning (deletion) and sub-ERO compression reorg 5) Stitching mechanism - c.f. CCAMP Discussion: George: Right now there are 3 different methods for tearing down an LSP. This seems unnecessarily complicated. Rahul: Point well taken. As you know, we had a huge number of authors. It needs to be pruned down on the mailing list. VI. Detecting P2MP Data Plane Failures (A.Farrell) yasukawa-mpls-p2mp-lsp-ping Need simple and efficient mechanisms to detect data plane failures in P2MP MPLS LSPs Reqs: Verification of reception at recipients Discovering p2mp topology Objective is to build on top of LSP Ping need to introduce RSVP P2MP session sub-TLV Revision 01 has not changed very much. The biggest was that we limited the choice of traceroute destinations to all, or one. Request for WG Rahul: The draft tries to limit the ping to a subset of the recipients? Adrian: Sub-set permitted in sub-set 1 or all (target individual recipient or whole tree) Rahul: If I have a tree with a thousand egresses then I am not sure that that solves my problem. Adrian: Issue is with problem statement - may be need to be a separate draft George: Leave it together for now - if it gets too big then separate VII. Component Link Recording and Resource Control for GMPLS Link Bundles (Zafar Ali) explicit-resource-control-bundle-04 This started in CCAMP at IETF 57. People found issues with link bundling. These were discussed and it was decided that this should be pursued by the MPLS WG. Motivation : TE Link Bundle resources are identified by TE Link ID, Component interface ID and Label value. RFC3209 allows for label recording, component recording would also be useful. RFC3473 allows for label selection; explicit component selection would be useful for applications like LSP splicing and SRLG diversity. Therefore the RRO and ERO should carry component IDs. We think that there is general agreement on the requirement and the solution, and would like to have it adopted as a WG doc. Loa: (after show of hands who read; who believe should be a WG doc) That's pretty good support, so we will take this to the list. Loa: Meeting adjourned - see you in Paris ======================================================================== 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@ietf.org Thu Apr 7 11:26:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04566; Thu, 7 Apr 2005 11:26:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZ2a-00079i-Of; Thu, 07 Apr 2005 11:35:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJY8W-0005Nv-9F; Thu, 07 Apr 2005 10:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJY8U-0005Nq-Eu for mpls@megatron.ietf.org; Thu, 07 Apr 2005 10:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29035 for ; Thu, 7 Apr 2005 10:37:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYH3-00051G-4S for mpls@ietf.org; Thu, 07 Apr 2005 10:46:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2005 07:37:24 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j37EbKgG004346 for ; Thu, 7 Apr 2005 07:37:22 -0700 (PDT) Received: from swallow-mac.cisco.com (che-vpn-cluster-2-158.cisco.com [10.86.242.158]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQL02767; Thu, 7 Apr 2005 10:37:18 -0400 (EDT) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 0DE032945E9; Thu, 7 Apr 2005 10:38:41 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id E245A2945E0 for ; Thu, 7 Apr 2005 10:38:41 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Thu, 07 Apr 2005 10:38:40 -0400 Message-Id: <20050407143841.0DE032945E9@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [mpls] IETF 62 Presentations 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 If you presented at the last MPLS wg meeting, would like your slides included in the proceedings, and haven't sent them to me already, please do so in the next 24 hours. Thanks, ...george ======================================================================== 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@ietf.org Fri Apr 8 11:42:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04258; Fri, 8 Apr 2005 11:42:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvc0-0003ME-UA; Fri, 08 Apr 2005 11:41:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvNP-0007Sv-TI; Fri, 08 Apr 2005 11:26:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvNN-0007S9-NZ for mpls@megatron.ietf.org; Fri, 08 Apr 2005 11:26:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02633 for ; Fri, 8 Apr 2005 11:26:26 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvRI-0002LZ-1j for mpls@ietf.org; Fri, 08 Apr 2005 11:30:32 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 17:21:24 +0200 Received: from l-dhcp-4470-3.rd.francetelecom.fr ([10.193.15.112]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 17:21:24 +0200 From: MORIN Thomas RD-CORE-LAN To: mpls@ietf.org Content-Type: text/plain Organization: France Telecom R&D CORE/CPN Date: Fri, 08 Apr 2005 17:21:19 +0200 Message-Id: <1112973679.24489.47.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2005 15:21:24.0547 (UTC) FILETIME=[A05CA930:01C53C4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [mpls] LDP P2MP Extensions : loops ? 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Hi, Two recent drafts have recently been submitted and propose extensions to LDP to setup multipoint MPLS trees (P2MP and/or MP2MP). The question I have is about the impact of transient loops that may occur because of e.g. IGP inconsistencies, or because of the delay needed to update label switching tables. As you know, IP multicast forwarding implies systematically doing an RPF check against a packet source address, and dropping packets arriving on an interface different from the one that would be used to reach the source, thus effectively preventing exponential growth of the traffic on a loop (always only one upstream interface). With proposed LDP extensions for P2MP, its not hard to see how this RPF-check is "emulated" : impose a break-before-make procedure (labe withdraw THEN label map). But for MP2MP, it seems to me that nothing like this can be done : you'll have to accept traffic on many interfaces, and the label hides the packet source so no RPF-like check can be done, except by looking inside the labeled packet (!...). Thus, it looks to me that exponential-traffic loops can occur during IGP reconvergence in the MP2MP case. So I'd like to know if this problem was considered during the design of the MP2MP solution described in draft-wijnands-mpls-ldp-mcast-ext-00 ? -Thomas _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 8 14:06:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18656; Fri, 8 Apr 2005 14:06:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJy0w-0003Nk-3B; Fri, 08 Apr 2005 14:15:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxq0-0007OQ-GQ; Fri, 08 Apr 2005 14:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxpy-0007N7-MZ for mpls@megatron.ietf.org; Fri, 08 Apr 2005 14:04:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18186 for ; Fri, 8 Apr 2005 14:04:09 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxyl-0003CC-SR for mpls@ietf.org; Fri, 08 Apr 2005 14:13:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Apr 2005 11:04:00 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j38I3rgW018714 for ; Fri, 8 Apr 2005 11:03:58 -0700 (PDT) Received: from swallow-mac.cisco.com (rtp-vpn1-281.cisco.com [10.82.225.25]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQM10335; Fri, 8 Apr 2005 14:03:52 -0400 (EDT) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 0894B297095; Fri, 8 Apr 2005 14:05:16 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id D076B297091 for ; Fri, 8 Apr 2005 14:05:16 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Fri, 08 Apr 2005 14:05:15 -0400 Message-Id: <20050408180516.0894B297095@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [mpls] LDP Multipoint Extensions 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Folks - Recently two drafts on using LDP have been submitted. Technically the workgroup is only chartered for Traffic Engineered multicast. Since we suddenly have two drafts with a number of Service Providers as authors, it would appear that the is a good deal of interest in this. I'd like to get a feel for how wide the support is. If its as wide as it initially appears, I'm hoping that we can get our charter "tweaked" without going through a full re-charter process. Comments Alex and Bill? Since the two drafts are very similar in the P2MP case, I would like to invite (i.e. urge) the authors' to submit a combined draft prior to Paris. ...George ======================================================================== 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@ietf.org Fri Apr 8 16:20:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09024; Fri, 8 Apr 2005 16:20:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK06W-0004Lo-3z; Fri, 08 Apr 2005 16:29:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzvQ-0007oW-JY; Fri, 08 Apr 2005 16:17:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzvM-0007oP-RW for mpls@megatron.ietf.org; Fri, 08 Apr 2005 16:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08850 for ; Fri, 8 Apr 2005 16:17:51 -0400 (EDT) Received: from web60909.mail.yahoo.com ([216.155.196.85]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DK04A-0004Dh-Ju for mpls@ietf.org; Fri, 08 Apr 2005 16:27:00 -0400 Received: (qmail 47425 invoked by uid 60001); 8 Apr 2005 20:17:41 -0000 Message-ID: <20050408201741.47423.qmail@web60909.mail.yahoo.com> Received: from [219.65.139.161] by web60909.mail.yahoo.com via HTTP; Fri, 08 Apr 2005 21:17:41 BST Date: Fri, 8 Apr 2005 21:17:41 +0100 (BST) From: Spice Sylvia Subject: Re: [mpls] Request To: Kireeti Kompella , parvesh minocha In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA08850 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable hi folks :) When salt `A=92 is treated with concentrated H2SO4 , `B=92 (solid) and `C=92 (gas) are formed. `C=92 forms white fumes with NH3 . `B=92 is treated with coke and lime stone and heated to 8000C, a solid `D=92 is formed. `D=92 is treated with water to obtain a solution E and a solid F. When excess CO2 gas is passed through this solution precipitate `G=92 is formed. `G=92 on strong heating gives `E=92. Write the sequence of chemical reactions and identify the substances from A to G. ( 3 ) how do I find the salts? --- Kireeti Kompella wrote: > On Mon, 14 Mar 2005, parvesh minocha wrote: >=20 > > I am a student of B.E(Computer Science). i am > doing my last year > > project on designing of "MULTIPROTOCOL LABEL > SIMULATOR".Plz > > help me in designing this. If any of you have > source code of this > > protocol plz mail it to me as soon as possible. >=20 > Have you considered the possibility that your > professor might be > subscribed to this list? >=20 > Kireeti. > ------- >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 Send instant messages to your online friends http://uk.messenger.yahoo.co= m=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 8 18:27:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17879; Fri, 8 Apr 2005 18:27:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK25x-0001kl-Bp; Fri, 08 Apr 2005 18:36:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1wL-0003GI-Lv; Fri, 08 Apr 2005 18:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1w3-00039o-5S for mpls@megatron.ietf.org; Fri, 08 Apr 2005 18:26:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17799 for ; Fri, 8 Apr 2005 18:26:36 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK24o-0001dy-2m for mpls@ietf.org; Fri, 08 Apr 2005 18:35:47 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 526A3E000074; Fri, 8 Apr 2005 23:26:24 +0100 (BST) Received: from Puppy ([212.43.203.118] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 23:21:53 +0100 Message-ID: <025101c53c89$a010aa40$6fcb2bd4@Puppy> From: "Adrian Farrel" To: "Spice Sylvia" , "Kireeti Kompella" , "parvesh minocha" References: <20050408201741.47423.qmail@web60909.mail.yahoo.com> Subject: Re: [mpls] Request Date: Fri, 8 Apr 2005 23:23:19 +0100 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: 08 Apr 2005 22:21:54.0012 (UTC) FILETIME=[5E4B81C0:01C53C89] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit > how do I find the salts? Have you looked on the shelf next to the spices and herbs? Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 8 18:36:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18687; Fri, 8 Apr 2005 18:36:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2Ep-00029R-Jd; Fri, 08 Apr 2005 18:46:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK243-0005A8-Kb; Fri, 08 Apr 2005 18:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK240-0005A3-Gw for mpls@megatron.ietf.org; Fri, 08 Apr 2005 18:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18515 for ; Fri, 8 Apr 2005 18:34:54 -0400 (EDT) Received: from web60908.mail.yahoo.com ([216.155.196.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DK2Cq-00021u-6f for mpls@ietf.org; Fri, 08 Apr 2005 18:44:05 -0400 Received: (qmail 97169 invoked by uid 60001); 8 Apr 2005 22:34:45 -0000 Message-ID: <20050408223445.97167.qmail@web60908.mail.yahoo.com> Received: from [219.65.139.161] by web60908.mail.yahoo.com via HTTP; Fri, 08 Apr 2005 23:34:45 BST Date: Fri, 8 Apr 2005 23:34:45 +0100 (BST) From: Spice Sylvia Subject: Re: [mpls] Request To: Adrian Farrel , Kireeti Kompella , parvesh minocha In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 8bit 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit --- Adrian Farrel wrote: > > how do I find the salts? > > Have you looked on the shelf next to the spices and > herbs? > The 8000degC is a problem.. somehow at 7000deg C that "thimble" goes "poof" :( > Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Apr 11 10:11:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15903; Mon, 11 Apr 2005 10:11:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzml-0000ih-BM; Mon, 11 Apr 2005 10:21:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzM6-0008Aj-Q3; Mon, 11 Apr 2005 09:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzM4-00089v-LB for mpls@megatron.ietf.org; Mon, 11 Apr 2005 09:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14619 for ; Mon, 11 Apr 2005 09:53:25 -0400 (EDT) Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzVM-0000H3-Du for mpls@ietf.org; Mon, 11 Apr 2005 10:03:09 -0400 Received: from sehan002fe.han.telia.se ([131.115.18.155]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:53:15 +0200 Received: from YBDH014427.teliasonera.com ([131.116.232.83]) by sehan002fe.han.telia.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:53:15 +0200 Message-Id: <6.0.1.1.0.20050411155040.03461930@tmspop.telia.se> X-Sender: ther45@tmspop.telia.se X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 11 Apr 2005 15:53:14 +0200 To: George Swallow , mpls@ietf.org From: Thomas Eriksson Subject: Re: [mpls] LDP Multipoint Extensions In-Reply-To: <20050408180516.0894B297095@swallow-mac.cisco.com> References: <20050408180516.0894B297095@swallow-mac.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Apr 2005 13:53:15.0717 (UTC) FILETIME=[CF367F50:01C53E9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hi, >it would appear that the is a good deal of >interest in this. I'd like to get a feel for how wide the support is. I support adding this work to the WG charter. Thomas _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Apr 11 10:46:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18875; Mon, 11 Apr 2005 10:46:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL0Ko-0001YO-6C; Mon, 11 Apr 2005 10:56:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzyx-0003gU-5m; Mon, 11 Apr 2005 10:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzyv-0003g6-Fk for mpls@megatron.ietf.org; Mon, 11 Apr 2005 10:33:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17901 for ; Mon, 11 Apr 2005 10:33:30 -0400 (EDT) From: kkhanna@isocore.com Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL08A-0001Eh-QY for mpls@ietf.org; Mon, 11 Apr 2005 10:43:16 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.50) id 1DKzyg-0005OM-Qo for mpls@ietf.org; Mon, 11 Apr 2005 10:33:26 -0400 Received: from 68.228.14.175 ([68.228.14.175]) by isocore.com (Horde) with HTTP for ; Mon, 11 Apr 2005 10:33:26 -0400 Message-ID: <20050411103326.iapygmv6qre0o4os@isocore.com> Date: Mon, 11 Apr 2005 10:33:26 -0400 To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [mpls] MPLS 2005 Call for Presentations (Oct 16-19, Wash. DC) 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit ===================================== MPLS 2005 International Conference http://www.mpls2005.com October 16-19, 2005 Washington, DC ====================================== The Program Committee of MPLS2005 () is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution, please send a one page long proposal (including speaker's contact details) to the attention of the Technical Program Committee at mpls2005-cfp@isocore.com by June 10, 2005. This year's conference will include, but not be limited to, topics such as: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Supporting multicast in MPLS VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in the Next Generation Network - Voice over IP/MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Testing the technology: MPLS test tools and experience - Protection, restoration and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - Motivations and requirements for extending MPLS into the access network The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider, research and user community are solicited on new technologies and operational experience. REGISTRATION is also now open, with extremely lucrative early-bird discounts - visit for details. Thank you for your continued support. Regards, Kavita _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 15 04:09:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04616; Fri, 15 Apr 2005 04:09:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMM3q-0002cr-4M; Fri, 15 Apr 2005 04:20:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLYx-000414-JW; Fri, 15 Apr 2005 03:48:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLYv-000402-4D for mpls@megatron.ietf.org; Fri, 15 Apr 2005 03:48:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02923 for ; Fri, 15 Apr 2005 03:48:15 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLiw-0001dv-90 for mpls@ietf.org; Fri, 15 Apr 2005 03:58:46 -0400 Received: from du-203-105.nat.dialup.claranet.fr ([212.43.203.105] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DMLYj-000Llx-78 for mpls@ietf.org; Fri, 15 Apr 2005 08:48:14 +0100 Message-ID: <02fa01c5418f$be1e9050$cdcb2bd4@Puppy> From: "Adrian Farrel" To: Date: Fri, 15 Apr 2005 08:47:46 +0100 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-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Subject: [mpls] Fw: I-D ACTION:draft-yasukawa-mpls-p2mp-lsp-ping-02.txt 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@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Hi, We have updated the P2MP LSP Ping draft. The main changes are: - Addition of a new co-author (Bill Fenner) - Introduction of a new mechanism to allow the jittering of echo responses to avoid swamping the initiator. We would (as always) appreciate your comments on our proposals. As the work on LDP multicast crystallises, we will also look at how this can be covered by the existing or new proposals. Thanks, Adrian ----- Original Message ----- From: To: Sent: Thursday, April 14, 2005 8:45 PM Subject: I-D ACTION:draft-yasukawa-mpls-p2mp-lsp-ping-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Detecting Data Plane Failures in Point-to-Multipoint > MPLS Traffic Engineering - Extensions to LSP Ping > Author(s) : S. Yasukawa, et al. > Filename : draft-yasukawa-mpls-p2mp-lsp-ping-02.txt > Pages : 18 > Date : 2005-4-14 > > Recent proposals have extended the scope of Multi-Protocol Label > Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) > to encompass point-to-multipoint (P2MP) TE LSPs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-lsp-ping-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-yasukawa-mpls-p2mp-lsp-ping-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-yasukawa-mpls-p2mp-lsp-ping-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 15 08:54:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27093; Fri, 15 Apr 2005 08:54:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQVQ-00052r-Uz; Fri, 15 Apr 2005 09:05:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQ6F-0007f8-6P; Fri, 15 Apr 2005 08:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQ6D-0007eX-Gs for mpls@megatron.ietf.org; Fri, 15 Apr 2005 08:39:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26166 for ; Fri, 15 Apr 2005 08:38:56 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQGC-0004Va-IN for mpls@ietf.org; Fri, 15 Apr 2005 08:49:29 -0400 Received: from p5480ce2d.dip.t-dialin.net ([84.128.206.45]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMPMb-0007TM-N5 for mpls@ietf.org; Fri, 15 Apr 2005 07:51:58 -0400 Received: from eawtwhdkdh.asandox.com (xesykvfify.asandox.com [250.42.119.82]) by 84.128.206.45 Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Apr 2005 15:34:09 +0300 Message-ID: Date: Fri, 15 Apr 2005 15:34:09 +0300 From: Myra.Givens@ietf.org To: mpls@ietf.org, mrg-web-archive@ietf.org MIME-Version: 1.0 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [mpls] Congratulations X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "hd@bevivek.com"@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1828640841==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --===============1828640841== Content-Type: multipart/alternative; boundary="269653378227" --269653378227 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello mpls@ietf.org, We tried to contact you earlier about flnanclng your home at a lower rate. I would like to let you know that we have gone ahead and started the preapproval process, Here are the results: Name: Mpls Negotiable Amount: $257,000 to $816,000 Rate: 4.30% - 7.75% For more information or to have a broker contact you please visit: http://g.msn.com/0MNBUS00/1?http://true-offers.com No future contact: http://g.msn.com/0MNBUS00/1?http://true-offers.com/gone.asp Best Regards, Myra Givens, Account Manager --269653378227-- --===============1828640841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1828640841==-- From mpls-bounces@lists.ietf.org Mon Apr 18 04:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNRkP-0001am-6z; Mon, 18 Apr 2005 04:36:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNRkM-0001af-6v for mpls@megatron.ietf.org; Mon, 18 Apr 2005 04:36:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27014 for ; Mon, 18 Apr 2005 04:36:44 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNRv7-0004OH-Q0 for mpls@ietf.org; Mon, 18 Apr 2005 04:47:54 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZYL6028599; Mon, 18 Apr 2005 17:35:34 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZYgg011536; Mon, 18 Apr 2005 17:35:34 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZXdq011530; Mon, 18 Apr 2005 17:35:33 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZX38025183; Mon, 18 Apr 2005 17:35:33 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZWgX025180; Mon, 18 Apr 2005 17:35:32 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZWMk025130; Mon, 18 Apr 2005 17:35:32 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZWUQ008609; Mon, 18 Apr 2005 17:35:32 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3I8ZVHh008606; Mon, 18 Apr 2005 17:35:31 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id RAA01932; Mon, 18 Apr 2005 17:35:29 +0900 (JST) Message-Id: <5.0.2.5.2.20050418145551.05bf8930@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Mon, 18 Apr 2005 17:51:08 +0900 To: From: Seisho Yasukawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [mpls] Resolving the remaining open issues in the P2MP TE Signaling Requirements draft 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 MPLS Working Group, As we reported in the last IETF meeting, we have two final issues to resolve in draft-ietf-mpls-p2mp-sig-requirement. Below are my suggestions for how to close these issues so that we can take the draft to working group last call. Please send your comments to the list. Thanks, Seisho. ---- Issue 1. Data duplication. Section 4.12 describes how data duplication may arise and may be an issue for receivers. We need to decide exactly how much data duplication we can tolerate. The current text says... Instead, the solution MUST provide a mechanism to resolve, limit or avoid data duplication at either or both of: - the point at which the data path diverges - the point at which the data paths converge. THE EXTENT TO WHICH DATA DUPLICATION MAY BE TOLERATED (in time or in a count of bits or packets) IS FOR FURTHER STUDY. We believe that it is not necessary for the requirements draft to quantify the amount of duplication that is permissible, but that we should give stronger guidance on the requirements to protect against duplication. At the same time, we don't want to put constraints on the solution (for example, some solutions may wish to prevent duplication at the point at which the data path diverges, some may wish to handle duplication at the point at which the data path converges, and some may wish to handle duplication when the data is received at the leaf). So, we propose to replace the text quoted above with the following... Instead, the solution: - SHOULD limit to transitory conditions only the cases where network bandwidth is wasted by the existence of duplicate delivery paths. - MUST limit the cases of delivery of duplicate data to an application to error cases or rare transitory conditions. ---- Issue 2. Scaling limits. Section 4.19 sets out the conditions for scaling, and section 4.19.1 attempts to quantify some limits for scaling. Section 4.19.1 is currently described as provisional and for further study, so we need to close the discussion. Number of recipients. Currently the draft says that... ...initial deployments of P2MP TE LSPs may be limited to only several hundred recipients, but also that future deployments may require significantly larger numbers. We believe this should be changed to read ...initial deployments of P2MP TE LSPs will be limited to a maximum of around a hundred recipients, but that medium term deployments may increase this to several hundred, and that future deployments may require significantly larger numbers. Tree dynamics (rate of graft and prune). This requirements discussion is hard to hold without looking at possible applications, but applications have been ruled out of scope for this draft. Nevertheless, we can usefully consider two cases here. a. P2MP tunnels are established through management actions (e.g. P2MP tunnel provisioning) as new leaves are signed up to a service. In this model the management action is likely to be a gating factor and join/prune changes will probably be carried out as bulk changes relatively infrequently. b. P2MP tunnels are automatically managed as the result of some form or routing or signaling action that notifies the root about changes to the leaves. This model will result in individual join/prune operation occurring more often, but it must be remembered that the P2MP TE LSP provides an aggregation technique so that (for example) in the case of a multicast VPN, a leaf represents a participating VPN site, not an individual receiver. (Note that this is only applied to S-PMSI model. In case of I-PMSI model, join/prune operations are occurred during VPN's site addition and deletion process and it is assumed that the frequency of this operation is not so high). Thus join/prune operations are likely to be relatively infrequent. Therefore, no change is proposed to the current text. Effect of join/prune on transit LSRs and control plane load. This issue is shown at the end of section 4.19 with the text Key considerations SHOULD include: - the amount of control plane processing required by the ingress, transit and egress LSRs to add/delete a branch LSP to/from an existing P2MP LSP. We believe that this point needs to be expanded to cover the cost of such a mechanism during join/prune *and* during steady state. That is, the cost of detecting a join/prune operation must not impose a significant burden on an LSR when no join/prune is actually taking place. Therefore, we propose to replace the text above with the following... Key considerations SHOULD include: - the amount of additional control plane processing required in the network to detect whether an add/delete of a new branch is required, and in particular, the amount of processing in steady state when no add/delete is requested - the amount of control plane processing required by the ingress, transit and egress LSRs to add/delete a branch LSP to/from an existing P2MP LSP. Further, we propose that the "SHOULD" in this section is changed to "MUST". _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 18 22:07:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNi8t-0000QX-UK; Mon, 18 Apr 2005 22:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd0L-0006gt-TY for mpls@megatron.ietf.org; Mon, 18 Apr 2005 16:38:03 -0400 Received: from newodin.ietf.org ([10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06923 for ; Mon, 18 Apr 2005 16:37:59 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DNd0K-00075k-8m; Mon, 18 Apr 2005 16:38:00 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 18 Apr 2005 16:38:00 -0400 X-Mailman-Approved-At: Mon, 18 Apr 2005 22:07:09 -0400 Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Link Bundling in MPLS Traffic Engineering' 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: - 'Link Bundling in MPLS Traffic Engineering ' 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. Technical Summary For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct which is described in this document. This document updates the interface identification TLVs defined in GMPLS Signaling Functional Description, [RFC3471]. Working Group Summary Version -04 of the document has been approved by the IESG before. However, while it was in the RFC-Editor queue, the WG identified a problem that was worth fixing before publication. The doc has been re-LC'ed and is back to the IESG for approval of the changes. Protocol Quality The draft was reviewed for the IESG by Alex Zinin RFC-Editor Note Section 4. first para: OLD: As defined in [GMPLS-ROUTING], a TE link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnect LSRs into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling. NEW: As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnect LSRs into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling. Section 4. second para: OLD: As further stated in [GMPLS-ROUTING], depending on the nature of resources that form a particular TE link, for the purpose of GMPLS signaling in some cases a combination of is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, a combination of is not sufficient. Such cases are handled by using the link bundling construct which is described in this document. NEW: As further stated in [GMPLS-ROUTING], depending on the nature of resources that form a particular TE link, for the purpose of GMPLS signaling in some cases a combination of is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, a combination of is not sufficient. Consider, for example, a TE link between a pair of SONET/SDH cross-connects, where this TE link is composed of several fibers. In this case the label is a TDM time slot, and moreover, this time slot is significant only within a particular fiber. Thus, when signaling an LSP over such a TE link, one needs to specify not just the identity of the link, but also the identity of a particular fiber within that TE link, as well as a particular label (time slot) within that fiber. Such cases are handled by using the link bundling construct which is described in this document. Last para: OLD: The purpose of link bundling is to improve routing scalability by reducing the amount of information that has to be handled by OSPF and/or IS-IS. This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of the information. To limit the amount of losses one need to restrict the ^^^^ type of the information that can be aggregated/abstracted. NEW The purpose of link bundling is to improve routing scalability by reducing the amount of information that has to be handled by OSPF and/or IS-IS. This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of the information. To limit the amount of losses one needs to restrict the type of the information that can be aggregated/abstracted. Section 4.3. First para: OLD: Typically, an LSP's ERO will identify the bundled link to be used for the LSP, but not the component link, since information about the bundled link is flooded, but information about the component links is not. The identification of a component link in an ERO is outside the scope of this document. When the bundled link is identified in an ERO or is dynamically identified, the choice of the component link for the LSP is a local matter between the two LSRs at each end of the bundled link. NEW: Typically, an LSP's ERO will identify the bundled link to be used for the LSP, but not the component link, since information about the bundled link is flooded, but information about the component links is not. While Discovery of component link identities to be used in an ERO is outside the scope of the document, it is envisioned that such information may be provided via configuration or via future RRO extensions. When the bundled link is identified in an ERO or is dynamically identified, the choice of the component link for the LSP is a local matter between the two LSRs at each end of the bundled link. Section 4.3. Signaling Considerations, Para 4: OLD: [RFC3471] defines the Interface Identification TLV types. This document specifies that the TLV types 1, 2 and 3 SHOULD be used to indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs. Type 1 TLVs are used for IPv4 numbered component link identifiers. Type 2 TLVs are used for IPv6 numbered component link identifiers. Type 3 TLVs are used for unnumbered component link identifiers. The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used. Note, in Path and REQUEST messages, link identifiers MUST be specified from the sender's perspective. NEW: [RFC3471] defines the Interface Identification type-length-value (TLV) types. This document specifies that the TLV types 1, 2 and 3 SHOULD be used to indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs. Type 1 TLVs are used for IPv4 numbered component link identifiers. Type 2 TLVs are used for IPv6 numbered component link identifiers. Type 3 TLVs are used for unnumbered component link identifiers. The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used. Note, in Path and REQUEST messages, link identifiers MUST be specified from the sender's perspective. Page 5, 3rd para: OLD: In the special case where the same label is to be valid across all component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or ^^^^^^^^^^^ IF_ID TLV. The first TLV indicates the TE link identifier of the bundle on which label allocation must be done. The second TLV indicates a bundle scope label. For TLV types 1 and 2 this is done by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for a type 1 TLV. Per [RFC3471], for TLV types 3, 4 and 5, this is done by setting the Interface ID field to the special value 0xFFFFFFFF. Note that this special case applies to both unidirectional and bidirectional LSPs. NEW: In the special case where the same label is to be valid across all component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID TLV. The first TLV indicates the TE link identifier of the bundle on which label allocation must be done. The second TLV indicates a bundle scope label. For TLV types 1 and 2 this is done by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for a type 1 TLV. Per [RFC3471], for TLV types 3, 4 and 5, this is done by setting the Interface ID field to the special value 0xFFFFFFFF. Note that this special case applies to both unidirectional and bidirectional LSPs. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Apr 19 15:48:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyhe-0001Bw-3t; Tue, 19 Apr 2005 15:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyhc-0001Bq-L6 for mpls@megatron.ietf.org; Tue, 19 Apr 2005 15:48:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14337 for ; Tue, 19 Apr 2005 15:48:06 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNyse-0003bF-J1 for mpls@ietf.org; Tue, 19 Apr 2005 15:59:35 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2005 21:47:56 +0200 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 j3JJlp54024896; Tue, 19 Apr 2005 21:47:52 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4524.cisco.com [10.61.81.171]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA26352; Tue, 19 Apr 2005 20:47:47 +0100 (BST) Message-ID: <42656063.8070301@cisco.com> Date: Tue, 19 Apr 2005 20:47:47 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, swallow@cisco.com, loa@pi.se, Danny McPherson , "W. Mark Townsley" , zinin@psg.com, fenner@research.att.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] PWE3 control draft review request 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 following draft: Pseudowire Setup and Maintenance using LDP http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-16.txt Extends LDP to allow it to set up pseudowires. The PWE3 WG Chairs requests that the MPLS WG review this draft. Please sent comments by COB Wednesday 4th May. Thank you for your help. Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Apr 20 10:43:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGQm-0001ME-DD; Wed, 20 Apr 2005 10:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGQk-0001Lh-E0 for mpls@megatron.ietf.org; Wed, 20 Apr 2005 10:43:54 -0400 Received: from smtp.testbed.se ([80.86.78.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15551 for ; Wed, 20 Apr 2005 10:43:51 -0400 (EDT) Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DOGQ9-0007nT-Iw; Wed, 20 Apr 2005 16:43:19 +0200 Message-ID: <42666A1B.1040101@pi.se> Date: Wed, 20 Apr 2005 16:41:31 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] LDP implementation survey 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, some time ago the draft-thomas-mpls-ldp-survey2002-00.txt it is a republish of the implementor survey we did in 2002. We need this information to take LDP to Draft Standard. IMPORTANT!!!! If there are more implementors that have information, please fill in the survey form in Appendix B in the draft and send it to the working group chairs. If you want to supply such info anonymously send the completed form to Scott Bradner . /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 Wed Apr 20 12:03:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHff-0003nF-B0; Wed, 20 Apr 2005 12:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHfc-0003n8-Lk for mpls@megatron.ietf.org; Wed, 20 Apr 2005 12:03:21 -0400 Received: from smtp.testbed.se ([80.86.78.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22622 for ; Wed, 20 Apr 2005 12:03:17 -0400 (EDT) Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DOHex-00082N-49; Wed, 20 Apr 2005 18:02:47 +0200 Message-ID: <42667CB4.2060204@pi.se> Date: Wed, 20 Apr 2005 18:00:52 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) Content-Transfer-Encoding: 7bit Cc: Stewart Bryant Subject: [mpls] mpls wg review of draft-ietf-pwe3-control-protocol-16.txt 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 pwe3 working group has requested that the mpls working group reviews the draft-ietf-pwe3-control-protocol-16.txt. This review is mainly done to ensure that the extensions and changes of the LDP protocol that has been proposed are done in such away that they don't effect the LDP in general in a negative way. The correct use and understanding of the LDP spec is also within scope of this review. Internet Draft nits and the pros and cons of pseudowires are not within scope. Send the comments to the mpls wg chairs and the mpls wg mailing list before COB May 4th. /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 Wed Apr 20 21:00:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQ3L-0003yd-Ix; Wed, 20 Apr 2005 21:00:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQ3H-0003yV-5Q for mpls@megatron.ietf.org; Wed, 20 Apr 2005 21:00:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15639 for ; Wed, 20 Apr 2005 21:00:17 -0400 (EDT) From: prabakarts@future.futsoft.com Received: from [202.56.251.200] (helo=mail.future.futsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOQEa-0006xn-8D for mpls@ietf.org; Wed, 20 Apr 2005 21:12:01 -0400 Received: from kailash.future.futsoft.com (unverified [10.203.112.3]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Thu, 21 Apr 2005 06:30:18 +0530 Received: from webmail.future.futsoft.com (webmail.future.futsoft.com [10.203.112.133]) by kailash.future.futsoft.com (8.12.8/8.12.8) with ESMTP id j3L0xE7K026373; Thu, 21 Apr 2005 06:29:14 +0530 Received: from webmail.future.futsoft.com (localhost.localdomain [127.0.0.1]) by webmail.future.futsoft.com (8.12.8/8.12.8) with ESMTP id j3L0wvwS026086; Thu, 21 Apr 2005 06:28:57 +0530 Received: (from apache@localhost) by webmail.future.futsoft.com (8.12.8/8.12.8/Submit) id j3L0wvW4026084; Thu, 21 Apr 2005 06:28:57 +0530 X-Authentication-Warning: webmail.future.futsoft.com: apache set sender to prabakarts@future.futsoft.com using -f Received: from 208.246.215.5 (SquirrelMail authenticated user prabakarts) by webmail.futsoft.com with HTTP; Thu, 21 Apr 2005 06:28:57 +0530 (IST) Message-ID: <4413.208.246.215.5.1114045137.squirrel@webmail.futsoft.com> Date: Thu, 21 Apr 2005 06:28:57 +0530 (IST) To: mpls@ietf.org User-Agent: SquirrelMail/1.4.2-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.3 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 8bit Cc: psampath@avici.com Subject: [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout 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 MPLS-WG, I have the following doubts in MPLS LDP Graceful restart : I was searching in the mailing list about this topic, but, I am not able to find out the relevant info, If this question has been already raised and discussed in MPLS-WG, I would greatly appreciate if you could show the pointers. 1. In RFC 3479 states, In section 8.2. FT Session TLV, " FT Reconnection Timeout If the S bit or C bit in the FT Flags field is set, this indicates the period of time the sending LSR will preserve state and resources for FT Labels exchanged on the previous instantiation of an FT LDP session that has recently failed. The timeout is encoded as a 32-bit unsigned integer number of milliseconds. A value of zero in this field means that the sending LSR will preserve state and resources indefinitely. " 2. In RFC 3478 states, In section 2, "Setting the FT Reconnect Timeout to 0 indicates that the sender of the TLV will not preserve its forwarding state across the restart, yet the sender supports the procedures, defined in Section 3.3, "Restart of LDP communication with a neighbor LSR" of this document, and therefore could take advantage if its neighbor to preserve its forwarding state across the restart." Question: ========= In the above point 1, as per RFC 3479, "a value of zero in the FT Reconnect timeout means that the sending LSR will preserve state and resrouces indefinitely" and as in point 2, as per RFC 3478, "if FT Reconnect Timeout is zero, then the sender of the TLV will not preserve its forwarding state across the restart" To me both the RFC 3478 and RFC 3479 conflicts with each other in the above statements, I would like to know which one is appropriate for the LDP graceful restart and what is the industry prefered one and is there anything finalysed in the mailing list/MPLS-WG about this, authors please clarify me regarding this? Thanks in advance, Best regards, Prabakaran T.S. Future Communications Software, a Flextronics company. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 21 18:05:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjo2-0001M9-A7; Thu, 21 Apr 2005 18:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjo0-0001Lu-OK for mpls@megatron.ietf.org; Thu, 21 Apr 2005 18:05:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21453 for ; Thu, 21 Apr 2005 18:05:50 -0400 (EDT) Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjzW-0006rR-6Z for mpls@ietf.org; Thu, 21 Apr 2005 18:17:46 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j3LM5gSK012623 for ; Thu, 21 Apr 2005 18:05:42 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.2.052) id 426289720014C8CB for mpls@ietf.org; Thu, 21 Apr 2005 18:05:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 17:05:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA8C79@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt Thread-Index: AcVGsK+ZB2HmnyVzRdmKlM478mx93gAB+qAAAAFCAXAAACNPsA== From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt 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, Please review and comment on the (significantly) updated draft "Protocol Extensions for Header Compression over MPLS" (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol -00.txt). Here is a brief background and overview/explanation of the updates: Work on requirements for header compression over MPLS (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-mpls-reqs-03.txt) is complete, and work on protocol extensions for header compression over MPLS is underway (previous draft at http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-0 2.txt). Chartering of the protocol work in the AVT working group has been submitted for approval with the following milestone: Dec 05: Submit any extensions for RTP HC on MPLS networks for Proposed Standard There has been considerable discussion on the previous protocol extensions draft (http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol- 02.txt) in the last couple of months. I presented the update on the header compression over MPLS protocol extensions work at the AVT meeting at IETF-62; slides and minutes are available at https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=3D= 6 2 (look under AVT for minutes and slides). The recent discussion and issues regarding the basic approach are summarized in the slides. Header compression experts in the AVT and ROHC working groups wish to re-use, and extend, the existing layer 2 approaches for assignment of context identification (CID) and header compression parameter negotiation. In a multipoint-to-point MPLS environment, one approach would be to have the various header compressors assign CIDs as they do now, with the possible need to resolve CID conflicts/collisions at the header decompressor. Some comments were made that current header compression methods do not have to resolve CID collisions, however the synchronization source (SSRC) assigned in RTP could need collision/conflict resolution. A second approach, suggested by Andy Malis and Loa Andersson, is to use pseudowires and/or targeted LDP to create 'point-to-point' sessions between header compressor and header decompressor, thereby avoiding any issue of CID collision. The disadvantage of this approach is that it requires an additional 4-byte label to be carried with each packet. =20 The updated draft based on the second approach is available at http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol- 00.txt. Once again, please review and comment on the updated draft. Thanks, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, April 21, 2005 3:39 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol Extensions for Header Compression over MPLS Author(s) : J. Ash, et al. Filename : draft-ash-avt-hc-over-mpls-protocol-00.txt Pages : 12 Date : 2005-4-21 =09 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the pseudowires define a point to point instance of each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol- 00.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Apr 22 06:09:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOv6P-0002tZ-GU; Fri, 22 Apr 2005 06:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOv6L-0002t6-Up for mpls@megatron.ietf.org; Fri, 22 Apr 2005 06:09:34 -0400 Received: from oberon.imc.kth.se (oberon.imc.kth.se [193.10.152.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00696 for ; Fri, 22 Apr 2005 06:09:31 -0400 (EDT) Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j3MA7dN15159 for ; Fri, 22 Apr 2005 12:07:39 +0200 Received: from [127.0.0.1] ([172.16.2.232]) by mail1.imc.kth.se; Fri, 22 Apr 2005 12:07:25 +0200 Message-ID: <4268CCD7.3040803@pi.se> Date: Fri, 22 Apr 2005 12:07:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, L2VPN Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Rick Wilder , Bill Fenner , Mark Townsley , Margaret Wasserman , Vach Kompella Subject: [mpls] Summary: mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt 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 mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt has ended. The comments sent to the list has been scarce. We have received a few comments off-line, and also comments from four reviewers that we asked to review the documents. We want to thank Bob T, Ina, Eric G and Dimitri for their reviews. Part of their comments are very useful as "wg chair comments" and will be sent to ADs and authors. Below are the major points captured, based on the reviewer input. Targeted LDP sessions ---------------------- One recurring theme is that a choice to use LDP to signaling vpls de-multiplexors will lead to a full mesh of targeted ldp session between PEs. It has been appointed out that this will potentially cause scaling problems. WG-chair comment: LDP was never intended to support a full mesh of targeted LDP sessions. If LDP is used in this way it must clearly be stated that this is a factor that will limit the scaling of the vpls application, However this is nothing the changes or affects the workings of other usages of LDP. This is local to this draft and should be handled here. MAC List TLV: ------------- A second point is made that the added TLV "MAC List TLV" is an example of using LDP for something it was not intended for. One issue here is that the already, as compared to a routing protocol, long LDP convergence time could be even longer. This will have effects on both "traditional" LDP convergence and the vpls application. The encoding of this TLV is not clearly defined. First the diagram of the TLV depicts MAC addresses that are only 4 bytes long. Second, given the historic confusion between IEEE and IETF encodings some discussion of bit and byte order and some pointers to documents such as RFC1042 would be in order. WG-chair comment: The MPLS working group is concerned about this issue. However we need a better understanding of the dynamics involved before a recommendation can be made. The text on the usage of this TLV is very difficult to parse. Some clean-up is needed. Further use of this TLV should be incorporated into the examples. Use of Generalized PWid FEC Element ----------------------------------- Several fields are not clearly specified. E.g. in section 4.1.1: >> Control bit (C): Depending on whether, on that particular PW, the >> control word is desired or not, the control bit may be specified. simply say: This bit is used to signal use of the control word as specified in [PWE3-CTRL]. >> PW type: The allowed PW types in this version are Ethernet and >> Ethernet VLAN. The phrase "in this version" should be deleted. >> AGI Type field Either a value should be specified (along with a corresponding format) or it should be stated how values are to be selected. >> - Requested VLAN ID: If the PW type is Ethernet VLAN, this >> parameter may be used to signal the insertion of the >> appropriate VLAN ID. This looks under specified. >> Section 7. Operation of a VPLS Since FEC 128 has been moved to an appendix, this section should be recast in terms of FEC 129. >> Section 8.2.2. Failure detection and recovery The hello message only detect control plane failures and not at a particularly fast rate. If fast detection is needed, then VCCV or BFD on the PSN tunnel should be employed. MD5 and security ---------------- A third point that has been made is that the security considerations of the LDP specification were never designed to meet the requirements of VPLS. WG-chair comment: This would definitely be of great concern, but again it does not effect the LDP as a protocol but is limited to the usage of LDP in this application. /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 Mon Apr 25 04:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyaM-0002NL-C2; Mon, 25 Apr 2005 04:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyaI-0002MG-3L for mpls@megatron.ietf.org; Mon, 25 Apr 2005 04:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22567 for ; Mon, 25 Apr 2005 04:04:47 -0400 (EDT) Received: from mss1.koc.net ([193.243.207.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPymT-0003C5-WE for mpls@ietf.org; Mon, 25 Apr 2005 04:17:26 -0400 Received: from kn2smtp1.koc.root ([212.115.20.193]) by mss1.koc.net with InterScan Messaging Security Suite; Mon, 25 Apr 2005 11:04:33 +0300 Importance: normal Priority: normal Received: from kn2srv5.koc.root ([193.243.207.13]) by kn2smtp1.koc.root with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Apr 2005 11:04:32 +0300 Received: from kn2000.kocnet.koc ([195.87.232.9]) by kn2srv5.koc.root with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Apr 2005 11:04:32 +0300 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Apr 2005 11:03:51 +0300 Message-ID: <87E93813DF05C94988EBFAC0D64B1F6D01F3D23A@exchange.koc.net> thread-index: AcVHJInQagpcGx3ITL+pWrpX2rhYogCSMeYN From: "=?iso-8859-9?Q?G=FCrkan_G=FClcan_\=28Ko=E7.net\=29?=" To: X-OriginalArrivalTime: 25 Apr 2005 08:04:32.0327 (UTC) FILETIME=[69AF0D70:01C5496D] X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [mpls] (no subject) 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="===============0575297559==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0575297559== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5496D.6961CE03" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5496D.6961CE03 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable unsubscribe=20 _________________________________________________________________________= ____________________________________________________________________=20 Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. = Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir = sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen = e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini = mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi = bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. = Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan = taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma = sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti = etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu = kabul etmez. =20 This message is intended solely for the use of the individual or entity = to whom it is addressed , and may contain confidential information. If = you are not the intended recipient of this message or you receive this = mail in error, you should refrain from making any use of the contents = and from opening any attachment. In that case, please notify the sender = immediately and return the message to the sender, then, delete and = destroy all copies. This e-mail message, can not be copied, published or = sold for any reason. This e-mail message has been swept by anti-virus = systems for the presence of computer viruses. In doing so, however, = sender cannot warrant that virus or other forms of data corruption may = not be present and do not take any responsibility in any occurrence.=20 _________________________________________________________________________= ____________________________________________________________________=20 =20 =20 =20 ------_=_NextPart_001_01C5496D.6961CE03 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable [mpls] Summary: mpls wg review of = thedraft-ietf-l2vpn-vpls-ldp-06.txt
unsubscribe
________________________________________________________________= _________________________________________________________________________= ____
Bu = e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger = bu e-posta mesaji size yanlislikla ulasmissa,  icerigini hic bir = sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen = e-posta mesajini kullaniciya hemen geri gonderiniz  ve  tum = kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir = sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para = karsiligi satilamaz.  Bu e-posta mesaji viruslere karsi anti-virus = sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin = - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus = icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak = hicbir sorumlulugu kabul etmez.
This = message is intended solely for the use of the individual or entity to = whom it is addressed , and may contain confidential  information. = If you are not the intended recipient of this message or you receive = this mail in error, you should refrain from making any use of the = contents and from opening any attachment. In that case, please notify = the sender immediately and return the message to the sender, then, = delete and destroy all copies. This e-mail message, can not be copied, = published or sold for any reason. This e-mail message has been swept by = anti-virus systems for the presence of computer viruses. In doing so, = however,  sender  cannot warrant that virus or other forms of = data corruption may not be present and do not take any responsibility in = any occurrence.
________________________________________________________________= _________________________________________________________________________= ____
------_=_NextPart_001_01C5496D.6961CE03-- --===============0575297559== 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 --===============0575297559==-- From mpls-bounces@lists.ietf.org Mon Apr 25 12:53:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ6qE-0004Yk-Hl; Mon, 25 Apr 2005 12:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ6qB-0004YD-LO; Mon, 25 Apr 2005 12:53:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01198; Mon, 25 Apr 2005 12:53:44 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ72S-00088S-5U; Mon, 25 Apr 2005 13:06:29 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2005 13:05:35 -0400 X-IronPort-AV: i="3.92,128,1112587200"; d="scan'208"; a="45993846:sNHT30938128" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j3PGrVRQ010675; Mon, 25 Apr 2005 12:53:32 -0400 (EDT) Message-ID: <426D208A.7020603@cisco.com> Date: Mon, 25 Apr 2005 10:53:30 -0600 From: Luca Martini User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson References: <4268CCD7.3040803@pi.se> In-Reply-To: <4268CCD7.3040803@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: L2VPN , mpls@ietf.org, Rick Wilder , Bill Fenner , Mark Townsley , Margaret Wasserman , Vach Kompella Subject: [mpls] Re: Summary: mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt 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 Loa, Comments in line... ..... > > Targeted LDP sessions > ---------------------- > One recurring theme is that a choice to use LDP to signaling > vpls de-multiplexors will lead to a full mesh of targeted > ldp session between PEs. It has been appointed out that this > will potentially cause scaling problems. > > WG-chair comment: LDP was never intended to support a full mesh of > targeted LDP sessions. > > > If LDP is used in this way it must clearly be stated that this is a > factor that will limit the scaling of the vpls application, > However this is nothing the changes or affects the workings of > other usages of LDP. This is local to this draft and should be > handled here. > I would like someone to actually substantiate that there would be a problem with a large number of targeted LDP sessions. It had been my experience that targeted LDP scales very easily beyond any number of session that would be deployed in this application. This is NOT BGP ! Let's not just assume that because BGP with hundreds of thousands routes, and very complex policies , does not scale in a full mesh environment, LDP will have the same fate. > MAC List TLV: > ------------- > A second point is made that the added TLV "MAC List TLV" > is an example of using LDP for something it was not intended > for. One issue here is that the already, as compared to a routing > protocol, long LDP convergence time could be even longer. This > will have effects on both "traditional" LDP convergence and the > vpls application. > As far as i remember , this is a TLV that is going to be used to indicate withdrawal of the mac addresses. When there is a link failure LDP does not advertise new IP label mappings, hence the only "slow down" will be in possibly withdrawing LDP IP label mappings ... And since these are targeted sessions it very likely that there will be no LDP ip label mappings in the first place. Nobody should care about LDP withdrawing IP label mapping , as the IGP is the master , and determines the convergence time. So what is going to be slowed down ? > The encoding of this TLV is not clearly defined. > First the diagram of the TLV depicts MAC addresses that are > only 4 bytes long. > Second, given the historic confusion between IEEE and IETF > encodings some discussion of bit and byte order and some > pointers to documents such as RFC1042 would be in order. > > WG-chair comment: > The MPLS working group is concerned about this issue. However > we need a better understanding of the dynamics involved before > a recommendation can be made. > > The text on the usage of this TLV is very difficult to parse. > Some clean-up is needed. Further use of this TLV should be > incorporated into the examples. > > Use of Generalized PWid FEC Element > ----------------------------------- > > Several fields are not clearly specified. > > E.g. in section 4.1.1: > >> Control bit (C): Depending on whether, on that particular PW, the > >> control word is desired or not, the control bit may be specified. > > > simply say: > > This bit is used to signal use of the control word as specified in > [PWE3-CTRL]. > > > >> PW type: The allowed PW types in this version are Ethernet and > >> Ethernet VLAN. > > > The phrase "in this version" should be deleted. > > > >> AGI Type field > > Either a value should be specified (along with a corresponding format) > or it should be stated how values are to be selected. > > > >> - Requested VLAN ID: If the PW type is Ethernet VLAN, this > >> parameter may be used to signal the insertion of the > >> appropriate VLAN ID. > > > This looks under specified. > > > >> Section 7. Operation of a VPLS > > Since FEC 128 has been moved to an appendix, this section should be > recast in terms of FEC 129. > > >> Section 8.2.2. Failure detection and recovery > > The hello message only detect control plane failures and not at a > particularly fast rate. If fast detection is needed, then > VCCV or BFD on the PSN tunnel should be employed. > > > MD5 and security > ---------------- > > A third point that has been made is that the security > considerations of the LDP specification were never designed > to meet the requirements of VPLS. > > WG-chair comment: This would definitely be of great concern, > but again it does not effect the LDP as a protocol but is > limited to the usage of LDP in this application. > this document should probably point to the pwe3 document and it's security section ... Luca > > /Loa and George > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Apr 25 16:09:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ9ty-0004Nc-1X; Mon, 25 Apr 2005 16:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ9tu-0004NU-L1; Mon, 25 Apr 2005 16:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17918; Mon, 25 Apr 2005 16:09:43 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQA67-0006wR-9s; Mon, 25 Apr 2005 16:22:29 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA05002; Mon, 25 Apr 2005 13:09:24 -0700 (PDT) Message-ID: <039a01c549d2$a59851b0$6501a8c0@IBMT41ML> From: "Marc Lasserre" To: "Luca Martini" , "Loa Andersson" References: <4268CCD7.3040803@pi.se> <426D208A.7020603@cisco.com> Subject: Re: [mpls] Re: Summary: mpls wg review of thedraft-ietf-l2vpn-vpls-ldp-06.txt Date: Mon, 25 Apr 2005 22:09:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: L2VPN , mpls@ietf.org, Rick Wilder , Bill Fenner , Mark Townsley , Margaret Wasserman , Vach Kompella 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 Besides agreeing with Luca's comments, I'd like to add that the VPLS-LDP draft specifies how to reduce the size of the T-LDP full mesh through hierarchical constructs in order to prevent scalability problems with a large number of LDP adjacencies. Existing deployments have demonstrated that large full mesh designs have not caused scalabilty problems. As far as MAC withdrawal is concerned, it is only used when a primary AC fails, specifically in the case of dual-homed MTUs. Hence, I do not see why LDP convergence time should be impacted. I agree with the other comments from the group which call for clarification. Marc ----- Original Message ----- From: "Luca Martini" To: "Loa Andersson" Cc: "L2VPN" ; ; "Rick Wilder" ; "Bill Fenner" ; "Mark Townsley" ; "Margaret Wasserman" ; "Vach Kompella" Sent: Monday, April 25, 2005 6:53 PM Subject: [mpls] Re: Summary: mpls wg review of thedraft-ietf-l2vpn-vpls-ldp-06.txt > Loa, > > Comments in line... > > ..... > >> >> Targeted LDP sessions >> ---------------------- >> One recurring theme is that a choice to use LDP to signaling >> vpls de-multiplexors will lead to a full mesh of targeted >> ldp session between PEs. It has been appointed out that this >> will potentially cause scaling problems. >> >> WG-chair comment: LDP was never intended to support a full mesh of >> targeted LDP sessions. >> >> >> If LDP is used in this way it must clearly be stated that this is a >> factor that will limit the scaling of the vpls application, >> However this is nothing the changes or affects the workings of >> other usages of LDP. This is local to this draft and should be >> handled here. >> > I would like someone to actually substantiate that there would be a > problem with a large number of targeted LDP sessions. > It had been my experience that targeted LDP scales very easily beyond any > number of session that would be deployed in this application. > This is NOT BGP ! Let's not just assume that because BGP with hundreds of > thousands routes, and very complex policies , does not scale in a full > mesh environment, LDP will have the same fate. > > >> MAC List TLV: >> ------------- >> A second point is made that the added TLV "MAC List TLV" >> is an example of using LDP for something it was not intended >> for. One issue here is that the already, as compared to a routing >> protocol, long LDP convergence time could be even longer. This >> will have effects on both "traditional" LDP convergence and the >> vpls application. >> > > As far as i remember , this is a TLV that is going to be used to indicate > withdrawal of the mac addresses. > When there is a link failure LDP does not advertise new IP label mappings, > hence the only "slow down" will be in possibly withdrawing LDP IP label > mappings ... > And since these are targeted sessions it very likely that there will be no > LDP ip label mappings in the first place. > Nobody should care about LDP withdrawing IP label mapping , as the IGP is > the master , and determines the convergence time. > So what is going to be slowed down ? > >> The encoding of this TLV is not clearly defined. >> First the diagram of the TLV depicts MAC addresses that are >> only 4 bytes long. >> Second, given the historic confusion between IEEE and IETF >> encodings some discussion of bit and byte order and some >> pointers to documents such as RFC1042 would be in order. >> >> WG-chair comment: >> The MPLS working group is concerned about this issue. However >> we need a better understanding of the dynamics involved before >> a recommendation can be made. >> >> The text on the usage of this TLV is very difficult to parse. >> Some clean-up is needed. Further use of this TLV should be >> incorporated into the examples. >> >> Use of Generalized PWid FEC Element >> ----------------------------------- >> >> Several fields are not clearly specified. >> >> E.g. in section 4.1.1: >> >> Control bit (C): Depending on whether, on that particular PW, the >> >> control word is desired or not, the control bit may be specified. >> >> >> simply say: >> >> This bit is used to signal use of the control word as specified in >> [PWE3-CTRL]. >> >> >> >> PW type: The allowed PW types in this version are Ethernet and >> >> Ethernet VLAN. >> >> >> The phrase "in this version" should be deleted. >> >> >> >> AGI Type field >> >> Either a value should be specified (along with a corresponding format) >> or it should be stated how values are to be selected. >> >> >> >> - Requested VLAN ID: If the PW type is Ethernet VLAN, this >> >> parameter may be used to signal the insertion of the >> >> appropriate VLAN ID. >> >> >> This looks under specified. >> >> >> >> Section 7. Operation of a VPLS >> >> Since FEC 128 has been moved to an appendix, this section should be >> recast in terms of FEC 129. >> >> >> Section 8.2.2. Failure detection and recovery >> >> The hello message only detect control plane failures and not at a >> particularly fast rate. If fast detection is needed, then >> VCCV or BFD on the PSN tunnel should be employed. >> >> >> MD5 and security >> ---------------- >> >> A third point that has been made is that the security >> considerations of the LDP specification were never designed >> to meet the requirements of VPLS. >> >> WG-chair comment: This would definitely be of great concern, >> but again it does not effect the LDP as a protocol but is >> limited to the usage of LDP in this application. >> > this document should probably point to the pwe3 document and it's > security section ... > > Luca > >> >> /Loa and George >> > > _______________________________________________ > 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 Apr 25 16:36:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQAJi-0001FA-Oy; Mon, 25 Apr 2005 16:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQAJg-0001Ee-Jp for mpls@megatron.ietf.org; Mon, 25 Apr 2005 16:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21992 for ; Mon, 25 Apr 2005 16:36:25 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQAVx-00007L-MM for mpls@ietf.org; Mon, 25 Apr 2005 16:49:12 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2005 16:48:16 -0400 X-IronPort-AV: i="3.92,128,1112587200"; d="scan'208"; a="46036396:sNHT26136940" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3PKa8RW018838; Mon, 25 Apr 2005 16:36:15 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 16:36:11 -0400 Received: from swallow-mac.cisco.com ([161.44.74.106]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 16:36:10 -0400 Received: by swallow-mac.cisco.com (Postfix, from userid 501) id D7D652BDD1C; Mon, 25 Apr 2005 16:36:10 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id A62E92BDD18; Mon, 25 Apr 2005 16:36:10 -0400 (EDT) To: "Adrian Farrel" Subject: Re: [mpls] Last Call on "LSP Ping" In-reply-to: Your message of "Fri, 18 Mar 2005 19:44:17 GMT." <065201c52bf8$2a910cc0$dccb2bd4@Puppy> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Mon, 25 Apr 2005 16:36:09 -0400 Message-Id: <20050425203610.D7D652BDD1C@swallow-mac.cisco.com> X-OriginalArrivalTime: 25 Apr 2005 20:36:10.0998 (UTC) FILETIME=[6A962160:01C549D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 > This is one of the best written I-Ds for a long time! > > A couple of nits. > > Section 4.4 > Note: in all the error codes listed in this draft a stack-depth of 0 > means "no value specified". This allows compatibility with existing > implementations which do not use the Return Subcode field. > s/draft/document/ Thanks. > Section 7 > There are several specific codepoints defined in the draft and marked as > "to be defined by IANA". These are specific values within the new name > spaces defined in section 7. I think it would help IANA if you listed all > of the defined values in a central place (perhaps with references to the > defining sections). Good idea. Will include. > Appendix A. > I'm sure this one has been out and round the block several times. > Notwithstanding that the appendix is non-normative, why is it included? I > thought we were doing no new work (apart from drafts listed in RFC3468) > related to CR-LDP. Is there anyone who objects to removing Appendix A? > Section 3.5 > The Error Code TLV > I think no-one came up with a use for this. Since we try not to define > things unless we have an actual use, perhaps this TLV should be retired. I'll leave it to Kireeti to defend as I also suggested taking it out. > And a silly question. > > Suppose I have an RSVP-TE LSP that starts on an IPv6 LSR and ends on an > IPv4 LSR (or vice versa). > So I have an IPv6 Sender Template and IPv4 Session (or vice versa). > How do I encode the Target FEC Stack? > Or perhaps this is just an unrealistic deployment? Hmmm. Good luck getting a notify message back! Not something I was planning to support. ======================================================================== 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 Mon Apr 25 16:51:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQAXx-0008Ru-Lp; Mon, 25 Apr 2005 16:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQAXv-0008QH-2W for mpls@megatron.ietf.org; Mon, 25 Apr 2005 16:51:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27256 for ; Mon, 25 Apr 2005 16:51:08 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQAkD-000245-PD for mpls@ietf.org; Mon, 25 Apr 2005 17:03:55 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Apr 2005 16:51:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3PKo4Rw023048; Mon, 25 Apr 2005 16:50:59 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 16:50:49 -0400 Received: from swallow-mac.cisco.com ([161.44.74.106]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 16:50:48 -0400 Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 343E72BDD96; Mon, 25 Apr 2005 16:50:49 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 0FC8E2BDD8D; Mon, 25 Apr 2005 16:50:49 -0400 (EDT) To: "David Allan" Subject: Re: [mpls] Last Call on "LSP Ping" In-reply-to: Your message of "Fri, 18 Mar 2005 13:40:57 EST." <87AC5F88F03E6249AEA68D40BD3E00BE03192EE1@zcarhxm2.corp.nortel.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Mon, 25 Apr 2005 16:50:47 -0400 Message-Id: <20050425205049.343E72BDD96@swallow-mac.cisco.com> X-OriginalArrivalTime: 25 Apr 2005 20:50:49.0090 (UTC) FILETIME=[75F85620:01C549D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Dave - Actually, the text you cite should have been removed from this draft. It went with the last set of processing rules. It was pointed out that an implicit null could occur anywhere in the stack, and the procedure make too bold an assumption. So I rewrote the rules to cover the case. But I forgot to remove the "preprocessing step". So thanks for pointing it out (even if that wasn't quite your intention ;-). ...George ======================================================================== 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 Mon Apr 25 17:21:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQB1a-0000iP-05; Mon, 25 Apr 2005 17:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQB1Y-0000iJ-By for mpls@megatron.ietf.org; Mon, 25 Apr 2005 17:21:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00956 for ; Mon, 25 Apr 2005 17:21:45 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQBDr-0003c0-7J for mpls@ietf.org; Mon, 25 Apr 2005 17:34:32 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2005 17:33:38 -0400 X-IronPort-AV: i="3.92,128,1112587200"; d="scan'208"; a="46044569:sNHT29013582" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3PLLGRc002532; Mon, 25 Apr 2005 17:21:36 -0400 (EDT) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 17:21:34 -0400 Received: from swallow-mac.cisco.com ([161.44.74.106]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 17:21:33 -0400 Received: by swallow-mac.cisco.com (Postfix, from userid 501) id EF7D62BDF5D; Mon, 25 Apr 2005 17:21:33 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id CDB4F2BDF54; Mon, 25 Apr 2005 17:21:33 -0400 (EDT) To: Igor Vulanovic Subject: Re: [mpls] Last Call on "LSP Ping" In-reply-to: Your message of "Mon, 28 Mar 2005 15:56:01 EST." <42486F61.278349C0@alcatel.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Mon, 25 Apr 2005 17:21:32 -0400 Message-Id: <20050425212133.EF7D62BDF5D@swallow-mac.cisco.com> X-OriginalArrivalTime: 25 Apr 2005 21:21:33.0981 (UTC) FILETIME=[C19C5CD0:01C549DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 > 1) Clarification of Mandatory vs. Optional TLVs > > The draft is unclear about which TLVs are mandatory > and which are optional. It is also unclear about > the format of the TLV "type" field. > > On one hand, the draft suggests that each TLV has > a type (i.e. Target FEC TLV is type 1) which determines > whether or not that TLV is optional or mandatory. > This determination is based on whether the TLV > type is above or below 32768. > On the other hand, for example, the draft suggests that the > Target FEC TLV is mandatory in an echo request and > optional in an echo response. > Another example is the Vendor Enterprise TLV. The > draft says that to determine if the Vendor Enterprise > TLV is mandatory/optional, one must look at the > values in Message Type, Reply Mode, Return Code and > Return Subcode. I think a chief problem is that we've used Mandatory/Optional in two different senses and haven't been clear on which we're talking about. The Type code indicates whether the TLV is Mandatory or Optional to *process*. That is, if you encounter one of these, then an implementation much either process it or return an error code saying it doesn't understand the TLV. We've been less diligent on saying what TLVs are Mandatory/Optional in the messages. We've also spread that text about the draft. So if there's a general feeling that this is getting too complicated, I'm willing to put in some BNR message descriptions a la RSVP. > It would seem that one can not rely only on the high > order bit in the TLV type to determine if the TLV is > mandatory/optional. Actually, with the above clarification, you can. > 2) Vendor Enterprise Code TLV > > Section 3.6 of the draft describes the Vendor Enterprise Code TLV. > However, that section is not totally complete. There is extra > information in section 7.1 regarding which fields can contain > values in the vendor private range. It would be better to include > more information in section 3.6 or else reference section 7.1. I'll add the forward reference. > 3) Addition of DS Flags in Downstream Mapping TLV > > It seems strange to have a flag inside the Downstream > Mapping TLV which indicates a request to have an > Interface and Label TLV included in the echo reply. > > Is there a better way to do this? > > Would it make more sense to use the Global Flags inside the > fixed fields for this purpose? We went back and forth on this. Our conservatism lead us toward not wasting the global flag space. > 4) NIL FEC > > Why do we need more than one label in the Nil FEC TLV? > My understanding is that each FEC stack sub-TLV corresponds > to one label in the label stack. > Is this for the case where there are multiple back-to-back > reserved labels in the label stack? Is the intent to be > able to represent those back-to-back labels in one single > Nil FEC sub-TLV? > Would it be simpler to just have one label in each Nil FEC > sub-TLV? This way, each FEC sub-TLV always corresponds to > a single label in the label stack. I support your proposed change. Other opinions? > 5) CR-LDP FEC Appendix A.1 > > There appears to be a typo here. The length of the CR-LDP > FEC should be 8 instead of 6. I'll fix it if we don't drop it altogether. ...George ======================================================================== 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 Mon Apr 25 18:24:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQC0B-0000Y9-Ut; Mon, 25 Apr 2005 18:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQC09-0000XQ-Lf for mpls@megatron.ietf.org; Mon, 25 Apr 2005 18:24:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06016 for ; Mon, 25 Apr 2005 18:24:21 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQCCQ-0005gm-Cu for mpls@ietf.org; Mon, 25 Apr 2005 18:37:09 -0400 Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3PMO5411434 for ; Mon, 25 Apr 2005 18:24:05 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3PMNc001702 for ; Mon, 25 Apr 2005 18:23:39 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Apr 2005 18:23:38 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03193164@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'George Swallow'" Subject: RE: [mpls] Last Call on "LSP Ping" Date: Mon, 25 Apr 2005 18:23:30 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Not sure how to parse below... ? Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Monday, April 25, 2005 4:51 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: mpls@ietf.org; swallow@cisco.com > Subject: Re: [mpls] Last Call on "LSP Ping" > > > Dave - > > Actually, the text you cite should have been removed from > this draft. It went with the last set of processing rules. > It was pointed out that an implicit null could occur anywhere > in the stack, and the procedure make too bold an assumption. > So I rewrote the rules to cover the case. But I forgot to > remove the "preprocessing step". So thanks for pointing it > out (even if that wasn't quite your intention ;-). > > ...George > > ============================================================== > ========== > 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 Tue Apr 26 12:26:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQStd-0005Rk-U4; Tue, 26 Apr 2005 12:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQStc-0005Rb-Cn for mpls@megatron.ietf.org; Tue, 26 Apr 2005 12:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23298 for ; Tue, 26 Apr 2005 12:26:45 -0400 (EDT) Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQT65-0000nb-Cq for mpls@ietf.org; Tue, 26 Apr 2005 12:39:42 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3QGQb1l071187; Tue, 26 Apr 2005 09:26:37 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j3QGQZYx071184; Tue, 26 Apr 2005 09:26:35 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 26 Apr 2005 09:26:35 -0700 (PDT) From: Kireeti Kompella To: George Swallow Subject: Re: [mpls] Last Call on "LSP Ping" In-Reply-To: <20050425203610.D7D652BDD1C@swallow-mac.cisco.com> Message-ID: <20050426091124.T71105@kummer.juniper.net> References: <20050425203610.D7D652BDD1C@swallow-mac.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Mon, 25 Apr 2005, George Swallow wrote: > > This is one of the best written I-Ds for a long time! Thanks. > > Section 7 > > There are several specific codepoints defined in the draft and > > marked as "to be defined by IANA". These are specific values > > within the new name spaces defined in section 7. I think it would > > help IANA if you listed all of the defined values in a central > > place (perhaps with references to the defining sections). > > Good idea. Will include. Concur. Should also make sure that there are allocation policies for all the code point spaces (e.g., fields in Downstream Mapping TLV). > > Appendix A. > > I'm sure this one has been out and round the block several times. > > Notwithstanding that the appendix is non-normative, why is it included? I > > thought we were doing no new work (apart from drafts listed in RFC3468) > > related to CR-LDP. > > Is there anyone who objects to removing Appendix A? Not me. > > Section 3.5 > > The Error Code TLV > > I think no-one came up with a use for this. Since we try not to define > > things unless we have an actual use, perhaps this TLV should be retired. > > I'll leave it to Kireeti to defend as I also suggested taking it out. Take it out. > > And a silly question. > > > > Suppose I have an RSVP-TE LSP that starts on an IPv6 LSR and ends on an > > IPv4 LSR (or vice versa). > > So I have an IPv6 Sender Template and IPv4 Session (or vice versa). > > How do I encode the Target FEC Stack? > > Or perhaps this is just an unrealistic deployment? > > Hmmm. Good luck getting a notify message back! Not something I was > planning to support. When there is an actual deployment of this, we'll re-evaluate whether we need N*M RSVP-TE TLVs (N sender templates * M sessions) or N+M TLVs that the ping-er can mix-and-match. The two TLVs for IPv4+IPv4 and IPv6+IPv6 should cover 99.314% of the cases, so we'll leave those unperturbed. We can re-evaluate this sooner, when we get to the point where we're discussing the nuts-and-bolts of the p2mp RSVP-TE ping TLVs. Kireeti. ------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 28 09:44:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9JU-0007u6-UH; Thu, 28 Apr 2005 09:44:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9JS-0007r6-5E for mpls@megatron.ietf.org; Thu, 28 Apr 2005 09:44:18 -0400 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14979 for ; Thu, 28 Apr 2005 09:44:14 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 68so642355wri for ; Thu, 28 Apr 2005 06:43:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NzZd9QB9jfk73QeHtxHhaR0MdeoCv9UOb+RDciEzPYDXlqRQUdB2Nwfl4ztmdFRop5VhLBUpEigdazAX96ixZogWjy9kf2vrk29nfV84x+PiwKcXcM9vIpRQCexXLnBYUJyOJkHssZiiUm1XdXbu1l6cMG1UaKiFAjpPDM8GT/Y= Received: by 10.54.121.12 with SMTP id t12mr738890wrc; Thu, 28 Apr 2005 06:43:33 -0700 (PDT) Received: by 10.54.70.2 with HTTP; Thu, 28 Apr 2005 06:43:33 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2005 09:43:33 -0400 From: Rurick Kellermann To: mpls@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] test message - pls. ignore X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rurick Kellermann 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 mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Apr 28 11:45:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBCM-0000fM-JW; Thu, 28 Apr 2005 11:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQsbh-0001jm-Qw; Wed, 27 Apr 2005 15:54:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19156; Wed, 27 Apr 2005 15:54:00 -0400 (EDT) Message-Id: <200504271954.PAA19156@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 27 Apr 2005 15:53:59 -0400 X-Mailman-Approved-At: Thu, 28 Apr 2005 11:45:04 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lc-if-mib-05.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition Author(s) : T. Nadeau, S. Hegde Filename : draft-ietf-mpls-lc-if-mib-05.txt Pages : 20 Date : 2005-4-27 This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label switching controlled Frame-Relay and ATM interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lc-if-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-27160616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lc-if-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-27160616.I-D@ietf.org> --OtherAccess-- --NextPart 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-- From mpls-bounces@lists.ietf.org Thu Apr 28 11:45:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBCP-0000gN-3I; Thu, 28 Apr 2005 11:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQscF-0001qX-Bt; Wed, 27 Apr 2005 15:54:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19310; Wed, 27 Apr 2005 15:54:33 -0400 (EDT) Message-Id: <200504271954.PAA19310@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 27 Apr 2005 15:54:32 -0400 X-Mailman-Approved-At: Thu, 28 Apr 2005 11:45:04 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-02.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs Author(s) : S. Yasukawa Filename : draft-ietf-mpls-p2mp-sig-requirement-02.txt Pages : 29 Date : 2005-4-27 This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution specific details nor application specific requirements in this document. It is intended that the requirements presented in this document are not limited to the requirements of packet switched networks, but also encompass the requirements of Layer two Switching (L2SC), Time Division Multiplexing (TDM), lambda and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-p2mp-sig-requirement-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-27160624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-sig-requirement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-27160624.I-D@ietf.org> --OtherAccess-- --NextPart 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--