From mpls-bounces@ietf.org Wed Apr 2 00:01:44 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F363A6DDC; Wed, 2 Apr 2008 00:01:43 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE85E3A69D1 for ; Wed, 2 Apr 2008 00:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y69hhdhrRiUo for ; Wed, 2 Apr 2008 00:01:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B00E828C2F8 for ; Wed, 2 Apr 2008 00:01:40 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2008 00:01:41 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3271eH7031088; Wed, 2 Apr 2008 00:01:40 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3271e2o022581; Wed, 2 Apr 2008 07:01:40 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 03:01:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 03:01:39 -0400 Message-ID: In-Reply-To: <5A0FF108221C7C4E85738678804B567C05F92343@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt Thread-Index: AciOt90U0PeFnVFrRKeagc1XHaD+UwAc0cPwAVfDT1A= From: "Luyuan Fang (lufang)" To: , , X-OriginalArrivalTime: 02 Apr 2008 07:01:40.0478 (UTC) FILETIME=[66BA51E0:01C8948F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7669; t=1207119700; x=1207983700; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lufang@cisco.com; z=From:=20=22Luyuan=20Fang=20(lufang)=22=20 |Subject:=20RE=3A=20[mpls]=20wg=20last=20call=20on=20draft- ietf-mpls-ldp-igp-sync-01.txt |Sender:=20; bh=9KDAQE3t6sVLgVqw7ces0z8sNZ9JKYMHRHmaHWeSqp0=; b=aP+44Kxxu/d0QC/X4JJCgRZ9KAvzwVLmcrAiUYBkpzIcko97xiDBYLeAtr KrKgNx4EzR3iybhn3rDA9CwOfBIiGX6k1rmJ46zFZkri543dzIsWc1uO7crl XNF7m3V9gHrCGWnhsPEhNJadaH5tA5sliohiBMum9hGJSAxe9r/4k=; Authentication-Results: sj-dkim-1; header.From=lufang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Bruno, Thank you for the comments. Please see in-line. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of bruno.decraene@orange-ftgroup.com > Sent: 26 March 2008 13:08 > To: loa@pi.se; mpls@ietf.org > Subject: Re: [mpls] wg last call on > draft-ietf-mpls-ldp-igp-sync-01.txt > > Hi Markus, Alia, Luyuan, all, > > A few comments: > > 1) May be the document should talk about its interaction with > graceful restart. (I guess this document should not be used > when GR is used, unless GR is aborted or failed.). > Very good point. Let's try to look the relationship between LDP-IGP synch (LDP-IGP) and Graceful Restart (GR). In fact, LDP-IGP is also used when GR is used. There are LDP GR [RFC 3478] and IGP GR - OSPF GR [RFC 3623] and ISIS GR [RFC 3847]. A. LDP GR and LDP-IGP synch: LDP GR provides a mechanism to minimize the impact on MPLS labeled traffic caused by LSR's control plane restart. LDP GR is taking the proactive approach. LDP-IGP synch is reactive, it provides the exchange and synch action between LDP and IGP when LDP is already failed. It prevents router sending traffic to the path where IGP is up and LDP is down. There are many occasions you don't have a chance to gracefully restart. E.g. bring up a new link; operational error - missed to configure LDP; implementation error causes label corruption, etc. Both LDP GR and LDP-IGP synch provide labeled traffic protection under different conditions. B. IGP GR and LDP-IGP synch IGP GR or non-stop forwarding (NSF) is to keep IGP router stay on the forwarding path even as its IGP is restarted. An IGP instance performing NSF should honor the LDP-IGP synch procedure to check the LDP-IGP synch parameter on the standby routing device. IGP GR protects traffic during the switch over. LDP-IGP protects labeled traffic from being blackholed when LDP is faulty for some reason while IGP is still up. > > 2) " While the link could still be used for IP forwarding, it > is not useful for traffic with packets carrying a label stack > of more than one label or when the IP address carried in the > packet is out of the > RFC1918 space." > > It seems that the use of RFC 1918 IP address is just an > example. One could find others (eg BGP free core). > Proposition to change to " While the link could still be used > for IP forwarding, it is not useful for MPLS forwarding (e.g. > MPLS VPN, BGP free core.)" > Agreed. We can used both examples. How about we say "While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, e.g., MPLS VPN; BGP route free core; IP address carried in the packet is out of the RFC1918 space, etc."? > > 3) "The LDP protocol itself has currently no means to > indicate to a service depending on it whether there is an > uninterrupted label switched path available to the desired > destination or not." > > Eventually, it could be useful to say why LDP ordered mode + > FEC withdraw is not an existing mean. LDP is not a routing protocol. IGP directs the traffic to the shortest path regardless there is an established LSP along the path or not. Under the LDP down and IGP up condition: When LDP Ordered Control is used, the labeled packets drop happens at the LSR of the ingress of network as LSP cannot be established on the shortest path selected by IGP; When Independent Control is used, the labeled packets drop happens at the LSR where LDP failed (could be a mid point in the LSP) as the LSP is broken. We have seen both blackholing cases in live networks. For more details on LDP blackholing problems and solution, also see "LDP Failure Detection and Recovery", by L. Fang, A. Atlas, F. Chiussi, K. Kompella, and G. Swallow, IEEE Communications Vol.42 No.10, October 2004. > Or may be you want to say that LDP has currently no way to > correct the issue, for example by using a different IGP path. > Yes, thanks. We can re-word this similar as you suggested: LDP has currently no way to correct the issue. LDP is not a routing protocol, it cannot re-direct traffic to an alternate IGP path. > 4) "In the case of OSPF this cost is LSInfinity (16-bit value > 0xFFFF) as proposed in [RFC3137]." > > Could you also indicate the metric to use for IS-IS? > Especially since: > - further in the doc you recommend that all implementation > use the same metric to avoid asymmetric link cost > - RFC 3784 seems to indicate that the max metric link (2^24 - > 1) is already reserved > Very good point. We shall add the ISIS max metric in the draft. The max metric value for ISIS using wide metrics is 0xFFFFFE per RFC 3784. > 5) "It is recommended that both sides of a link implement > this mechanism to be effective and to avoid asymmetric link > costs which could cause problems with IP multicast forwarding." > > Avoiding asymetric link cost during all the procedure would > require that both routers sharing the LDP session have the > same way to detect when "LDP is considered fully > operational". This is currently not the case. Understood. It is a recommendation for better performance, not a requirement. > As the document propose to wait "some time", the document > could possibly propose a default value for this timer and > warn that if the operator wish to change that value, it > should change it on both side of the LDP session. > We prefer not to set the hold-down timer with a default value. The reason is that the LIB tables size can vary largely, as well the equipment capability/speed. If the default value is too small, this function would not work; if it is too big, it slows down the convergence time. But the hold-down time guidelines through equipment testing would be helpful. LDP End-of-LIB (draft-asati-mpls-ldp-end-of-lib-01.txt) is currently a work in progress. When End-of-LIB is implemented, it can signal the end of IGP hold-down time, no longer need for the configured nor default timers. > Also, as there is a risk of transient asymetric link cost > (because the end of the procedure is not stricly defined) > could you possibly provide more precision on the problems > that could be faced by IP multicast? > Yes, transient asymmetric cost is always a risk, it is not just for this problem, it is rather a common problem. e.g. it is same as in BGP. We would treat it as out of scope for this draft. > Thanks, > Regards, > Bruno > Thanks, Luyuan > > From Loa Andersson > > > > Working group, > > > > this is to initiate a two week working group last call on: > > > > draft-ietf-mpls-ldp-igp-sync-01.txt > > > > Please send your comments to the working group mailing list > or to the > > working group chairs before April 11. > > > > 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@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 01:03:40 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D83C3A6A8D; Wed, 2 Apr 2008 01:03:39 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FA43A6831 for ; Wed, 2 Apr 2008 01:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnrGmcj6Fokv for ; Wed, 2 Apr 2008 01:03:28 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 7025C28C0FF for ; Wed, 2 Apr 2008 01:03:27 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3283RSN004379 for ; Wed, 2 Apr 2008 04:03:27 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3283RTf082764 for ; Wed, 2 Apr 2008 04:03:27 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3283QSn011768 for ; Wed, 2 Apr 2008 04:03:27 -0400 Received: from d01ml263.pok.ibm.com (d01ml263.pok.ibm.com [9.56.227.113]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3283QD8011762 for ; Wed, 2 Apr 2008 04:03:26 -0400 From: Andrew Veitch To: mpls@ietf.org Message-ID: Date: Wed, 2 Apr 2008 04:03:25 -0400 X-MIMETrack: Serialize by Router on D01ML263/01/M/IBM(Release 7.0.2FP2HF300 | September 14, 2007) at 04/02/2008 04:03:26 MIME-Version: 1.0 Subject: [mpls] Veitch, Andrew is out of the office. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org I will be out of the office starting 03/31/2008 and will not return until 04/07/2008. I will respond to your message when I return. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 03:36:39 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7698B28C4DE; Wed, 2 Apr 2008 03:36:39 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD3528C4B4 for ; Wed, 2 Apr 2008 03:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.906 X-Spam-Level: *** X-Spam-Status: No, score=3.906 tagged_above=-999 required=5 tests=[AWL=2.795, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_39=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ZScWaGzkRN for ; Wed, 2 Apr 2008 03:36:36 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by core3.amsl.com (Postfix) with ESMTP id 81EE128C4CD for ; Wed, 2 Apr 2008 03:36:36 -0700 (PDT) Received: from mlsv17.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 8BFF133CD5 for ; Wed, 2 Apr 2008 19:36:36 +0900 (JST) Received: from mfilter-s5.hitachi.co.jp by mlsv17.hitachi.co.jp (8.13.1/8.13.1) id m32Aaaau024064; Wed, 2 Apr 2008 19:36:36 +0900 Received: from vshuts3.hitachi.co.jp (unverified) by mfilter-s5.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 2 Apr 2008 19:36:36 +0900 Received: from vshuts3.hitachi.co.jp (unknown [127.0.0.1]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 2545A3925EA for ; Wed, 2 Apr 2008 19:36:36 +0900 (JST) X-AuditID: 0ac90648-ab975ba0000017b2-1c-47f361b4da65 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 053813925F2 for ; Wed, 2 Apr 2008 19:36:36 +0900 (JST) Received: from P4090 by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id m32AaZC11518184; Wed, 2 Apr 2008 19:36:35 +0900 Message-ID: <012101c894ad$99198a20$2204d69e@P4090> From: "Masayuki Takase" To: Date: Wed, 2 Apr 2008 19:37:46 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== Subject: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Loa, Hitachi has implemented Transport Switch chips that support MPLS OAM using the Label 14. Therefore we disagree to the modification of the existing RFC3429 document. So we also suggest using a different label for the new function. Regards, ----------------------------------- Masayuki Takase Hitachi, Communication Technologies, Ltd. 216 Totsuka-cho, Totsuka-ku, Yokohama-shi 244-8567, Japan Tel: +81-45-865-7003(Ext.4094) Email:masayuki.takase.vx@hitachi.com ----- Original Message ----- > Hi Loa, > > Yes we have implemented the Label 14 in our packet processor/switch chips > as > requested by our customers. So we suggest using a different label for the > new function. > > > Regards, > > Shahram Davari | Director, Systems Engineering > T|PACK| 9 King's Inn Trail | Markham | Ontario L3T 1T6| Canada > Direct: +1 905 597 3125 | Mobile: +1 416 371 3139 | Email: > davari at tpack.com > www.tpack.com > > TPACK CONFIDENTIAL > Note: This message and any attachment hereto is intended solely for the > use > of the designated recipient(s) and their appointed delegates and may > contain > confidential information. Any unauthorized use, disclosure, copying, or > distribution of its contents is strictly prohibited. If you have received > this message in error, please destroy it and advise the sender immediately > by phone or email Thank you for your cooperation. > > > > > -----Original Message----- > From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On > Behalf Of > Loa Andersson > Sent: March-28-08 4:50 AM > To: mpls at ietf.org; pwe3; l3vpn at ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 > > All, > > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. > > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. > > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. > > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. > > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. > > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" > > ITU-T has sent out a question along the same lines, see the included > mail below. > > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. > > Loa and George > > > ------------------- included mail ------------------------------------ > > All users/implementers of recommendation Y.1711, > > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. > > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. > > This makes the OAM alert label directly visible at the > sink MEP. > > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. > > The OAM alert label will point to an ?opcode? at the bottom > of the stack. > ------------------------------------------ > > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. > > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? > > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). > > Please send me (or this list) your response ASAP. > > Kind regards, Huub van Helvoort, your rapporteur. > > -- > 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 at acreo.se > loa at pi.se > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 05:32:14 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6253A6F00; Wed, 2 Apr 2008 05:32:14 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE283A6F00 for ; Wed, 2 Apr 2008 05:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPPyMQeTMKEf for ; Wed, 2 Apr 2008 05:32:12 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by core3.amsl.com (Postfix) with ESMTP id 945DB3A6C10 for ; Wed, 2 Apr 2008 05:32:08 -0700 (PDT) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id CC1CDE463B; Wed, 2 Apr 2008 08:32:08 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 02 Apr 2008 08:32:08 -0400 X-Sasl-enc: fmm2N5Z5UNLhb+qXkBjX2P7pzNf8/YfzZKjZAeOFqAFt 1207139528 Received: from mood.vph.iki.fi (a91-154-107-25.elisa-laajakaista.fi [91.154.107.25]) by mail.messagingengine.com (Postfix) with ESMTPSA id 02CA3134C0; Wed, 2 Apr 2008 08:32:08 -0400 (EDT) Received: from vph by mood.vph.iki.fi with local (Exim 4.63) (envelope-from ) id 1Jh28M-0006os-E0; Wed, 02 Apr 2008 15:32:06 +0300 Date: Wed, 2 Apr 2008 15:32:06 +0300 From: Ville Hallivuori To: Loa Andersson Message-ID: <20080402123206.GA25746@mood.vph.iki.fi> Mail-Followup-To: Loa Andersson , mpls@ietf.org, Ross Callon , David Ward References: <47ECB132.7090200@pi.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47ECB132.7090200@pi.se> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Ross Callon , mpls@ietf.org, David Ward Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vph@iki.fi List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Tellabs has implementation of Y.1711. Current Y.1373 seems to be sufficiently backward-compatible to Y.1711 to make it preferable to use label 14 for it. We (Tellabs) would rather see that EXP and TTL fields would not be mis-used (as current Y.1373 mis-uses them for MEL and for filtering packets in MIPs). However if mis-use of these fields is insisted, changing label value brings no additional advantages over using label 14. As long as Y.1373 and Y.1711 packets can be differentiated and Y.1373 frames retain sufficient backward-compatibility (as is the case with current specification), we prefer label 14. However Y.1373 specification should more clearly state the backward-compatibility with Y.1711. On Fri, Mar 28, 2008 at 09:49:54AM +0100, Loa Andersson wrote: > All, > > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. > > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. > > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. > > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. > > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. > > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" > > ITU-T has sent out a question along the same lines, see the included > mail below. > > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. > > Loa and George > > > ------------------- included mail ------------------------------------ > > All users/implementers of recommendation Y.1711, > > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. > > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. > > This makes the OAM alert label directly visible at the > sink MEP. > > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. > > The OAM alert label will point to an ?opcode? at the bottom > of the stack. > ------------------------------------------ > > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. > > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? > > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). > > Please send me (or this list) your response ASAP. > > Kind regards, Huub van Helvoort, your rapporteur. > > -- > 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@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- [Ville Hallivuori][vph@iki.fi][http://www.iki.fi/vph/] [ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62 5D 87 47 9D 3F 2B 07 5D] [ID 58543419][FP20=8731 941D 15AB D4A0 88A0 FC8F B55C F4C4 5854 3419] [ID 8061C24E][FP20=C722 12DA 841E D811 DBFE 2FB3 174C E291 8061 C24E] _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 06:53:14 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1473A6F27; Wed, 2 Apr 2008 06:53:14 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA92528C57A for ; Wed, 2 Apr 2008 06:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKo7E-Z+bw6m for ; Wed, 2 Apr 2008 06:53:02 -0700 (PDT) Received: from lucidvision.com (static-72-71-250-34.cncdnh.fios.verizon.net [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id DBB0D3A69E2 for ; Wed, 2 Apr 2008 06:50:22 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id B63792C89B5; Wed, 2 Apr 2008 06:50:23 -0700 (PDT) From: Thomas Nadeau To: "Masayuki Takase" In-Reply-To: <012101c894ad$99198a20$2204d69e@P4090> X-Priority: 3 References: <012101c894ad$99198a20$2204d69e@P4090> Message-Id: <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 09:50:17 -0400 X-Mailer: Apple Mail (2.919.2) Cc: mpls@ietf.org Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org How could you have built MPLS OAM to support label 14? Do you mean you implemented Y1711 using label 14? --Tom On Apr 2, 2008, at 6:37 AM, Masayuki Takase wrote: > Hi Loa, > > Hitachi has implemented Transport Switch chips that support MPLS OAM > using > the Label 14. Therefore we disagree to the modification of the > existing > RFC3429 document. > So we also suggest using a different label for the new function. > > Regards, > ----------------------------------- > Masayuki Takase > Hitachi, Communication Technologies, Ltd. > 216 Totsuka-cho, Totsuka-ku, > Yokohama-shi 244-8567, Japan > Tel: +81-45-865-7003(Ext.4094) > Email:masayuki.takase.vx@hitachi.com > > ----- Original Message ----- >> Hi Loa, >> >> Yes we have implemented the Label 14 in our packet processor/switch >> chips >> as >> requested by our customers. So we suggest using a different label >> for the >> new function. >> >> >> Regards, >> >> Shahram Davari | Director, Systems Engineering >> T|PACK| 9 King's Inn Trail | Markham | Ontario L3T 1T6| Canada >> Direct: +1 905 597 3125 | Mobile: +1 416 371 3139 | Email: >> davari at tpack.com >> www.tpack.com >> >> TPACK CONFIDENTIAL >> Note: This message and any attachment hereto is intended solely for >> the >> use >> of the designated recipient(s) and their appointed delegates and may >> contain >> confidential information. Any unauthorized use, disclosure, >> copying, or >> distribution of its contents is strictly prohibited. If you have >> received >> this message in error, please destroy it and advise the sender >> immediately >> by phone or email Thank you for your cooperation. >> >> >> >> >> -----Original Message----- >> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On >> Behalf Of >> Loa Andersson >> Sent: March-28-08 4:50 AM >> To: mpls at ietf.org; pwe3; l3vpn at ietf.org; L2VPN; ccamp >> Cc: Ross Callon; David Ward >> Subject: Question on the status of Y.1711 and RFC3429 >> >> All, >> >> In the discussions the IETF and the ITU-T have had on T-MPLS we have >> discussed the intended use for label 14 and the different documents >> where this has been specified. >> >> As a side effect we've also started to ask ourselves if there are any >> implementations and/or deployments that uses label 14. >> >> A quick survey among known implementers of MPLS has not shown any >> implementations/deployments. >> >> Since one of the approaches discussed in the Joint Working Team >> context is a solution that requires the allocation of a reserved >> label and reserved labels are a scarce resource we'd like to know >> if it possible to redefine label 14 for that particular use. >> >> There are still technical issues to be sorted out with the suggested >> approach, but in the mean time we would like to know if it is >> possible >> to deprecate RFC3429 and redefine the OAM Alert Label. >> >> The questions is: "Are there any implementations/deployments of Y. >> 1711 >> or the OAM Alert label as it is allocated in RFC3429; and is there >> objection to deprecating the protocol as it stands today?" >> >> ITU-T has sent out a question along the same lines, see the included >> mail below. >> >> Please respond to the mpls working group mailing list or to the mpls >> working chairs directly. As usual non-responses will be counted as >> that there is no implementation/deployment. >> >> Loa and George >> >> >> ------------------- included mail >> ------------------------------------ >> >> All users/implementers of recommendation Y.1711, >> >> Currently the Joint Working Team of ITU-T and IETF experts is >> considering the options of using IETF mechanisms to provide >> OAM for T-MPLS. >> >> One possibility is the following mechanism: >> ------------------------------------------- >> Push/pop a label at the MEP/domain boundary. >> >> This makes the OAM alert label directly visible at the >> sink MEP. >> >> To make the OAM label visible to a MIP the TTL in the server >> (lower) layer is set by the MEP to expire when the OAM frame >> reaches the intended MIP. >> >> The OAM alert label will point to an ?opcode? at the bottom >> of the stack. >> ------------------------------------------ >> >> This behaviour (when the OAM alert label is received) is not >> consistent with the behaviour currently defined in Y.1711 when >> label 14 is received. >> >> *QUESTION* are there any users/implementers of the current Y.1711 >> concerned with this change in behaviour? >> >> If there are no concerns then recommendation Y.1711 can be >> withdrawn or revised to describe the desired behaviour (described >> above). >> >> Please send me (or this list) your response ASAP. >> >> Kind regards, Huub van Helvoort, your rapporteur. >> >> -- >> 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 at acreo.se >> loa at pi.se >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 08:09:14 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E883A6DB0; Wed, 2 Apr 2008 08:09:14 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F313A6D35 for ; Wed, 2 Apr 2008 08:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSLzhZnefKge for ; Wed, 2 Apr 2008 08:09:13 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 0B50C3A6C24 for ; Wed, 2 Apr 2008 08:09:13 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k40so3748236wah.25 for ; Wed, 02 Apr 2008 08:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AIND1b4n0sgdxxEIKUSVo9CBJsaRaIxKCvRCOMPB+nc=; b=b+kgl8CmzIi7/nnHWjRYFajTtW0BucJsCRJPrSPutRktL+4s8k6YznLRc2X/ZMbJ/UMd5cgFg/IRcriDf2KwXAXcfSVyyBd0ImPTHq2l7O7DgCRvpRDoPsrWOyReTTxPiDwKOBl1OY1Pb/CpjAEWtv9ZzTXw5TL/iSlKre9b3ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YQTsxLqfhLu7rQy2E6UPX5UiYJ86yl7DAmtk//GEIGuG1sGC0T8qn/to8n60RKnsbQGBrgFWEHZr889b/PF6AYcLqI8lNoGyur2cP0xTamRKfJzSCaEPRyWXl9+4iz5dOWKrL2KLV2mK6GL2hGEBC+bd/BN0m5sMvHwOhJO6Xsw= Received: by 10.114.156.1 with SMTP id d1mr14955225wae.120.1207148953691; Wed, 02 Apr 2008 08:09:13 -0700 (PDT) Received: by 10.114.39.14 with HTTP; Wed, 2 Apr 2008 08:09:13 -0700 (PDT) Message-ID: <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> Date: Wed, 2 Apr 2008 17:09:13 +0200 From: "Francesco Fondelli" To: "Thomas Nadeau" In-Reply-To: <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> MIME-Version: 1.0 Content-Disposition: inline References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> Cc: mpls@ietf.org, Masayuki Takase Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau wrote: > > How could you have built MPLS OAM to support label 14? Do you mean > you implemented Y1711 using label 14? > > --Tom Back in 2002/2003/2004? there used to be no 'T-' :-) http://www.itu.int/rec/T-REC-Y.1711/en "Y.1711: Operation & Maintenance mechanism for MPLS networks" Clear, isn't it? //I'm sarcastic Ciao FF _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 11:06:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D923A699A; Wed, 2 Apr 2008 11:06:03 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24DC28C1C5; Mon, 31 Mar 2008 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvVSrjwX95hv; Mon, 31 Mar 2008 11:24:42 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id C7A7128C13B; Mon, 31 Mar 2008 11:24:41 -0700 (PDT) Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 31 Mar 2008 21:24:37 +0300 id 00067D06.47F12C65.00007099 Date: Mon, 31 Mar 2008 21:24:36 +0300 (EEST) From: Jukka MJ Manner To: Magnus Westerlund In-Reply-To: <47F0EAB0.8090504@ericsson.com> Message-ID: References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com> <47F0EAB0.8090504@ericsson.com> Mime-Version: 1.0 X-Mailman-Approved-At: Wed, 02 Apr 2008 11:06:01 -0700 Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg Subject: Re: [mpls] [Tsvwg] WG last call for draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi, I have read the draft, and think it is a reasonable proposal, and presented well. I have just a few minor comments/clarification requests: - What is exactly meant by "it is RECOMMENDED that organizations use a published scheme for this string to promote consistent decoding."? Could you add an example, perhaps? - Is it possible to not include the Error Description? If so, this could be said explicitly. - Is it possible to not include User-defined subobjects? If so, this could be said explicitly. These latter two comments are about making the user error propagation a bit simpler, e.g., one could primarily use the extended number space to define new error values, but leave in some cases the description and subobjects out to save bytes. Regards, Jukka On Mon, 31 Mar 2008, Magnus Westerlund wrote: > Hi, > > Version 04 is now available. I am still waiting for at least one more review > before requesting publication. > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-04.txt > > Cheers > > Magnus > > Magnus Westerlund skrev: > > Hi, > > > > This WG last call has now timed out. However, as there has not been a single > > comment it will continue until we actually get at least 3 reviewers stating > > that they have read it and find it ready to progress. > > > > Cheers > > > > Magnus > > > > Magnus Westerlund skrev: > > > This announces a WG last call for "User-Defined Errors for RSVP" to be > > > published as proposed standard. Please provide any comments by March 7. > > > (Yes, you get an extra week due to the just before the meeting time of > > > this last call). > > > > > > CCAMP and MPLS WG participants, please provide your comments to TSVWG. > > > > > > You can find the draft here: > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-03.txt > > > > > > > > > Regards > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > ---------------------------------------------------------------------- > > > Multimedia Technologies, Ericsson Research EAB/TVM > > > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 11:06:05 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D623C28C5C5; Wed, 2 Apr 2008 11:06:04 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9B828C0F5; Mon, 31 Mar 2008 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4yWkoC8GBUV; Mon, 31 Mar 2008 23:18:38 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 04F7A28C10C; Mon, 31 Mar 2008 23:18:37 -0700 (PDT) Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 01 Apr 2008 09:18:34 +0300 id 00067DEA.47F1D3BA.000010B0 Date: Tue, 1 Apr 2008 09:18:34 +0300 (EEST) From: Jukka MJ Manner To: Adrian Farrel In-Reply-To: <025201c89378$f29f1690$0300a8c0@your029b8cecfe> Message-ID: References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com><47F0EAB0.8090504@ericsson.com> <025201c89378$f29f1690$0300a8c0@your029b8cecfe> Mime-Version: 1.0 X-Mailman-Approved-At: Wed, 02 Apr 2008 11:06:01 -0700 Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg Subject: Re: [mpls] [Tsvwg] WG last callfor draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi, Sounds very good to me. Sorry that I missed that "MAY" for the suboptions. :) Cheers, Jukka On Mon, 31 Mar 2008, Adrian Farrel wrote: > Hi Jukka, > > > I have read the draft, and think it is a reasonable proposal, and > > presented well. I have just a few minor comments/clarification requests: > > > > - What is exactly meant by "it is RECOMMENDED that organizations use a > > published scheme for this string to promote consistent decoding."? Could > > you add an example, perhaps? > > Ah. Probably over-enthusiastic text created when we added the Error > Description string before this became a WG I-D. > > What we meant was that it might be helpful to a device that is going to a user > that is going to read this string if they knew that a string coming from a > device made by vendor X should be interpreted in a particular way. For > example, date stamp, IP address, error string. > > However, looking at this again, I would be happy to strike this text. > > > - Is it possible to not include the Error Description? If so, this could > > be said explicitly. > > Yes, the length can be set to zero, in which case there are no bytes of > description string. > > I can clarify this. > > > - Is it possible to not include User-defined subobjects? If so, this could > > be said explicitly. > > We already have: > User-defined subobjects MAY be included. > > I think that is sufficiently explicit that it is possible to not include them. > > > These latter two comments are about making the user error propagation a > > bit simpler, e.g., one could primarily use the extended number space to > > define new error values, but leave in some cases the description and > > subobjects out to save bytes. > > Agreed, and that is our intention. > > Does that work for you? > > Adrian > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 12:15:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0ED228C696; Wed, 2 Apr 2008 12:15:04 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6131228C679; Wed, 2 Apr 2008 12:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080402191502.6131228C679@core3.amsl.com> Date: Wed, 2 Apr 2008 12:15:02 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Component Link Recording and Resource Control for TE Link Bundles Author(s) : A. Zamfir Filename : draft-ietf-mpls-explicit-resource-control-bundle-03.txt Pages : 12 Date : 2008-4-2 Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-resource-control-bundle-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-explicit-resource-control-bundle-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-2121012.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Wed Apr 2 15:15:47 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62493A695B; Wed, 2 Apr 2008 15:15:47 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDD928C13F for ; Wed, 2 Apr 2008 15:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iejgc0f7y83M for ; Wed, 2 Apr 2008 15:15:44 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 310973A6865 for ; Wed, 2 Apr 2008 15:15:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m32MFcBL021202 for ; Wed, 2 Apr 2008 23:15:40 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m32MFaMn021192 for ; Wed, 2 Apr 2008 23:15:37 +0100 Message-ID: <006001c8950f$12bbba40$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <20080402191502.6131228C679@core3.amsl.com> Date: Wed, 2 Apr 2008 23:15:31 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Anca, Interesting to see this draft back again. I think it expired in April 2007 and I had assumed we had given up on it. A couple of thoughts... === In the terminology section you have: For unnumbered component links, the component link ID is assumed to be unique on an advertising node. I think this reflects exactly what was discussed several IETFs ago (possibly in CCAMP with respect to the hierarchy-bis draft or maybe draft-ietf-ccamp-gmpls-addressing-03). However, don't you need to have some RFC 2119 language here? Failing this assumption will break your draft, so this is a "MUST" in which case I suggest you move it from the Terminology section to the main body of the draft. === More generally, way back in March 2006, in Dallas, CCAMP discussed how to build EROs and RROs in order to qualify this in draft-ietf-ccamp-gmpls-addressing (now RFC 4990). We had a survey and published the results in http://www.watersprings.org/pub/id/draft-farrel-ccamp-ero-survey-00.txt. The conclusion seemed to be that implementations of bundling simply reported (and signaled) component links by including two sequential interface IDs, the first indicating the TE link and the second the component link. There was no need to use different subobject types for these two pieces of information as their ordering and context was sufficient. I recall that in the discussions it was even suggested that it was not necessary to include both the TE link ID and the component link ID as the component link ID actually has global scope even if it does not have global visibility. But the survey seemed to indicate that people wanted to "play safe" and include both identifiers. === Part of the question may hinge on the U-bit that you have defined for your new suobjects. This bit allows different component links to be used in each direction. Have we had a thorough discussion of this requirement? Last time I talked to people about this, it seemed to be the case that, just as we would not split a bidirectional LSP across separate TE links in each direction, we would not split an LSP across separate component links in each direction. After all, component links are just TE links that are bundled for advertisement. It was suggested that component links might be unidirectional components of a bidirectional bundle. But surely, just as with TE links, unidirectional data channels are paired to form bidirectional data links. I note, however, that RFC 4990 decided to allow different component links to be used in each direction with some (rather unclear) suggestion that ordering the subobjects is enough to allow you to determine the direction. === So, we come to the big question. Why do we need to change existing implementations and introduce a different way of encoding EROs and RROs for bundled links? Cheers, Adrian PS. I think that introducing a flag "component link recording desired" is a great idea. ----- Original Message ----- From: To: Cc: Sent: Wednesday, April 02, 2008 8:15 PM Subject: [mpls] I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : Component Link Recording and Resource Control for TE Link Bundles > Author(s) : A. Zamfir > Filename : draft-ietf-mpls-explicit-resource-control-bundle-03.txt > Pages : 12 > Date : 2008-4-2 > > Record Route is a useful administrative tool that has been used > extensively by the service providers. However, when TE links are > bundled, identification of label resource in Record Route Object > (RRO) is not enough for the administrative purpose. Network service > providers would like to know the component link within a TE link that > is being used by a given LSP. In other words, when link bundling is > used, resource recording requires mechanisms to specify the component > link identifier, along with the TE link identifier and Label. As it > is not possible to record component link in the RRO, this draft > defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify > component link identifiers for resource recording purposes. > > This draft also defines the Explicit Route Object (ERO) counterpart > of the RRO extension. The ERO extensions are needed to perform > explicit label/ resource control over bundled TE link. Hence, this > document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to > specify component link identifiers for explicit resource control and > recording over TE link bundles. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-resource-control-bundle-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 2 16:32:45 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C6328C13F; Wed, 2 Apr 2008 16:32:45 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2833A69C0 for ; Wed, 2 Apr 2008 16:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy5SGarPPaK2 for ; Wed, 2 Apr 2008 16:32:43 -0700 (PDT) Received: from lucidvision.com (static-72-71-250-34.cncdnh.fios.verizon.net [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 852CA28C13F for ; Wed, 2 Apr 2008 16:32:43 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 4CECC2C9988; Wed, 2 Apr 2008 16:32:47 -0700 (PDT) Message-Id: <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> From: Thomas Nadeau To: "Francesco Fondelli" In-Reply-To: <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 19:32:45 -0400 References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: mpls@ietf.org, Masayuki Takase Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org ITU recommendation Y1711 has nothing to do with MPLS OAM. If you want a good overview of IETF MPLS OAM take a look at RFC4221. --Tom On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: > On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau > wrote: >> >> How could you have built MPLS OAM to support label 14? Do >> you mean >> you implemented Y1711 using label 14? >> >> --Tom > > Back in 2002/2003/2004? there used to be no 'T-' :-) > > http://www.itu.int/rec/T-REC-Y.1711/en > > "Y.1711: Operation & Maintenance mechanism for MPLS networks" > > Clear, isn't it? //I'm sarcastic > > Ciao > FF > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 03:19:50 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004C028C5A9; Thu, 3 Apr 2008 03:19:50 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3C028C5A9 for ; Thu, 3 Apr 2008 03:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7TWcfOtlk0O for ; Thu, 3 Apr 2008 03:19:48 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id CCD4728C569 for ; Thu, 3 Apr 2008 03:19:47 -0700 (PDT) Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:19:49 +0100 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.114]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Apr 2008 10:19:47 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 03 Apr 2008 11:19:47 +0100 From: Ben Niven-Jenkins To: Message-ID: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciVdD4PAO+PgbtlHESq3Q3ULisygA== In-Reply-To: <20080402133015.U40977@kummer.juniper.net> Mime-version: 1.0 X-OriginalArrivalTime: 03 Apr 2008 10:19:49.0481 (UTC) FILETIME=[3F89F590:01C89574] Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org I support this draft becoming a working group document. I will send some comments on the draft in a separate e-mail. Ben > Working Group, > > the authors of > > Mechanism for performing LSP-Ping over MPLS tunnels > > > have requested that this draft is made a working group > document. > > Please send your comments/opinions (both positve and negative) > to the working group mailing list, or directly to the working > group chairs before April 11. > > Loa and George _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 03:25:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4634528C5DD; Thu, 3 Apr 2008 03:25:03 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9519628C62D for ; Thu, 3 Apr 2008 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nudaa6lDsWiV for ; Thu, 3 Apr 2008 03:23:08 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7F73328C5B0 for ; Thu, 3 Apr 2008 03:22:45 -0700 (PDT) Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:22:48 +0100 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.114]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Apr 2008 10:22:47 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 03 Apr 2008 11:22:47 +0100 From: Ben Niven-Jenkins To: "mpls@ietf.org" Message-ID: Thread-Topic: Comments on draft-nitinb-lsp-ping-over-mpls-tunnel-01 Thread-Index: AciVdKlZtABt4yjg+kqTFkLP+zWs5Q== Mime-version: 1.0 X-OriginalArrivalTime: 03 Apr 2008 10:22:48.0393 (UTC) FILETIME=[AA2DC390:01C89574] Subject: [mpls] Comments on draft-nitinb-lsp-ping-over-mpls-tunnel-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Some comments of draft-nitinb-lsp-ping-over-mpls-tunnel-01 General: Section 3.2.3: Operation Type "A FEC Swap operation is to be simulated by including a POP type FEC change sub-TLV followed by a PUSH type FEC change sub-TLV." During the ITU-T SG15 ad hoc meeting on T-MPLS in February, the ITU model (G.8110) of MPLS was discussed. G.8110 models a SWAP as a POP followed by a PUSH and at least one of the IETF representatives at the meeting expressed the view that modelling a SWAP as a POP followed by a PUSH did not sufficiently describe the behaviour as per the MPLS architecture (RFC3031). You appear to be doing the same here, so is modelling a SWAP as a POP followed by a PUSH sufficient in this context? Remote peer address "If the operation type is POP, the remote peer address MAY not be set to Unspecified." I find the use of the term "MAY not" confusing. If you really mean MAY then as it is optional, IMO the not is superfluous. Editorial: Section 1 S/using which/by which/ Section 3.1 S/tlv/TLV/ Section 3.2 S/sub-tlv/sub-TLV/ Section 3.3 S/deprecatd/deprecated/ S/tlv/TLV/ Section 4.1.1 S/when that the/when the/ Section 4.1.2 S/one for the PUSH operation/one with a PUSH operation/ S/FEC-tlv/FEC TLV/ S/Push/PUSH/ Section 4.3 S/In cases where the a detailed/In cases where a detailed/ S/tlv/TLV/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 04:38:37 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A44428C66A; Thu, 3 Apr 2008 04:38:37 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98FE28C149; Thu, 3 Apr 2008 04:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fceOgAdv8viz; Thu, 3 Apr 2008 04:38:30 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 27D5528C614; Thu, 3 Apr 2008 04:38:28 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 03 Apr 2008 15:17:37 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 14:38:31 +0300 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.263.0; Thu, 3 Apr 2008 14:38:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 14:38:30 +0300 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> In-Reply-To: <47ECB132.7090200@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on the status of Y.1711 and RFC3429 Thread-Index: AciQsMzOn/guAnfHTHCRQvl2K2wxvAEzhEzw References: <47ECB132.7090200@pi.se> From: Alexander Vainshtein To: "Loa Andersson" , , X-OriginalArrivalTime: 03 Apr 2008 11:38:31.0350 (UTC) FILETIME=[3DFDFD60:01C8957F] Cc: L2VPN , l3vpn@ietf.org, ccamp , pwe3 , David Ward , Ross Callon Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Loa, George and all, ECI Telecom has implemented ITU-T recommendation Y.1711 using Label 14 as defined in RFC 3429 in its XDM (TM) products family. The corresponding products have been deployed in live networks, and their Y.1711-related functionality is now in operational use. Based on this, we (ECI) object to deprecation of the Label 14 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] > On Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 11:50 AM > To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 > > All, > > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. > > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. > > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. > > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. > > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. > > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" > > ITU-T has sent out a question along the same lines, see the included > mail below. > > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. > > Loa and George > > > ------------------- included mail ------------------------------------ > > All users/implementers of recommendation Y.1711, > > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. > > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. > > This makes the OAM alert label directly visible at the > sink MEP. > > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. > > The OAM alert label will point to an "opcode" at the bottom > of the stack. > ------------------------------------------ > > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. > > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? > > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). > > Please send me (or this list) your response ASAP. > > Kind regards, Huub van Helvoort, your rapporteur. > > -- > 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 05:11:32 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BF528C635; Thu, 3 Apr 2008 05:11:31 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314C628C696 for ; Thu, 3 Apr 2008 05:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.718 X-Spam-Level: X-Spam-Status: No, score=-101.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6cYbib6KWqH for ; Thu, 3 Apr 2008 05:11:23 -0700 (PDT) Received: from smtp110.rog.mail.re2.yahoo.com (smtp110.rog.mail.re2.yahoo.com [206.190.37.0]) by core3.amsl.com (Postfix) with SMTP id 0C6AA3A6F80 for ; Thu, 3 Apr 2008 05:10:21 -0700 (PDT) Received: (qmail 59676 invoked from network); 3 Apr 2008 12:10:24 -0000 Received: from unknown (HELO ShahramPC) (davari@rogers.com@99.238.119.231 with login) by smtp110.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2008 12:10:23 -0000 X-YMail-OSG: T_fNTr4VM1lXdfsR_n1OmAfD4yaC.M6q84nhtsAjdrNatb2T3fONFeVSYRgDRW69hw-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: "'Thomas Nadeau'" , "'Francesco Fondelli'" References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> In-Reply-To: <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> Date: Thu, 3 Apr 2008 08:10:21 -0400 Message-ID: <001201c89583$b2b57530$18205f90$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciVGiYKzyvaRC3iQxOS6VUVA7CWXgAaFoVg Content-Language: en-ca Cc: mpls@ietf.org, 'Masayuki Takase' Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Tom, Could you please provide your definition of MPLS OAM? I have been involved in MPLS and OAM for more than 10 years and my understanding is that Y.1711 is the first MPLS OAM defined in the industry. -Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: April-02-08 7:33 PM To: Francesco Fondelli Cc: mpls@ietf.org; Masayuki Takase Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 ITU recommendation Y1711 has nothing to do with MPLS OAM. If you want a good overview of IETF MPLS OAM take a look at RFC4221. --Tom On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: > On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau > wrote: >> >> How could you have built MPLS OAM to support label 14? Do >> you mean >> you implemented Y1711 using label 14? >> >> --Tom > > Back in 2002/2003/2004? there used to be no 'T-' :-) > > http://www.itu.int/rec/T-REC-Y.1711/en > > "Y.1711: Operation & Maintenance mechanism for MPLS networks" > > Clear, isn't it? //I'm sarcastic > > Ciao > FF > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 05:15:55 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5063528C6AD; Thu, 3 Apr 2008 05:15:55 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE83128C695 for ; Thu, 3 Apr 2008 05:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzY0X8Pnkzub for ; Thu, 3 Apr 2008 05:15:49 -0700 (PDT) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id 3959128C6AD for ; Thu, 3 Apr 2008 05:15:46 -0700 (PDT) Received: (qmail 92569 invoked from network); 3 Apr 2008 12:15:49 -0000 Received: from unknown (HELO ShahramPC) (davari@rogers.com@99.238.119.231 with login) by smtp113.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2008 12:15:48 -0000 X-YMail-OSG: hhGjG10VM1kOm_OkMcCxHUZifwfG1XXhUPAA4Bh55BdkAYGxvi1X1eejm9jQYfKoKg-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: "'Loa Andersson'" , , References: <47ECB132.7090200@pi.se> <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> Date: Thu, 3 Apr 2008 08:15:47 -0400 Message-ID: <001301c89584$7402a050$5c07e0f0$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQsMzOn/guAnfHTHCRQvl2K2wxvAEzhEzwAAE/PFA= Content-Language: en-ca Cc: 'L2VPN' , 'ccamp' , 'pwe3' , l3vpn@ietf.org, 'David Ward' Subject: Re: [mpls] [PWE3] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Loa, George and all, TPACK has implemented Y.1711 using label 14 and TPACK's customers have reported Y.1711 has been deployed and in operation by the network operators using their products. Therefore TPACK objects to deprecation of the Label 14 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Shahram Davari TPACK -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: April-03-08 7:39 AM To: Loa Andersson; swallow@cisco.com; mpls@ietf.org Cc: L2VPN; l3vpn@ietf.org; ccamp; pwe3; David Ward Subject: Re: [PWE3] Question on the status of Y.1711 and RFC3429 Loa, George and all, ECI Telecom has implemented ITU-T recommendation Y.1711 using Label 14 as defined in RFC 3429 in its XDM (TM) products family. The corresponding products have been deployed in live networks, and their Y.1711-related functionality is now in operational use. Based on this, we (ECI) object to deprecation of the Label 14 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] > On Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 11:50 AM > To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 > > All, > > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. > > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. > > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. > > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. > > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. > > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" > > ITU-T has sent out a question along the same lines, see the included > mail below. > > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. > > Loa and George > > > ------------------- included mail ------------------------------------ > > All users/implementers of recommendation Y.1711, > > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. > > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. > > This makes the OAM alert label directly visible at the > sink MEP. > > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. > > The OAM alert label will point to an "opcode" at the bottom > of the stack. > ------------------------------------------ > > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. > > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? > > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). > > Please send me (or this list) your response ASAP. > > Kind regards, Huub van Helvoort, your rapporteur. > > -- > 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 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 06:33:16 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498843A6CFB; Thu, 3 Apr 2008 06:33:16 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495113A6BC5 for ; Thu, 3 Apr 2008 06:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSyB0a2bliEd for ; Thu, 3 Apr 2008 06:33:09 -0700 (PDT) Received: from lucidvision.com (static-72-71-250-34.cncdnh.fios.verizon.net [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 270503A6C9B for ; Thu, 3 Apr 2008 06:33:04 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 87C1D2CAE9D; Thu, 3 Apr 2008 06:33:11 -0700 (PDT) Message-Id: <6AF8BFB3-2894-46A8-97B7-3F926ACF2775@lucidvision.com> From: Thomas Nadeau To: "Shahram Davari" In-Reply-To: <001201c89583$b2b57530$18205f90$@org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 09:33:07 -0400 References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> <001201c89583$b2b57530$18205f90$@org> X-Mailer: Apple Mail (2.919.2) Cc: mpls@ietf.org, 'Masayuki Takase' Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Sharam, Lets please not play your normal games around this. We all know what you are getting at here, and I have little time or patience to play that useless game again... --Tom > Tom, > > Could you please provide your definition of MPLS OAM? I have been > involved > in MPLS and OAM for more than 10 years and my understanding is that > Y.1711 > is the first MPLS OAM defined in the industry. > > -Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > Thomas Nadeau > Sent: April-02-08 7:33 PM > To: Francesco Fondelli > Cc: mpls@ietf.org; Masayuki Takase > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > ITU recommendation Y1711 has nothing to do with MPLS OAM. If you > want a > good overview of IETF MPLS OAM take a look at RFC4221. > > --Tom > > > > On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: >> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau >> wrote: >>> >>> How could you have built MPLS OAM to support label 14? Do >>> you mean >>> you implemented Y1711 using label 14? >>> >>> --Tom >> >> Back in 2002/2003/2004? there used to be no 'T-' :-) >> >> http://www.itu.int/rec/T-REC-Y.1711/en >> >> "Y.1711: Operation & Maintenance mechanism for MPLS networks" >> >> Clear, isn't it? //I'm sarcastic >> >> Ciao >> FF >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 06:48:22 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9DD28C5B4; Thu, 3 Apr 2008 06:48:22 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE73128C44D for ; Thu, 3 Apr 2008 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4yuSJ3cW3mY for ; Thu, 3 Apr 2008 06:48:19 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by core3.amsl.com (Postfix) with ESMTP id 9C24728C22D for ; Thu, 3 Apr 2008 06:48:19 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so3727918wxd.31 for ; Thu, 03 Apr 2008 06:48:22 -0700 (PDT) Received: by 10.70.72.11 with SMTP id u11mr12779497wxa.39.1207230502380; Thu, 03 Apr 2008 06:48:22 -0700 (PDT) Received: from ?192.168.1.100? ( [71.131.17.87]) by mx.google.com with ESMTPS id h14sm4037539wxd.26.2008.04.03.06.48.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Apr 2008 06:48:21 -0700 (PDT) Message-ID: <47F4E022.4050405@pingpan.org> Date: Thu, 03 Apr 2008 06:48:18 -0700 From: Ping Pan User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Shahram Davari References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> <001201c89583$b2b57530$18205f90$@org> In-Reply-To: <001201c89583$b2b57530$18205f90$@org> Cc: 'Masayuki Takase' , mpls@ietf.org Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Have to bite: Y.1711 may be the first to be defined, but LSP-ping was the first to get deployed and used to solve real problems. So the age, the complexity and the brand name sometimes do not matter much. Why do we try this? (Maybe we have already). Let's lay out - the problems that Y.1711 have solved where the existing mechanisms defined in IETF won't be able to address, and - how serious those problems are. Then let's move from there. - Ping Shahram Davari wrote: > Tom, > > Could you please provide your definition of MPLS OAM? I have been involved > in MPLS and OAM for more than 10 years and my understanding is that Y.1711 > is the first MPLS OAM defined in the industry. > > -Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Thomas Nadeau > Sent: April-02-08 7:33 PM > To: Francesco Fondelli > Cc: mpls@ietf.org; Masayuki Takase > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > ITU recommendation Y1711 has nothing to do with MPLS OAM. If you > want a > good overview of IETF MPLS OAM take a look at RFC4221. > > --Tom > > > > On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: >> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau >> wrote: >>> How could you have built MPLS OAM to support label 14? Do >>> you mean >>> you implemented Y1711 using label 14? >>> >>> --Tom >> Back in 2002/2003/2004? there used to be no 'T-' :-) >> >> http://www.itu.int/rec/T-REC-Y.1711/en >> >> "Y.1711: Operation & Maintenance mechanism for MPLS networks" >> >> Clear, isn't it? //I'm sarcastic >> >> Ciao >> FF >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 07:07:28 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF50D28C6B1; Thu, 3 Apr 2008 07:07:27 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9648928C5F1 for ; Thu, 3 Apr 2008 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.856 X-Spam-Level: X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAvdlFJRYlqj for ; Thu, 3 Apr 2008 07:07:20 -0700 (PDT) Received: from smtp114.rog.mail.re2.yahoo.com (smtp114.rog.mail.re2.yahoo.com [68.142.225.230]) by core3.amsl.com (Postfix) with SMTP id 9C6EB28C6A9 for ; Thu, 3 Apr 2008 07:05:25 -0700 (PDT) Received: (qmail 93589 invoked from network); 3 Apr 2008 14:05:28 -0000 Received: from unknown (HELO ShahramPC) (davari@rogers.com@99.238.119.231 with login) by smtp114.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2008 14:05:28 -0000 X-YMail-OSG: Td4EvhoVM1k7KlOtpSo40ERurx30BxEfyRPNrm0D_t_QYdMqhEVo8GUnKnugv5cCsQ-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: "'Ping Pan'" References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> <001201c89583$b2b57530$18205f90$@org> <47F4E022.4050405@pingpan.org> In-Reply-To: <47F4E022.4050405@pingpan.org> Date: Thu, 3 Apr 2008 10:05:27 -0400 Message-ID: <002301c89593$c5b8e8a0$512ab9e0$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciVkZCr379Ta+IlQcObH5voGABXVgAAeRMA Content-Language: en-ca Cc: mpls@ietf.org, 'Masayuki Takase' Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Ping, My email was not about your invention (LSP-ping). I in fact like LSP-ping and think it is useful. I was just answering Tom's claim that "Y.1711 has nothing to do with MPLS OAM". Shahram . -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ping Pan Sent: April-03-08 9:48 AM To: Shahram Davari Cc: 'Masayuki Takase'; mpls@ietf.org Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 Have to bite: Y.1711 may be the first to be defined, but LSP-ping was the first to get deployed and used to solve real problems. So the age, the complexity and the brand name sometimes do not matter much. Why do we try this? (Maybe we have already). Let's lay out - the problems that Y.1711 have solved where the existing mechanisms defined in IETF won't be able to address, and - how serious those problems are. Then let's move from there. - Ping Shahram Davari wrote: > Tom, > > Could you please provide your definition of MPLS OAM? I have been involved > in MPLS and OAM for more than 10 years and my understanding is that Y.1711 > is the first MPLS OAM defined in the industry. > > -Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Thomas Nadeau > Sent: April-02-08 7:33 PM > To: Francesco Fondelli > Cc: mpls@ietf.org; Masayuki Takase > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > ITU recommendation Y1711 has nothing to do with MPLS OAM. If you > want a > good overview of IETF MPLS OAM take a look at RFC4221. > > --Tom > > > > On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: >> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau >> wrote: >>> How could you have built MPLS OAM to support label 14? Do >>> you mean >>> you implemented Y1711 using label 14? >>> >>> --Tom >> Back in 2002/2003/2004? there used to be no 'T-' :-) >> >> http://www.itu.int/rec/T-REC-Y.1711/en >> >> "Y.1711: Operation & Maintenance mechanism for MPLS networks" >> >> Clear, isn't it? //I'm sarcastic >> >> Ciao >> FF >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 07:08:02 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4628528C6DC; Thu, 3 Apr 2008 07:08:02 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF92C28C6DB for ; Thu, 3 Apr 2008 07:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MlmUXeFaOr9 for ; Thu, 3 Apr 2008 07:07:58 -0700 (PDT) Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by core3.amsl.com (Postfix) with SMTP id D32FA28C6C2 for ; Thu, 3 Apr 2008 07:07:54 -0700 (PDT) Received: (qmail 80857 invoked from network); 3 Apr 2008 14:07:57 -0000 Received: from unknown (HELO ShahramPC) (davari@rogers.com@99.238.119.231 with login) by smtp109.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2008 14:07:57 -0000 X-YMail-OSG: rMSAxYgVM1liIXALTaz9X_1oh4XxqQb5Ve5aoPd8MUkfKD46k1GNdW8iZuQ3x0rKug-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: "'Thomas Nadeau'" References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> <001201c89583$b2b57530$18205f90$@org> <6AF8BFB3-2894-46A8-97B7-3F926ACF2775@lucidvision.com> In-Reply-To: <6AF8BFB3-2894-46A8-97B7-3F926ACF2775@lucidvision.com> Date: Thu, 3 Apr 2008 10:07:57 -0400 Message-ID: <002401c89594$1eccdd20$5c669760$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciVkqg30CPXOSWFRdaVLX2C39Dc7wAAR51w Content-Language: en-ca Cc: mpls@ietf.org, 'Masayuki Takase' Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Tom, I think you should keep your personal problems with ITU to yourself. I was not playing any games. I was just trying to understand your strange comments that Y.1711 has nothing to do with MPLS OAM. Shahram -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: April-03-08 9:33 AM To: Shahram Davari Cc: 'Francesco Fondelli'; mpls@ietf.org; 'Masayuki Takase' Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 Sharam, Lets please not play your normal games around this. We all know what you are getting at here, and I have little time or patience to play that useless game again... --Tom > Tom, > > Could you please provide your definition of MPLS OAM? I have been > involved > in MPLS and OAM for more than 10 years and my understanding is that > Y.1711 > is the first MPLS OAM defined in the industry. > > -Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > Thomas Nadeau > Sent: April-02-08 7:33 PM > To: Francesco Fondelli > Cc: mpls@ietf.org; Masayuki Takase > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > ITU recommendation Y1711 has nothing to do with MPLS OAM. If you > want a > good overview of IETF MPLS OAM take a look at RFC4221. > > --Tom > > > > On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: >> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau >> wrote: >>> >>> How could you have built MPLS OAM to support label 14? Do >>> you mean >>> you implemented Y1711 using label 14? >>> >>> --Tom >> >> Back in 2002/2003/2004? there used to be no 'T-' :-) >> >> http://www.itu.int/rec/T-REC-Y.1711/en >> >> "Y.1711: Operation & Maintenance mechanism for MPLS networks" >> >> Clear, isn't it? //I'm sarcastic >> >> Ciao >> FF >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 07:46:08 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A5928C226; Thu, 3 Apr 2008 07:46:08 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDC73A6A3E for ; Thu, 3 Apr 2008 07:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdqjHfNEIQz2 for ; Thu, 3 Apr 2008 07:46:01 -0700 (PDT) Received: from lucidvision.com (static-72-71-250-34.cncdnh.fios.verizon.net [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id BE1673A6B42 for ; Thu, 3 Apr 2008 07:46:01 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 849C32CB163; Thu, 3 Apr 2008 07:46:09 -0700 (PDT) Message-Id: <34D5C27C-D69A-4236-9327-BA4B4835DB66@lucidvision.com> From: Thomas Nadeau To: Shahram Davari In-Reply-To: <002401c89594$1eccdd20$5c669760$@org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 10:46:04 -0400 References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com> <5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com> <001201c89583$b2b57530$18205f90$@org> <6AF8BFB3-2894-46A8-97B7-3F926ACF2775@lucidvision.com> <002401c89594$1eccdd20$5c669760$@org> X-Mailer: Apple Mail (2.919.2) Cc: mpls@ietf.org, 'Masayuki Takase' Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > Tom, > > I think you should keep your personal problems with ITU to yourself. Thanks for the advice. I may keep this in mind for the future. > I was not playing any games. > I was just trying to understand your strange comments > that Y.1711 has nothing to do with MPLS OAM. Back to my original point: Y.1711 is not IETF "MPLS OAM", which what the original question was about. --Tom > Shahram > > > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: April-03-08 9:33 AM > To: Shahram Davari > Cc: 'Francesco Fondelli'; mpls@ietf.org; 'Masayuki Takase' > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > Sharam, > > Lets please not play your normal games around this. We all know what > > you are getting > at here, and I have little time or patience to play that useless game > again... > > --Tom > > > >> Tom, >> >> Could you please provide your definition of MPLS OAM? I have been >> involved >> in MPLS and OAM for more than 10 years and my understanding is that >> Y.1711 >> is the first MPLS OAM defined in the industry. >> >> -Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >> Thomas Nadeau >> Sent: April-02-08 7:33 PM >> To: Francesco Fondelli >> Cc: mpls@ietf.org; Masayuki Takase >> Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 >> >> >> ITU recommendation Y1711 has nothing to do with MPLS OAM. If you >> want a >> good overview of IETF MPLS OAM take a look at RFC4221. >> >> --Tom >> >> >> >> On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: >>> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau >>> wrote: >>>> >>>> How could you have built MPLS OAM to support label 14? Do >>>> you mean >>>> you implemented Y1711 using label 14? >>>> >>>> --Tom >>> >>> Back in 2002/2003/2004? there used to be no 'T-' :-) >>> >>> http://www.itu.int/rec/T-REC-Y.1711/en >>> >>> "Y.1711: Operation & Maintenance mechanism for MPLS networks" >>> >>> Clear, isn't it? //I'm sarcastic >>> >>> Ciao >>> FF >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 07:52:37 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38F928C6D3; Thu, 3 Apr 2008 07:52:37 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E4728C6D3 for ; Thu, 3 Apr 2008 07:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIwNHV46vPcE for ; Thu, 3 Apr 2008 07:52:35 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 83C7A28C6C5 for ; Thu, 3 Apr 2008 07:52:35 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 15:52:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 15:49:44 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0233C8BE@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <47F4E022.4050405@pingpan.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question on the status of Y.1711 and RFC3429 Thread-Index: AciVkW5jwGdqHRaWSRa8ljYow3BjzQABIXqA From: To: , X-OriginalArrivalTime: 03 Apr 2008 14:52:37.0756 (UTC) FILETIME=[5BCA83C0:01C8959A] Cc: mpls@ietf.org, masayuki.takase.vx@hitachi.com Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Ping....to be clear here (given I was largely responsible for Y.1711): - Y.1711 (and before it the requirements given in Y.1710) was based on trying to define a generic OAM solution for any correctly specified co-ps mode layer network technology....the key principle underpinning it was to 'keep things as simple as possible'. - If one breaks the architectural rules of what defines a connection (eg must have single source) then there are no good/simple OAM solutions. Or more accurately, one cannot assign/manage resource in a co-ps technology that breaks the rules of a connection. BTW - One cannot break this rule in the co-cs mode. - The type of MPLS based on LDP creates merging mp2p constructs (so does PHP on a last hop). These are not connections. - LSP ping took something like 5-6 years and 13 or so iterations....simple it is not. The use of ECMP also greatly complicates matters. - The OAM required to detect/handle defects in a properly architected co-ps or co-cs mode layer network should be unidirectional (and not of a request/response nature) for many reasons.....co-ps/cs mode OAM is not like cl-ps mode OAM because connections create constraining constructs under normal operation. So, having defined LDP (and PHP + ECMP) then Y.1711 is no good for this type of MPLS....but this is not the fault of Y.1711 of course. regards, Neil > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Ping Pan > Sent: 03 April 2008 14:48 > To: Shahram Davari > Cc: 'Masayuki Takase'; mpls@ietf.org > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > Have to bite: > > Y.1711 may be the first to be defined, but LSP-ping was the > first to get > deployed and used to solve real problems. So the age, the > complexity and > the brand name sometimes do not matter much. > > Why do we try this? (Maybe we have already). Let's lay out > > - the problems that Y.1711 have solved where the existing mechanisms > defined in IETF won't be able to address, and > > - how serious those problems are. > > Then let's move from there. > > - Ping > > > Shahram Davari wrote: > > Tom, > > > > Could you please provide your definition of MPLS OAM? I have been > > involved in MPLS and OAM for more than 10 years and my > understanding > > is that Y.1711 is the first MPLS OAM defined in the industry. > > > > -Shahram > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Thomas Nadeau > > Sent: April-02-08 7:33 PM > > To: Francesco Fondelli > > Cc: mpls@ietf.org; Masayuki Takase > > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > > > > ITU recommendation Y1711 has nothing to do with MPLS > OAM. If you > > want a > > good overview of IETF MPLS OAM take a look at RFC4221. > > > > --Tom > > > > > > > > On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: > >> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau > >> wrote: > >>> How could you have built MPLS OAM to support label 14? Do > >>> you mean > >>> you implemented Y1711 using label 14? > >>> > >>> --Tom > >> Back in 2002/2003/2004? there used to be no 'T-' :-) > >> > >> http://www.itu.int/rec/T-REC-Y.1711/en > >> > >> "Y.1711: Operation & Maintenance mechanism for MPLS networks" > >> > >> Clear, isn't it? //I'm sarcastic > >> > >> Ciao > >> FF > >> > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 09:21:49 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA9728C6E4; Thu, 3 Apr 2008 09:21:49 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D095D3A6CFC for ; Thu, 3 Apr 2008 09:21:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-XpRokgoQJD for ; Thu, 3 Apr 2008 09:21:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 28E893A6C2E for ; Thu, 3 Apr 2008 09:21:41 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2008 09:21:45 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m33GLiQv013050; Thu, 3 Apr 2008 09:21:45 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m33GLW3m024630; Thu, 3 Apr 2008 16:21:44 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 12:21:44 -0400 Received: from swallow-mini-mac.cisco.com ([10.86.116.2]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 12:21:43 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.cisco.com (Postfix) with ESMTP id D9EC558D5B0; Thu, 3 Apr 2008 12:21:42 -0400 (EDT) To: Ben Niven-Jenkins In-reply-to: Your message of "Thu, 03 Apr 2008 11:19:47 BST." From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.2; GNU Emacs 21.2.1 Date: Thu, 03 Apr 2008 12:21:42 -0400 Message-Id: <20080403162142.D9EC558D5B0@swallow-mini-mac.cisco.com> X-OriginalArrivalTime: 03 Apr 2008 16:21:43.0653 (UTC) FILETIME=[CE31A950:01C895A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=276; t=1207239705; x=1208103705; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:=20George=20Swallow=20 |Subject:=20Re=3A=20[mpls]=20draft-nitinb-lsp-ping-over-mpl s-tunnel-01=20for=20wg=20document=20 |Sender:=20; bh=n8FSJMhGsfEw0jfA8l2D6gQ+YA72J1IlrbkOnaxyMfE=; b=jYhYjyJrrJ9jIz0u8IAIk3MPb7Y89GiAVo1ygL9KZCgswq5aoLVteHanU/ mp5/Us3Qo6hvmi6WkDq+pglG9ANpMHZwy45V+WrrdqOw1+ulmSWeizoiHSlH gw7qGkmgar; Authentication-Results: sj-dkim-4; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mpls@ietf.org Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Support. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 09:33:10 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C708328C6BB; Thu, 3 Apr 2008 09:33:10 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B0428C6AD for ; Thu, 3 Apr 2008 09:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPJN-2Icwy66 for ; Thu, 3 Apr 2008 09:33:03 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 3F9653A6CC7 for ; Thu, 3 Apr 2008 09:33:03 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m33GQW1u001952; Thu, 3 Apr 2008 18:26:32 +0200 Received: from itvimn0i34082 ([151.98.70.19]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 18:32:31 +0200 From: "Italo Busi" To: "'Thomas Nadeau'" , "'Shahram Davari'" References: <012101c894ad$99198a20$2204d69e@P4090> <87F66FE4-36B3-4E17-8F5D-E2A716F838D3@lucidvision.com> <7c923b5e0804020809s616bf33fwd459bc816e53ddd8@mail.gmail.com><5E38A14E-B191-4FC0-A6E1-3CF34712D45D@lucidvision.com><001201c89583$b2b57530$18205f90$@org> <6AF8BFB3-2894-46A8-97B7-3F926ACF2775@lucidvision.com> Date: Thu, 3 Apr 2008 18:33:03 +0200 Message-ID: <006401c895a8$63cddfa0$13466297@vim.tlt.alcatel.it> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6AF8BFB3-2894-46A8-97B7-3F926ACF2775@lucidvision.com> Thread-Index: AciVj1ud37Spr2NHQq2XETXSXePMLgAGFHbg X-OriginalArrivalTime: 03 Apr 2008 16:32:31.0680 (UTC) FILETIME=[5072BC00:01C895A8] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls@ietf.org, Malcolm Betts , 'Masayuki Takase' , Dave Ward Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Tom, I am feeling very unconfortable with the way this discussion is progressing. There was a reasonable request coming from the chair to investigate whether there are implementations and/or deployment of RFC3429 and Y.1711. Most of the people are fairly reporting the status of their implementations/deployments. I do not see why comparing Y.1711 against LSP Ping fits into this thread. In addition I fail to understand the value of arguing against an approved ITU-T Recommendation (i.e. Y.1711) recognized by IETF (i.e. RFC3429) expecially now that ITU-T and IETF are improving the collaboration among themselves. Italo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Thomas Nadeau > Sent: Thursday, April 03, 2008 3:33 PM > To: Shahram Davari > Cc: mpls@ietf.org; 'Masayuki Takase' > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > Sharam, > > Lets please not play your normal games around this. We > all know what > you are getting > at here, and I have little time or patience to play that > useless game > again... > > --Tom > > > > > Tom, > > > > Could you please provide your definition of MPLS OAM? I have been > > involved > > in MPLS and OAM for more than 10 years and my understanding > is that > > Y.1711 > > is the first MPLS OAM defined in the industry. > > > > -Shahram > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of > > Thomas Nadeau > > Sent: April-02-08 7:33 PM > > To: Francesco Fondelli > > Cc: mpls@ietf.org; Masayuki Takase > > Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 > > > > > > ITU recommendation Y1711 has nothing to do with MPLS > OAM. If you > > want a > > good overview of IETF MPLS OAM take a look at RFC4221. > > > > --Tom > > > > > > > > On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: > >> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau > >> wrote: > >>> > >>> How could you have built MPLS OAM to support label 14? Do > >>> you mean > >>> you implemented Y1711 using label 14? > >>> > >>> --Tom > >> > >> Back in 2002/2003/2004? there used to be no 'T-' :-) > >> > >> http://www.itu.int/rec/T-REC-Y.1711/en > >> > >> "Y.1711: Operation & Maintenance mechanism for MPLS networks" > >> > >> Clear, isn't it? //I'm sarcastic > >> > >> Ciao > >> FF > >> > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 10:24:20 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6434B28C6D7; Thu, 3 Apr 2008 10:24:20 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D58028C628 for ; Thu, 3 Apr 2008 10:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxreYrujp8R3 for ; Thu, 3 Apr 2008 10:24:18 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.187]) by core3.amsl.com (Postfix) with ESMTP id 2D78128C6D3 for ; Thu, 3 Apr 2008 10:24:18 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id a46so2560380rne.9 for ; Thu, 03 Apr 2008 10:24:21 -0700 (PDT) Received: by 10.114.57.1 with SMTP id f1mr145837waa.78.1207243460929; Thu, 03 Apr 2008 10:24:20 -0700 (PDT) Received: from ?192.168.110.106? ( [65.113.43.30]) by mx.google.com with ESMTPS id j26sm7266745waf.49.2008.04.03.10.24.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Apr 2008 10:24:19 -0700 (PDT) Message-ID: <47F512C1.5060309@pingpan.org> Date: Thu, 03 Apr 2008 10:24:17 -0700 From: Ping Pan User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org References: <20080403162142.D9EC558D5B0@swallow-mini-mac.cisco.com> In-Reply-To: <20080403162142.D9EC558D5B0@swallow-mini-mac.cisco.com> Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Support - Ping _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 10:37:01 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A8728C140; Thu, 3 Apr 2008 10:37:01 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0583A687D for ; Thu, 3 Apr 2008 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UITnHdcMUktw for ; Thu, 3 Apr 2008 10:36:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 67D9628C3AD for ; Thu, 3 Apr 2008 10:35:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,599,1199682000"; d="scan'208";a="4009327" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2008 13:35:19 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m33HZJsc009862 for ; Thu, 3 Apr 2008 13:35:19 -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.13.8/8.13.8) with ESMTP id m33HZJtt020236 for ; Thu, 3 Apr 2008 17:35:19 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 13:35:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 13:35:18 -0400 Message-ID: In-Reply-To: <47F512C1.5060309@pingpan.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciVr6St2jeZmzHqTnSolxapL6s6GAAAT7Sg From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 03 Apr 2008 17:35:19.0076 (UTC) FILETIME=[15FDBE40:01C895B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18; t=1207244119; x=1208108119; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lufang@cisco.com; z=From:=20=22Luyuan=20Fang=20(lufang)=22=20 |Subject:=20RE=3A=20[mpls]=20draft-nitinb-lsp-ping-over-mpl s-tunnel-01=20for=20wg=20document |Sender:=20 |To:=20; bh=i8rStW0CdrpHDswqFfPLlAFFrsNXGXAFoN7Jrft2QX0=; b=OMpGMHaAmWJi8iMmCBWJX48uCreMVYaeE5Mfh5U0cMwSD3BorvpbPeYUs9 I67Cfzte81hjKPYC0x1CUIVEJHz/iAy6RXCzWU47zsx83bf6uZjUi1jdQMN6 j5K/SsuPUa; Authentication-Results: rtp-dkim-1; header.From=lufang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Support. Luyuan _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 10:52:34 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7534C3A6AA4; Thu, 3 Apr 2008 10:52:34 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676873A6AA4 for ; Thu, 3 Apr 2008 10:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W941-kt+YCz for ; Thu, 3 Apr 2008 10:52:31 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by core3.amsl.com (Postfix) with ESMTP id 44C993A6874 for ; Thu, 3 Apr 2008 10:52:31 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id r23so1610352elf.18 for ; Thu, 03 Apr 2008 10:52:34 -0700 (PDT) Received: by 10.114.152.17 with SMTP id z17mr160461wad.128.1207245154181; Thu, 03 Apr 2008 10:52:34 -0700 (PDT) Received: from ?192.168.110.106? ( [65.113.43.30]) by mx.google.com with ESMTPS id m31sm7356441wag.28.2008.04.03.10.52.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Apr 2008 10:52:31 -0700 (PDT) Message-ID: <47F5195D.8040109@pingpan.org> Date: Thu, 03 Apr 2008 10:52:29 -0700 From: Ping Pan User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <2ECAA42C79676B42AEBAC11229CA7D0C0233C8BE@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0233C8BE@E03MVB2-UKBR.domain1.systemhost.net> Cc: davari@ieee.org, mpls@ietf.org, masayuki.takase.vx@hitachi.com Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Neil, First, I think you have made some very good observation. In fact, I agree with you on the point where, if a connection is no longer p2p, OAM would be tough to deal with. You have brought up ECMP. As some of us have discussed in private, the reality could be worse. In case of ECMP, we at least know there may be multiple routes within a segment of the connection. If we consider Ethernet Link Aggregation (LAG), the packets may go over different physical links without the knowledgeable of upper layer OAM protocols. However, this is not the fault of MPLS. MPLS is the mechanism to forward packets over the connections defined by routing and underlying physical topology. To deal with this kind of complex scenarios, one tool is not enough! This is where a combination of LSP-ping, BFD and OAM interworking techniques could help us solving the problem. If we find new problems, let's put fixes into the defined and deployed mechanisms. As I have mentioned before, let's put all the problems on the table for discussion. Simply pushing standard may not be the best way to solve problems. Does it make sense? Regards, - Ping neil.2.harrison@bt.com wrote: > Ping....to be clear here (given I was largely responsible for Y.1711): > > - Y.1711 (and before it the requirements given in Y.1710) was > based on trying to define a generic OAM solution for any correctly > specified co-ps mode layer network technology....the key principle > underpinning it was to 'keep things as simple as possible'. > > - If one breaks the architectural rules of what defines a > connection (eg must have single source) then there are no good/simple > OAM solutions. Or more accurately, one cannot assign/manage resource in > a co-ps technology that breaks the rules of a connection. BTW - One > cannot break this rule in the co-cs mode. > > - The type of MPLS based on LDP creates merging mp2p constructs > (so does PHP on a last hop). These are not connections. > > - LSP ping took something like 5-6 years and 13 or so > iterations....simple it is not. The use of ECMP also greatly > complicates matters. > > - The OAM required to detect/handle defects in a properly > architected co-ps or co-cs mode layer network should be unidirectional > (and not of a request/response nature) for many reasons.....co-ps/cs > mode OAM is not like cl-ps mode OAM because connections create > constraining constructs under normal operation. > > So, having defined LDP (and PHP + ECMP) then Y.1711 is no good for this > type of MPLS....but this is not the fault of Y.1711 of course. > > regards, Neil > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Ping Pan >> Sent: 03 April 2008 14:48 >> To: Shahram Davari >> Cc: 'Masayuki Takase'; mpls@ietf.org >> Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 >> >> >> Have to bite: >> >> Y.1711 may be the first to be defined, but LSP-ping was the >> first to get >> deployed and used to solve real problems. So the age, the >> complexity and >> the brand name sometimes do not matter much. >> >> Why do we try this? (Maybe we have already). Let's lay out >> >> - the problems that Y.1711 have solved where the existing mechanisms >> defined in IETF won't be able to address, and >> >> - how serious those problems are. >> >> Then let's move from there. >> >> - Ping >> >> >> Shahram Davari wrote: >>> Tom, >>> >>> Could you please provide your definition of MPLS OAM? I have been >>> involved in MPLS and OAM for more than 10 years and my >> understanding >>> is that Y.1711 is the first MPLS OAM defined in the industry. >>> >>> -Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On Behalf >>> Of Thomas Nadeau >>> Sent: April-02-08 7:33 PM >>> To: Francesco Fondelli >>> Cc: mpls@ietf.org; Masayuki Takase >>> Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429 >>> >>> >>> ITU recommendation Y1711 has nothing to do with MPLS >> OAM. If you >>> want a >>> good overview of IETF MPLS OAM take a look at RFC4221. >>> >>> --Tom >>> >>> >>> >>> On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote: >>>> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau >>>> wrote: >>>>> How could you have built MPLS OAM to support label 14? Do >>>>> you mean >>>>> you implemented Y1711 using label 14? >>>>> >>>>> --Tom >>>> Back in 2002/2003/2004? there used to be no 'T-' :-) >>>> >>>> http://www.itu.int/rec/T-REC-Y.1711/en >>>> >>>> "Y.1711: Operation & Maintenance mechanism for MPLS networks" >>>> >>>> Clear, isn't it? //I'm sarcastic >>>> >>>> Ciao >>>> FF >>>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 10:53:14 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19BE23A6F88; Thu, 3 Apr 2008 10:53:14 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858693A6F87 for ; Thu, 3 Apr 2008 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x+UWmyBapVH for ; Thu, 3 Apr 2008 10:53:11 -0700 (PDT) Received: from audl952.usa.alcatel.com (audl952.usa.alcatel.com [143.209.238.159]) by core3.amsl.com (Postfix) with ESMTP id 50A573A6F99 for ; Thu, 3 Apr 2008 10:53:10 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id m33HrCBl006581; Thu, 3 Apr 2008 11:53:12 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.11]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 12:53:12 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 3 Apr 2008 12:53:11 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191E08@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <47ECDABA.3000104@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciQyZ/SlU3iPWcUSXaOHW9e4590PwE6O7Ng References: <47ECDABA.3000104@pi.se> From: "AISSAOUI Mustapha" To: "Loa Andersson" , X-OriginalArrivalTime: 03 Apr 2008 17:53:12.0090 (UTC) FILETIME=[958EAFA0:01C895B3] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: Ross Callon , David Ward Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, I provided my comments on this list to the authors of this draft back in January. My main issue is that a FEC Swap is different from FEC tunneling and that the use of the FEC Stack Change Sub-TLV is not warranted. A reply with the Target FEC stack TLV is sufficient. My proposal to the authors was to make the FEC Stack Change Sub-TLV optional and to limit its use to indicate the FEC being traced is entering or exiting a tunnel or tunnels. I support the draft if its scope is restricted to this. Mustapha. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 7:47 AM > To: mpls@ietf.org > Cc: Ross Callon; David Ward > Subject: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for > wg document > > Working Group, > > the authors of > > Mechanism for performing LSP-Ping over MPLS tunnels > > > have requested that this draft is made a working group document. > > Please send your comments/opinions (both positve and > negative) to the working group mailing list, or directly to > the working group chairs before April 11. > > 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@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 10:57:51 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5568F28C2A1; Thu, 3 Apr 2008 10:57:51 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA6B28C1E5 for ; Thu, 3 Apr 2008 10:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH-7wVrr5IBm for ; Thu, 3 Apr 2008 10:57:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C5AEB28C18B for ; Thu, 3 Apr 2008 10:57:48 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2008 10:57:52 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m33HvqVZ018216; Thu, 3 Apr 2008 10:57:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m33Hvnw6023488; Thu, 3 Apr 2008 17:57:52 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 13:57:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 13:57:58 -0400 Message-ID: In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191E08@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciQyZ/SlU3iPWcUSXaOHW9e4590PwE6O7NgAABogtA= References: <47ECDABA.3000104@pi.se> <4A5028372622294A99B8FFF6BD06EB7B04191E08@USDALSMBS03.ad3.ad.alcatel.com> From: "Zafar Ali (zali)" To: "AISSAOUI Mustapha" , "Loa Andersson" , X-OriginalArrivalTime: 03 Apr 2008 17:57:52.0011 (UTC) FILETIME=[3C673DB0:01C895B4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1464; t=1207245472; x=1208109472; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20[mpls]=20draft-nitinb-lsp-ping-over-mpl s-tunnel-01=20for=20wg=20document |Sender:=20; bh=PRF2X3/fHAAl+m71NiYtNLkw2rIe2YcJQe4tDJYkM5M=; b=rkRQpy+4cYrw2gtEWKUM5eKTq7WF5G1Y19abfykDQKN5rdL2jg0LAQzrSi 19PYTkOihG88n8Ep5uPBpzfxEF3NYn9XdpnQsjuWyyu3HJux/tddi45U60wc PaNq1iIf4F; Authentication-Results: sj-dkim-4; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Ross Callon , David Ward Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Support, Thanks Regards... Zafar > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Loa Andersson > > Sent: Friday, March 28, 2008 7:47 AM > > To: mpls@ietf.org > > Cc: Ross Callon; David Ward > > Subject: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg > > document > > > > Working Group, > > > > the authors of > > > > Mechanism for performing LSP-Ping over MPLS tunnels > > > > > > have requested that this draft is made a working group document. > > > > Please send your comments/opinions (both positve and > > negative) to the working group mailing list, or directly to the > > working group chairs before April 11. > > > > 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@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 3 12:34:50 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BA03A6C2D; Thu, 3 Apr 2008 12:34:50 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCCF28C140 for ; Thu, 3 Apr 2008 12:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqFPY0hHiRMy for ; Thu, 3 Apr 2008 12:34:45 -0700 (PDT) Received: from lucidvision.com (static-72-71-250-34.cncdnh.fios.verizon.net [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 43B473A699E for ; Thu, 3 Apr 2008 12:34:45 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 8081A2CBB4E; Thu, 3 Apr 2008 12:34:54 -0700 (PDT) Message-Id: <958F0633-A190-4B92-B95E-76C6ED7FCB9C@lucidvision.com> From: Thomas Nadeau To: Loa Andersson In-Reply-To: <47ECDABA.3000104@pi.se> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 15:34:48 -0400 References: <47ECDABA.3000104@pi.se> X-Mailer: Apple Mail (2.919.2) Cc: Ross Callon , mpls@ietf.org, David Ward Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Agree. > Working Group, > > the authors of > > Mechanism for performing LSP-Ping over MPLS tunnels > > > have requested that this draft is made a working group > document. > > Please send your comments/opinions (both positve and negative) > to the working group mailing list, or directly to the working > group chairs before April 11. > > 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@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 4 01:04:42 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B8828C6DF; Fri, 4 Apr 2008 01:04:42 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6A628C13F for ; Fri, 4 Apr 2008 01:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.41 X-Spam-Level: * X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqWl6a7dAiLL for ; Fri, 4 Apr 2008 01:04:40 -0700 (PDT) Received: from n2a.bullet.mail.kr1.yahoo.com (n2a.bullet.mail.kr1.yahoo.com [203.212.170.73]) by core3.amsl.com (Postfix) with SMTP id AD69E28C6F2 for ; Fri, 4 Apr 2008 01:04:39 -0700 (PDT) Received: from [203.212.168.60] by n2.bullet.kr1.yahoo.com with NNFMP; 04 Apr 2008 08:04:44 -0000 Received: from [203.104.18.55] by t1.bullet.kr1.yahoo.com with NNFMP; 04 Apr 2008 08:04:44 -0000 Received: from [127.0.0.1] by omp107.mail.in2.yahoo.com with NNFMP; 04 Apr 2008 08:04:43 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 388619.31067.bm@omp107.mail.in2.yahoo.com Received: (qmail 21548 invoked by uid 60001); 4 Apr 2008 08:04:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=VBci9/Wmv61LEYYs0HGLJ9CJYArsbbnGKQ/jGNEsMDZbfnUImxhTtmRLHGqaGYh+gOk/GTF3boRvNpbk4rzN/YQjDUWhRFXp1e9Um9KI8ZyQ/zumWHDqK8jFpBXB21Dg8JU1rPJLZPF9qbNexCFQ1NkhoBZ9qw4yDnWAmJ3x4qs=; X-YMail-OSG: dJhAOtIVM1le51v06eHM.NqxgtSqO.P4w8dEZSNhHTZjofGAKRkKXGOVjSPAvQ0fhZGuHbdVpYUgUOCT7oha1_1IO4VDe6RFnoFMmbVA86j6f4uzPqNb1L6dPRQiwA-- Received: from [125.17.142.38] by web94611.mail.in2.yahoo.com via HTTP; Fri, 04 Apr 2008 13:34:43 IST X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Fri, 4 Apr 2008 13:34:43 +0530 (IST) From: priyanka gupta To: mpls@ietf.org MIME-Version: 1.0 Message-ID: <242019.21528.qm@web94611.mail.in2.yahoo.com> Subject: [mpls] Doubt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727109205==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============1727109205== Content-Type: multipart/alternative; boundary="0-53648039-1207296283=:21528" --0-53648039-1207296283=:21528 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=0A=0AI have few querys regarding LDP RFC 3036.=0AI want to post them= on this mailing group.may i know what is the process?=0A=0AThanks& regards= =0APriyanka=0A=0A=0A Meet people who discuss and share your passions. = Go to http://in.promos.yahoo.com/groups/bestofyahoo/ --0-53648039-1207296283=:21528 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,
=0A
 
=0A
I have fe= w querys regarding LDP RFC 3036.
=0A
I want to post them on this m= ailing group.may i know what is the process?
=0A
 
=0AThanks& regards
=0A
Priyanka

=0A=0A=0A =
Explore your hobbies and interests. Click here to begin. --0-53648039-1207296283=:21528-- --===============1727109205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1727109205==-- From mpls-bounces@ietf.org Fri Apr 4 02:42:45 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BE228C6C8; Fri, 4 Apr 2008 02:42:45 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02E428C648 for ; Fri, 4 Apr 2008 02:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CePGHomlEQGa for ; Fri, 4 Apr 2008 02:42:42 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id E5C1E28C6C8 for ; Fri, 4 Apr 2008 02:42:39 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JhiRX-0001gz-4I for mpls@ietf.org; Fri, 04 Apr 2008 11:42:43 +0200 Received: from h4n2fls31o874.telia.com ([213.66.236.4]:60737 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JhiRV-0001gi-Od; Fri, 04 Apr 2008 11:42:41 +0200 Message-ID: <47F5F7EF.5030906@pi.se> Date: Fri, 04 Apr 2008 11:42:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org, ccamp , l1vpn@ietf.org, pwe3 , L2VPN X-Enigmail-Version: 0.95.6 Cc: Ross Callon , David Ward Subject: [mpls] conclusion on the status of Y.1711 and RFC3429 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, on March 28 the MPLS WG chairs polled the several working group mailing lists about the state of Y.1711 and RFC3429 implementations and deployments. Our conclusion is that there is enough implementations and deployments of Y.1711 and hence it is not possible to, for time being, deprecate label 14 or obsolete RFC3429. This conclusion however leaves with the issue of investigating if Y.1711, other ITU-T documents and RFC3429 is well enough aligned or if updates is needed. 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 4 06:41:33 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886F328C3B0; Fri, 4 Apr 2008 06:41:33 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12F028C261 for ; Fri, 4 Apr 2008 06:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIWhiujxZTMH for ; Fri, 4 Apr 2008 06:41:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D9C4128C1E8 for ; Fri, 4 Apr 2008 06:41:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,604,1199660400"; d="scan'208";a="5398034" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Apr 2008 15:41:34 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m34DfYdY016427 for ; Fri, 4 Apr 2008 15:41:34 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m34DfYsN027349 for ; Fri, 4 Apr 2008 13:41:34 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 15:41:34 +0200 Received: from 144.254.23.91 ([144.254.23.91]) by xmb-ams-33a.emea.cisco.com ([144.254.231.85]) via Exchange Front-End Server email.cisco.com ([144.254.231.73]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Apr 2008 13:41:34 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 04 Apr 2008 06:41:29 -0700 From: Monique Morrow To: "Luyuan Fang (lufang)" , Message-ID: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciVr6St2jeZmzHqTnSolxapL6s6GAAAT7SgACoslfo= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 04 Apr 2008 13:41:34.0761 (UTC) FILETIME=[9942D990:01C89659] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=247; t=1207316494; x=1208180494; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:=20Monique=20Morrow=20 |Subject:=20Re=3A=20[mpls]=20draft-nitinb-lsp-ping-over-mpl s-tunnel-01=20for=20wg=0A=20document |Sender:=20; bh=NcwhWAI0kXUEP/gGYKFppLlxFtvMtfrpGB5IpglsQno=; b=AGmEHgZLB3W6sfTs9muNTvddkg5bSiHXc+cmM6J8sIV1+78l3OnaYFLcS0 Z4gZkHZ6iyDMEA33WZAF4Vjz7ATSVaGCexG8W5Z8AUzQ1VLoG7mqgVEkrbrw 8U1bWEp4dM; Authentication-Results: ams-dkim-1; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Also support On 4/3/08 10:35 AM, "Luyuan Fang (lufang)" wrote: > Support. > Luyuan > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 4 17:33:23 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BFC3A6CDD; Fri, 4 Apr 2008 17:33:23 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E583C3A6CB7 for ; Fri, 4 Apr 2008 17:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTAA0wASZuAC for ; Fri, 4 Apr 2008 17:33:21 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 10F293A6CC9 for ; Fri, 4 Apr 2008 17:33:19 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Apr 2008 17:33:25 PDT Received: from emailcorp1.jnpr.net ([66.129.254.11]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 17:32:36 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 17:31:18 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 17:31:18 -0700 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E01664692@emailcorp3.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-nitinb-lsp-ping-over-mpls-tunnel-01 Thread-Index: AciVdKlZtABt4yjg+kqTFkLP+zWs5QBPdqvA References: From: "Nitin Bahadur" To: "Ben Niven-Jenkins" , X-OriginalArrivalTime: 05 Apr 2008 00:31:18.0703 (UTC) FILETIME=[5D8053F0:01C896B4] Subject: Re: [mpls] Comments on draft-nitinb-lsp-ping-over-mpls-tunnel-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Ben, > During the ITU-T SG15 ad hoc meeting on T-MPLS in February, the ITU model > (G.8110) of MPLS was discussed. G.8110 models a SWAP as a POP followed by > a > PUSH and at least one of the IETF representatives at the meeting expressed > the view that modelling a SWAP as a POP followed by a PUSH did not > sufficiently describe the behaviour as per the MPLS architecture > (RFC3031). > > You appear to be doing the same here, so is modelling a SWAP as a POP > followed by a PUSH sufficient in this context? Very good observation. In the forwarding plane, a POP/PUSH does not tell you much. In the control plane, a POP/PUSH can be tailored to provide sufficient detail so that the semantics are much clear. In this draft, the POP/PUSH operations have FEC and peer-address associated with them. That should help clarify the intended behavior. If there is still a chance of ambiguity, we can modify the control information for clarity. > Remote peer address > "If the operation type is POP, the remote peer address MAY not be set to > Unspecified." > I find the use of the term "MAY not" confusing. If you really mean MAY > then > as it is optional, IMO the not is superfluous. Yes, that's correct. The intention is "MAY" and not "MAY not". I shall have that corrected. I've taken care of the editorials. Thanks for combing through the document in detail. Nitin _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 4 19:02:03 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2183A69EA; Fri, 4 Apr 2008 19:02:03 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9B13A69EA for ; Fri, 4 Apr 2008 19:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbqeCT5r87N1 for ; Fri, 4 Apr 2008 19:02:01 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 5D40B3A6993 for ; Fri, 4 Apr 2008 19:02:01 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Apr 2008 19:02:08 PDT Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 19:01:33 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 19:00:32 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 18:58:43 -0700 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E01664694@emailcorp3.jnpr.net> In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191E08@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciQyZ/SlU3iPWcUSXaOHW9e4590PwE6O7NgAENz3vA= References: <47ECDABA.3000104@pi.se> <4A5028372622294A99B8FFF6BD06EB7B04191E08@USDALSMBS03.ad3.ad.alcatel.com> From: "Nitin Bahadur" To: "AISSAOUI Mustapha" , "Loa Andersson" , X-OriginalArrivalTime: 05 Apr 2008 02:00:32.0138 (UTC) FILETIME=[D465AEA0:01C896C0] Cc: Ross Callon , David Ward Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > My main issue is that a FEC Swap is different from FEC tunneling and > that the use of the FEC Stack Change Sub-TLV is not warranted. A reply > with the Target FEC stack TLV is sufficient. > > My proposal to the authors was to make the FEC Stack Change Sub-TLV > optional and to limit its use to indicate the FEC being traced is > entering or exiting a tunnel or tunnels. I believe we had that discussion on the WG mailing list. And I had mentioned reasons as to why FEC Swap is better than sending the full FEC stack in the reply. Nitin _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From MathewominousCarlson@foodnetwork.com Sat Apr 5 02:25:00 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BA728C19E; Sat, 5 Apr 2008 02:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.864 X-Spam-Level: X-Spam-Status: No, score=-16.864 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_ROLEX=5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlgWds6ZUq73; Sat, 5 Apr 2008 02:24:59 -0700 (PDT) Received: from uwrvv6t73a3gt6.arnhem.chello.nl (g248100.upc-g.chello.nl [80.57.248.100]) by core3.amsl.com (Postfix) with SMTP id 6A9683A681A; Sat, 5 Apr 2008 02:24:57 -0700 (PDT) Received: from 18766294044947078.17449537077319889.17243798393214233.14900978728038294 (HELO localhost.localdomain) (13240675875880527.12321498096223719.12831039903899708.11730174194413994) by 12658337055309531.12734199340142781.13675150355594750.12323213840158769 with SMTP; Sat, 5 Apr 2008 11:24:33 -0100 Date: Sat, 5 Apr 2008 11:24:33 -0100 Message-Id: <8IX658EJXVWDA149@foodnetwork.com> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 753113 X-Header-Versions: Hewlett-Packard.1t5bn6nd6.fk@us.newsgram.hp.com X-FID: 22E68DBC-2865-35AF-B3E8-22CDEA75DCB1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Cc: , , , From: "Lonnie Fowler" Subject: Designer Watches High Quality Watches & Products from an offical of prestige USA and Swiss watches manufacturers! http://juscutbah.com/ Rolex Timepieces on Sale!! From jyxnarihel@nari.name Sun Apr 6 23:21:11 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423A83A6E6F; Sun, 6 Apr 2008 23:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyr0wRD1Doze; Sun, 6 Apr 2008 23:21:10 -0700 (PDT) Received: from [116.71.243.214] (unknown [116.71.243.214]) by core3.amsl.com (Postfix) with ESMTP id 2AA8C3A6BA2; Sun, 6 Apr 2008 23:21:09 -0700 (PDT) Received: from [116.71.243.214] by mx04.nic.name; Mon, 7 Apr 2008 11:21:21 +0500 Date: Mon, 7 Apr 2008 11:21:21 +0500 From: "Roy Darby" X-Mailer: The Bat! (v3.62.14) Educational Reply-To: jyxnarihel@nari.name X-Priority: 3 (Normal) Message-ID: <782218263.02723971750250@nari.name> To: ipsra-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------CABBBBB48D3F21" ------------CABBBBB48D3F21 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Our main purpose is to provide PC and Macintosh lawful soft and computer solutions of low price for any budget. Whether you are a corporate buyer, a small enterprise owner, or shopping for your home PC, we guess we'll assist you. VIEW WHAT WE HAVE TO PROPOSE! http://frankiesubletteps539.googlepages.com ------------CABBBBB48D3F21 Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit Our main purpose is to provide PC and Macintosh lawful soft and computer solutions of low price for any budget.
Whether you are a corporate buyer, a small enterprise owner,
or shopping for your home PC, we guess we'll assist you.
VIEW WHAT WE HAVE TO PROPOSE!
http://frankiesubletteps539.googlepages.com
------------CABBBBB48D3F21-- From mpls-bounces@ietf.org Mon Apr 7 05:39:34 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85563A6BB0; Mon, 7 Apr 2008 05:39:33 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 262BD3A6B8C; Thu, 3 Apr 2008 01:09:04 -0700 (PDT) Mime-Version: 1.0 To: tsbsg13@itu.int From: Loa Andersson(IETF MPLS WG) Message-Id: <20080403080905.262BD3A6B8C@core3.amsl.com> Date: Thu, 3 Apr 2008 01:09:05 -0700 (PDT) X-Mailman-Approved-At: Mon, 07 Apr 2008 05:39:32 -0700 Cc: mpls@lists.ietf.org, Georges Sebel , huilanlu@alcatel-lucent.com, David Ward , Ross Callon , Stewart Bryant Subject: [mpls] New Liaison Statement, "Response to the liaison on Y.RACF-DistribMPLS "Distributed RACF Architecture for MPLS Networks"" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa@pi.se, swallow@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Title: Response to the liaison on Y.RACF-DistribMPLS "Distributed RACF Architecture for MPLS Networks" Submission Date: 2008-04-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=433 Please reply by 2008-07-25 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG13(tsbsg13@itu.int) Cc: Ross Callon David Ward Stewart Bryant Georges Sebel Reponse Contact: loa@pi.se swallow@cisco.com Technical Contact: Loa Andersson George Swallow Purpose: For comment Body: Thank you for your liaison from your Seoul meeting on Y.RACF-DistribMPLS "Distributed RACF Architecture for MPLS Networks". This work is of interest to the MPLS Working Group. Please keep us informed as the work progresses. Upon a cursory review we have identified some points where clarification would be beneficial to our understanding. Our reading is that ITU-T 4/13 has defined and Session Border Controller Connection Admission Control function as a gateway connected with an MPLS LER and in the so called distributed environment it appears that this function is embedded in the ingress MPLS LER. There are several points where we would greatly appreciate your clarification: 1. Describe the process by which the SBC gateway determines QoS and priority requirements by the so called "Policy Decision and Functional Entity" [PD-FE]? 2. Once the PD-FE QoS and priority requirements have been established by the PD-FE, what is the process by which they are then communicated to the MPLS LER? 3. Describe the expected behavior by the MPLS LER, e.g. the actual mechanism for tunneling. 4. What is meant by a PE-FE function as pointed out on page 4 of this document, eg. that an Ingress LER will also possess SBC gateway capabilities? 5. What extensions of DS-TE do you expect to have if any to support the PE-FE capability? We look forward to your reply. Thank you, George Swallow and Loa Andersson, MPLS wg co-chairs Attachment(s): No document has been attached _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From floatwater89@yahoo.com Mon Apr 7 10:36:42 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECE13A6A90 for ; Mon, 7 Apr 2008 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.23 X-Spam-Level: X-Spam-Status: No, score=-44.23 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9K3LEdZrg3E for ; Mon, 7 Apr 2008 10:36:38 -0700 (PDT) Received: from [189.41.14.18] (189-041-14-018.xd-dynamic.ctbcnetsuper.com.br [189.41.14.18]) by core3.amsl.com (Postfix) with ESMTP id 472043A6865 for ; Mon, 7 Apr 2008 10:36:35 -0700 (PDT) Received: from [189.41.14.18] by a.mx.mail.yahoo.com; Mon, 7 Apr 2008 14:36:49 -0300 From: adwords-noreply@google.com To: Subject: Please submit your payment information Date: Mon, 7 Apr 2008 14:36:49 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C898BC.CFF0D680" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6QE8P6YTW8OEBM8K060J0K6YHD1== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Message-ID: <01c898bc$cff0d680$120e29bd@floatwater89> X-Antivirus: avast! (VPS 000734-2, 18/04/2007), Outbound message X-Antivirus-Status: Clean This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C898BC.CFF0D680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. ---------------------------------------------------------------------------------- Dear AdWords Customer, Your ads have stopped running because we were unable to process your billing information. To activate your account and start running your ads, enter your billing information. In order to activate your account and start running your ads, enter your billing information. Pease sign into your account at http://adwords.google.com/select/login, and update your billing information. Once your account is reactivated and your billing information has been processed, any your ads and campaigns can begin running immediately on Google. ---------------------------------------------------------------------------------- The Google-AdWords Team ------=_NextPart_000_0006_01C898BC.CFF0D680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.

-------------------------------------------------------------------------= ---------

Dear AdWords Customer,

Your ads have stopped running because we were unable to process your bill= ing information.
To activate your account and start running your ads, enter your billing i= nformation.

In order to activate your account and start running your ads, enter your = billing information.
Pease sign into your account at http://adwords.google.com/select/login, and update=
your billing information.

Once your account is reactivated and your billing information has been pr= ocessed,
any your ads and campaigns can begin running immediately on Google.
<= br> -------------------------------------------------------------------------= ---------

The Google-AdWords Team
------=_NextPart_000_0006_01C898BC.CFF0D680-- From mpls-bounces@ietf.org Tue Apr 8 11:07:55 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F763A6B03; Tue, 8 Apr 2008 11:07:55 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F397D3A6B03 for ; Tue, 8 Apr 2008 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33nSWzpLugfx for ; Tue, 8 Apr 2008 11:07:52 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id A47B23A6B96 for ; Tue, 8 Apr 2008 11:07:47 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Apr 2008 11:07:25 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 11:07:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 14:00:35 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document Thread-Index: AciZobWDVShBbEsgTDqEZqzCO5X2pgAABEvw References: From: "Thomas Walsh" To: X-OriginalArrivalTime: 08 Apr 2008 18:07:35.0305 (UTC) FILETIME=[6C239790:01C899A3] Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0656468828==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============0656468828== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C899A2.7248A009" This is a multi-part message in MIME format. ------_=_NextPart_001_01C899A2.7248A009 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa, =20 I am in favor of accepting this as a WG draft. =20 Tom Walsh =20 ________________________________ Working Group, =20 the authors of =20 Mechanism for performing LSP-Ping over MPLS tunnels =20 have requested that this draft is made a working group document. =20 Please send your comments/opinions (both positve and negative) to the working group mailing list, or directly to the working group chairs before April 11. =20 Loa and George =20 --=20 Loa Andersson =20 Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson at acreo.se loa at pi.se _______________________________________________ mpls mailing list mpls at ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 =20 ------_=_NextPart_001_01C899A2.7248A009 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Loa,

 

I am in favor of accepting this as a WG = draft.

 

Tom Walsh

 

Working =
Group,
 
the =
authors of
 
Mechanism =
for performing LSP-Ping over MPLS =
tunnels
<draft-nitinb-lsp-ping-over-mpls-tunnel-01&=
gt;
 
have =
requested that this draft is made a working =
group
document.
<=
font
size=3D2 face=3D"Courier New"> 
Please =
send your comments/opinions (both positve and =
negative)
to the =
working group mailing list, or directly to the =
working
group =
chairs before April 11.
 
Loa and =
George
 
-- =

Loa =
Andersson
 
Principal =
Networking Architect
Acreo AB      =
;            =
         phone:  +46 8 632 77 14<=
/u1:SPAN>
Isafjordsgatan =
22            =
;      mobile: +46 739 81 21 64
Kista=
, Sweden   &nbs=
p;            =
;      email:  loa.andersson at =
acreo.se
       &nbs=
p;            =
;            =
            loa =
at pi.se
______________________________________________=
_
mpls =
mailing list
mpls at =
ietf.org
https://www.ietf.org/=
mailman/listinfo/mpls
 

 

------_=_NextPart_001_01C899A2.7248A009-- --===============0656468828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0656468828==-- From mpls-bounces@ietf.org Tue Apr 8 11:47:17 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C16E28C0E2; Tue, 8 Apr 2008 11:47:17 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52AB33A6ABB for ; Tue, 8 Apr 2008 11:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubOgBeD+lcoW for ; Tue, 8 Apr 2008 11:47:15 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 6CCF83A6A99 for ; Tue, 8 Apr 2008 11:47:15 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Apr 2008 11:47:12 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 11:47:12 -0700 Received: from [172.23.1.71] ([172.23.1.71] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 14:47:10 -0400 Message-ID: <47FBBDAA.3060601@juniper.net> Date: Tue, 08 Apr 2008 14:47:06 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Monique Morrow References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 X-OriginalArrivalTime: 08 Apr 2008 18:47:10.0536 (UTC) FILETIME=[F3E31480:01C899A8] Cc: mpls@ietf.org, "Luyuan Fang \(lufang\)" Subject: Re: [mpls] draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Also support Monique Morrow wrote: > Also support > > > On 4/3/08 10:35 AM, "Luyuan Fang (lufang)" wrote: > > >>Support. >>Luyuan >>_______________________________________________ >>mpls mailing list >>mpls@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 9 14:36:44 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDE83A6AD1 for ; Wed, 9 Apr 2008 14:36:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: You have been unsubscribed from the mpls mailing list From: mpls-bounces@ietf.org To: mpls-archive@megatron.ietf.org Message-ID: Date: Wed, 09 Apr 2008 14:36:42 -0700 Precedence: bulk X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multi-Protocol Label Switching WG X-List-Administrivia: yes Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Thank you for playing... From mpls-bounces@ietf.org Wed Apr 9 14:38:30 2008 Return-Path: X-Original-To: mpls-archive@ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1933A6D98 for ; Wed, 9 Apr 2008 14:38:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: You have been unsubscribed from the mpls mailing list From: mpls-bounces@ietf.org To: mpls-archive@ietf.org Message-ID: Date: Wed, 09 Apr 2008 14:38:30 -0700 Precedence: bulk X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multi-Protocol Label Switching WG X-List-Administrivia: yes Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Thank you for playing... From mpls-bounces@ietf.org Thu Apr 10 03:19:34 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D85E28C391; Thu, 10 Apr 2008 03:19:34 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC1F3A6D3C for ; Thu, 10 Apr 2008 03:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.278 X-Spam-Level: ** X-Spam-Status: No, score=2.278 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgTIMCswBPwa for ; Thu, 10 Apr 2008 03:19:32 -0700 (PDT) Received: from rediffmail.com (f5mail-236-228.rediffmail.com [202.137.236.228]) by core3.amsl.com (Postfix) with SMTP id 7EA093A6C91 for ; Thu, 10 Apr 2008 03:19:31 -0700 (PDT) Received: (qmail 3007 invoked by uid 510); 10 Apr 2008 10:21:45 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=iUoWAdOS8LH0ZSWsB7Cp4x3yOLgpyow9a084+pC7vhPi2wuQLowILzF5OdBM/YeRr/UdcFpug0G7HmgW7Z0izN4WxLFvohWTTQnHlPo/mIoab9tMMD3B1Xe/noY799m9lkPceQC9runJYNxIk0oB/XpB2Q+W4TwMfXCjDkX6Fg4= ; XX-CMAE-analysis: score=0 v=1.0 c=1 a=Y6zjXLVKI+OeaIkGxC4avA==:17 a=NFO3aJ82Ltzq_C5V_qoA:9 a=-8OhHIs6914-1oc5kJenwYAj9_8A:4 a=50e4U0PicR4A:10 a=6SwCy3u5AAAA:8 a=aCRQSj1kk_co3o9n9NYA:7 Date: 10 Apr 2008 10:21:45 -0000 MIME-Version: 1.0 To: , Received: from unknown 203.126.136.220 by rediffmail.com via HTTP; 10 Apr 2008 10:21:45 -0000 Message-ID: <1202104968.S.1689.8898.f5mail-237-203.rediffmail.com.old.1207822905.20267@webmail.rediffmail.com> From: "anshu " Subject: [mpls] error response to mpls data packets X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1633364128==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============1633364128== Content-Type: multipart/alternative; boundary="=_f0b35b2ce3d93bb04e7ffb0529ebe032" --=_f0b35b2ce3d93bb04e7ffb0529ebe032 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi,MPLS LSPs can span across different type of networks.Suppose LSP spans across R1,R2,R3 and R2 is not part of IP networks. In that case how will the forwarding error is handled at R2 (incase its part of IP, ICMP errormessage can be sent to the source). I could not find any standard specs which talks about any genericimplementation.Regards,Anshu --=_f0b35b2ce3d93bb04e7ffb0529ebe032 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi,
MPLS LSPs can span across different type of networks.
Suppose= LSP spans across R1,R2,R3 and R2 is not part of IP networks.
In that case how will the forwarding error is handled at R2 (incase i= ts part of IP, ICMP error
message can be sent to the source). I could = not find any standard specs which talks about any generic
implementati= on.

Regards,
Anshu
=20
=3D'JS
--=_f0b35b2ce3d93bb04e7ffb0529ebe032-- --===============1633364128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1633364128==-- From mpls-bounces@ietf.org Thu Apr 10 07:59:17 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B6828C309; Thu, 10 Apr 2008 07:59:17 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C733A6F20 for ; Thu, 10 Apr 2008 07:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6yi3Krv0mw7 for ; Thu, 10 Apr 2008 07:59:10 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id C99FE3A6C83 for ; Thu, 10 Apr 2008 07:59:09 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Apr 2008 07:59:29 PDT Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 07:58:59 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 07:57:31 -0700 Received: from 172.23.4.253 ([172.23.4.253]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Apr 2008 14:57:31 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Thu, 10 Apr 2008 07:58:46 -0700 From: Nitin Bahadur To: anshu , , Message-ID: Thread-Topic: [mpls] error response to mpls data packets Thread-Index: AcibG2As5C0LZT7bYU+OoqJhjGSRrg== In-Reply-To: <1202104968.S.1689.8898.f5mail-237-203.rediffmail.com.old.1207822905.20267@webmail.rediffmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 10 Apr 2008 14:57:31.0553 (UTC) FILETIME=[33CCA110:01C89B1B] Subject: Re: [mpls] error response to mpls data packets X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1586959046==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1586959046== Content-type: multipart/alternative; boundary="B_3290659126_469184" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3290659126_469184 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > >> > MPLS LSPs can span across different type of networks. >> > Suppose LSP spans across R1,R2,R3 and R2 is not part of IP networks. >> > In that case how will the forwarding error is handled at R2 (incase its >> part of IP, ICMP error >> > message can be sent to the source). > > If R2 is pure MPLS and there is a forwarding error, then the packet will > likely get dropped. > MPLS has no equivalent of ICMP error. For MPLS networks, it is important that > one run MPLS-OAM tools to quickly detect forwarding plane errors and fix the > same. --B_3290659126_469184 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls] error response to mpls data packets
=
> MPLS LSPs can span across different type of networks.
> Suppose LSP spans across R1,R2,R3 and R2 is not part of IP networks. <= BR> > In that case how will the forwarding error is handled at R2 (incase it= s part of IP, ICMP error
> message can be sent to the source).

If R2 is pure MPLS and there is a forwarding error, then the packet will li= kely get dropped.
MPLS has no equivalent of ICMP error. For MPLS networks, it is important th= at one run MPLS-OAM tools to quickly detect forwarding plane errors and fix = the same.
--B_3290659126_469184-- --===============1586959046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1586959046==-- From mpls-bounces@ietf.org Thu Apr 10 10:01:29 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF523A6A8D; Thu, 10 Apr 2008 10:01:29 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DBC3A6A8D for ; Thu, 10 Apr 2008 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbRXuN8xE8kC for ; Thu, 10 Apr 2008 10:01:26 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id A7D783A68A8 for ; Thu, 10 Apr 2008 10:01:20 -0700 (PDT) Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 10 Apr 2008 22:31:36 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3AH1X9w004093; Fri, 11 Apr 2008 01:01:33 +0800 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3AH1Xow018147; Thu, 10 Apr 2008 17:01:33 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 22:31:32 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 22:35:23 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC05540840@xmb-blr-417.apac.cisco.com> In-reply-to: <1202104968.S.1689.8898.f5mail-237-203.rediffmail.com.old.1207822905.20267@webmail.rediffmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] error response to mpls data packets Thread-Index: Acia9IZRDKITOiTYT7eJALWA2r22ngANka5w References: <1202104968.S.1689.8898.f5mail-237-203.rediffmail.com.old.1207822905.20267@webmail.rediffmail.com> From: "Anup Kumar Vasudevan (anuvasud)" To: "anshu " , , X-OriginalArrivalTime: 10 Apr 2008 17:01:32.0530 (UTC) FILETIME=[86F79D20:01C89B2C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5121; t=1207846893; x=1208710893; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anuvasud@cisco.com; z=From:=20=22Anup=20Kumar=20Vasudevan=20(anuvasud)=22=20 |Subject:=20RE=3A=20[mpls]=20error=20response=20to=20mpls=2 0data=20packets |Sender:=20; bh=UZnJE7Ovr1x12EiJhdaRGPRaXTH6oAMtza5HBVJtqgw=; b=B59kGaRIPk4meSnFkJckXyW/zpmREQ5jbHr+yY0O7XcD/E5pn5pp7jYxi9 TlzlZHyyO019We2FMgQUSaWeAn2WHj4f/Vnuz7LaOWM2K02GbBDjbkmkAWe5 UZn9nKugYXNdN+7fL0inckBexlNT02l2FuwDATnJM+t87FpInsGSM=; Authentication-Results: hkg-dkim-2; header.From=anuvasud@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [mpls] error response to mpls data packets X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0958304886==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============0958304886== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89B2C.86D30CE2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89B2C.86D30CE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 =20 Will RFC 4379 not suit your purpose? This is the RFC that defines MPLS OAM - look at 4377 and 4378 for a framework and requirements of OAM. However, if R2 is not part of the IP network, the MPLS n/w will terminate at R2 i.e. the R1-R2 will be one LSP and R2-R3 will be a different LSP?=20 =20 Also within the OAM RFC you might have to look more at the Downstream Mapping TLV. However in case of a failure at R2, it should be able to handle the MPLS Echo request packet which is a UDP packet, with the Label stack of the LSP being used, and with a destination address in the Local loopback region of IPv4/IPV6.=20 =20 Regards Anup Vasudevan ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of anshu=20 Sent: Thursday, April 10, 2008 3:52 PM To: mpls@uu.net; mpls@lists.ietf.org Subject: [mpls] error response to mpls data packets Hi, MPLS LSPs can span across different type of networks. Suppose LSP spans across R1,R2,R3 and R2 is not part of IP networks.=20 In that case how will the forwarding error is handled at R2 (incase its part of IP, ICMP error message can be sent to the source). I could not find any standard specs which talks about any generic implementation. Regards, Anshu =09 ------_=_NextPart_001_01C89B2C.86D30CE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
Will RFC 4379 not suit your purpose? This is = the RFC=20 that defines MPLS OAM - look at 4377 and 4378 for a framework and = requirements=20 of OAM. However, if R2 is not part of the IP network, the MPLS n/w will=20 terminate at R2  i.e. the R1-R2 will be one LSP and R2-R3 will be a = different LSP?
 
Also within the OAM RFC you might have to = look more at=20 the Downstream Mapping TLV. However in case of a failure at R2, it = should be=20 able to handle the MPLS Echo request packet which is a UDP packet, with = the=20 Label stack of the LSP being used, and with a destination address in the = Local=20 loopback region of IPv4/IPV6.
 
Regards
Anup Vasudevan

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of anshu =
Sent:=20 Thursday, April 10, 2008 3:52 PM
To: mpls@uu.net;=20 mpls@lists.ietf.org
Subject: [mpls] error response to mpls = data=20 packets

Hi,
MPLS LSPs can span across different type of=20 networks.
Suppose LSP spans across R1,R2,R3 and R2 is not part of IP=20 networks.
In that case how will the forwarding error is handled at = R2=20 (incase its part of IP, ICMP error
message can be sent to the = source). I=20 could not find any standard specs which talks about any=20 generic
implementation.

Regards,
Anshu

------_=_NextPart_001_01C89B2C.86D30CE2-- --===============0958304886== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0958304886==-- From negonurairkap@onurair.de Fri Apr 11 00:08:20 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2285328C11D; Fri, 11 Apr 2008 00:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.131 X-Spam-Level: **** X-Spam-Status: No, score=4.131 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4F9rvois03B; Fri, 11 Apr 2008 00:08:16 -0700 (PDT) Received: from host115-214-static.46-85-b.business.telecomitalia.it (host115-214-static.46-85-b.business.telecomitalia.it [85.46.214.115]) by core3.amsl.com (Postfix) with ESMTP id 83B0628C0DD; Fri, 11 Apr 2008 00:08:02 -0700 (PDT) Received: from [85.46.214.115] by mail.onurair.de; Fri, 11 Apr 2008 08:08:35 +0100 Date: Fri, 11 Apr 2008 08:08:35 +0100 From: "Mamie Person" X-Mailer: The Bat! (v2.00) Personal Reply-To: negonurairkap@onurair.de X-Priority: 3 (Normal) Message-ID: <624730854.74500691974620@onurair.de> To: ldapbis-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------5BD3E542CF8B6712" ------------5BD3E542CF8B6712 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Our main goal is to render low cost PC and Macintosh legal software and computer solutions for anyone's budget. Whether you are a corporate client, an owner of small business, or go shopping for your own PC, we suppose we can assist you. CHECK WHAT WE HAVE TO OFFER! http://earnestinermsf689.googlepages.com ------------5BD3E542CF8B6712 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Our main goal is to render low cost PC and Macintosh legal software and computer solutions for anyone's budget.
Whether you are a corporate client, an owner of small business,
or go shopping for your own PC, we suppose we can assist you.
CHECK WHAT WE HAVE TO OFFER!
http://earnestinermsf689.googlepages.com
------------5BD3E542CF8B6712-- From mpls-bounces@ietf.org Fri Apr 11 08:16:58 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1823A6E7A; Fri, 11 Apr 2008 08:16:58 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9F728C0E4 for ; Fri, 11 Apr 2008 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9QAmXI6iCXt for ; Fri, 11 Apr 2008 08:16:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 38DC63A6E9F for ; Fri, 11 Apr 2008 08:16:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3BFHHUa003346 for ; Fri, 11 Apr 2008 16:17:17 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3BFHFwr003282 for ; Fri, 11 Apr 2008 16:17:17 +0100 Message-ID: <049601c89be7$1efc9700$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 11 Apr 2008 16:15:02 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [mpls] Two CCAMP last calls of possible interest X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi, CCAMP is running working group last calls on two I-Ds that may be of interest to the MPLS working group. draft-ietf-rfc4420-bis-02.txt This is a revision to RFC 4420 to fix the TLV encoding to be consistent with the previous RSVP-TE RFCs. The fix is to the interpretation of the Length field. draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt This I-D for asymmetrical bandwidth allocations on bidirectional LSPs has been moved into the WG from being an individual submission, and has been marked as "Experimental". The reasoning was: - This is clearly a draft that CCAMP needs to review, so it might as well be a CCAMP draft. - This is a "stake in the ground" for how this problem would be solved within RSVP-TE, but at this stage there are no known implementations and no-one considering implementation. Please send your comments to the CCAMP list (or to the CCAMP chairs) by 12 noon GMT, April 26, 2008. Thanks, Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 11 11:59:24 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7873A6D6B; Fri, 11 Apr 2008 11:59:24 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 87CC73A6BFA; Fri, 11 Apr 2008 11:59:23 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080411185923.87CC73A6BFA@core3.amsl.com> Date: Fri, 11 Apr 2008 11:59:23 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-ldp-capabilities (LDP Capabilities) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Capabilities ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-capabilities-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16024&rfc_flag=0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 11 12:00:18 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454B428C53A; Fri, 11 Apr 2008 12:00:18 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5653628C3D7; Fri, 11 Apr 2008 12:00:14 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080411190015.5653628C3D7@core3.amsl.com> Date: Fri, 11 Apr 2008 12:00:15 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-ldp-interarea (LDP extension for Inter-Area LSP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP extension for Inter-Area LSP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-interarea-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16354&rfc_flag=0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 11 12:00:50 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3616028C58F; Fri, 11 Apr 2008 12:00:50 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 330E528C23B; Fri, 11 Apr 2008 12:00:48 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080411190049.330E528C23B@core3.amsl.com> Date: Fri, 11 Apr 2008 12:00:49 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Multicast Encapsulations ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-encaps-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14250&rfc_flag=0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 11 12:02:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9D528C5CE; Fri, 11 Apr 2008 12:02:04 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 23A7E3A6E3A; Fri, 11 Apr 2008 12:02:01 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080411190202.23A7E3A6E3A@core3.amsl.com> Date: Fri, 11 Apr 2008 12:02:02 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-number-0-bw-te-lsps (A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14681&rfc_flag=0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 11 12:20:58 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0330628C5EA; Fri, 11 Apr 2008 12:02:39 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A204628C5DE; Fri, 11 Apr 2008 12:02:35 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080411190235.A204628C5DE@core3.amsl.com> Date: Fri, 11 Apr 2008 12:02:35 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-upstream-label (MPLS Upstream Label Assignment and Context-Specific Label Space) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Upstream Label Assignment and Context-Specific Label Space ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-upstream-label-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14528&rfc_flag=0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Apr 11 15:57:00 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086BC3A699D; Fri, 11 Apr 2008 15:57:00 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1583A699D for ; Fri, 11 Apr 2008 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjnwNh2f9dAt for ; Fri, 11 Apr 2008 15:56:58 -0700 (PDT) Received: from mail44.messagelabs.com (mail44.messagelabs.com [216.82.249.179]) by core3.amsl.com (Postfix) with ESMTP id 10B503A6968 for ; Fri, 11 Apr 2008 15:56:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: nthomson@csc.com X-Msg-Ref: server-4.tower-44.messagelabs.com!1207954640!644947!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 26777 invoked from network); 11 Apr 2008 22:57:21 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-44.messagelabs.com with AES256-SHA encrypted SMTP; 11 Apr 2008 22:57:21 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m3BN1UBb014829 for ; Fri, 11 Apr 2008 19:01:31 -0400 From: Neil Thomson To: mpls@ietf.org Message-ID: Date: Fri, 11 Apr 2008 23:56:22 +0100 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 04/11/2008 07:00:19 PM MIME-Version: 1.0 Subject: [mpls] Neil Thomson/GIS/CSC is out of the office. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org I will be out of the office starting 11/04/2008 and will not return until 22/04/2008. For local site enquiries please contact Raymond Bush (CSC) 0141 333 2641. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From flipp_24@yahoo.com Sun Apr 13 12:05:38 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F97628C28F for ; Sun, 13 Apr 2008 12:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.179 X-Spam-Level: X-Spam-Status: No, score=-50.179 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj-3mhOiibPB for ; Sun, 13 Apr 2008 12:05:36 -0700 (PDT) Received: from [88.240.217.127] (unknown [88.240.217.127]) by core3.amsl.com (Postfix) with ESMTP id D048028C297 for ; Sun, 13 Apr 2008 12:05:06 -0700 (PDT) Received: from [88.240.217.127] by b.mx.mail.yahoo.com; , 13 Apr 2008 21:05:35 +0200 Message-ID: <01c89daa$1dcc7980$7fd9f058@flipp_24> From: "Google AdWords" To: Subject: Update Your Billing Information Date: , 13 Apr 2008 21:05:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C89DAA.1DCC7980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.5 X-Antivirus: avast! (VPS 071208-0, 08.12.2007), Outbound message X-Antivirus-Status: Clean This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C89DAA.1DCC7980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= -------- Dear Google Adwords Customer, Your ads have stopped running because we were unable to process your bill= ing information. To activate your account and start running your ads, enter your billing i= nformation. In order to activate your account and start running your ads, enter your = billing information. Pease sign into your account at http://adwords.google.com/select/login, a= nd update your billing information. Once your account is reactivated and your billing information has been pr= ocessed, any your ads and campaigns can begin running immediately on Google. -------------------------------------------------------------------------= --------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. -------------------------------------------------------------------------= --------- Google Adwords Team ------=_NextPart_000_0007_01C89DAA.1DCC7980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= --------
Dear Google Adwords Customer, Your ads have stopped running because we were unable to process your bill= ing information.
To activate your account and start running your ads, enter your billing i= nformation.

In order to activate your account and start running your ads, enter your = billing information.
Pease sign into your account at http://adwords.google.com/select/login, and upd= ate
your billing information.

Once your account is reactivated and your billing information has been pr= ocessed,
any your ads and campaigns can begin running immediately on Google.
<= br> -------------------------------------------------------------------------= ---------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.

-------------------------------------------------------------------------= ---------

Google Adwords Team ------=_NextPart_000_0007_01C89DAA.1DCC7980-- From mpls-bounces@ietf.org Mon Apr 14 01:35:42 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424AC3A695A; Mon, 14 Apr 2008 01:35:42 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08503A67B2 for ; Mon, 14 Apr 2008 01:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNu3AGUGAFi3 for ; Mon, 14 Apr 2008 01:35:37 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id E54B03A6AD2 for ; Mon, 14 Apr 2008 01:35:36 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JlKAV-0008Du-TX for mpls@ietf.org; Mon, 14 Apr 2008 10:36:03 +0200 Received: from h4n2fls31o874.telia.com ([213.66.236.4]:62825 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JlKAT-0008Do-Rw; Mon, 14 Apr 2008 10:36:01 +0200 Message-ID: <4803173B.5070807@pi.se> Date: Mon, 14 Apr 2008 10:35:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org References: <47ECDABA.3000104@pi.se> In-Reply-To: <47ECDABA.3000104@pi.se> X-Enigmail-Version: 0.95.6 Cc: Ross Callon , David Ward Subject: [mpls] Ended: Re: draft-nitinb-lsp-ping-over-mpls-tunnel-01 for wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This poll has ended, we have good support to make the document a working group document. Could the author plese republish the document as: draft-ietf-lsp-ping-over-mpls-tunnel-00 Loa and George /Loa Loa Andersson wrote: > Working Group, > > the authors of > > Mechanism for performing LSP-Ping over MPLS tunnels > > > have requested that this draft is made a working group > document. > > Please send your comments/opinions (both positve and negative) > to the working group mailing list, or directly to the working > group chairs before April 11. > > 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Apr 14 02:02:44 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4F93A6E10; Mon, 14 Apr 2008 02:02:44 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62ED63A6D9D for ; Mon, 14 Apr 2008 02:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVbbCMAX9ka9 for ; Mon, 14 Apr 2008 02:02:42 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id 5E7303A6E10 for ; Mon, 14 Apr 2008 02:02:42 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JlKal-0008NG-3h for mpls@ietf.org; Mon, 14 Apr 2008 11:03:11 +0200 Received: from h4n2fls31o874.telia.com ([213.66.236.4]:62888 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JlKaj-0008NA-ES; Mon, 14 Apr 2008 11:03:09 +0200 Message-ID: <48031D97.5010706@pi.se> Date: Mon, 14 Apr 2008 11:02:15 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org, Ross Callon , David Ward References: <47E9621C.4090804@pi.se> In-Reply-To: <47E9621C.4090804@pi.se> X-Enigmail-Version: 0.95.6 Subject: [mpls] Ended: wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Working Group, this working group last call has ended. There has been comments, could the authors please address the comments and republish the draft. Loa and George Loa Andersson wrote: > Working group, > > this is to initiate a two week working group last call on: > > draft-ietf-mpls-ldp-igp-sync-01.txt > > Please send your comments to the working group mailing list or > to the working group chairs before April 11. > > 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Apr 14 03:18:10 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C383A6CE1; Mon, 14 Apr 2008 03:18:09 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C043A6A06 for ; Mon, 14 Apr 2008 03:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48V2ilxqNV+k for ; Mon, 14 Apr 2008 03:18:08 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 85D0E3A6CE1 for ; Mon, 14 Apr 2008 03:18:07 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 12:18:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 12:18:08 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C060C64A9@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt Thread-Index: AciOt90U0PeFnVFrRKeagc1XHaD+UwAc0cPwAVfDT1ACYYyg0A== References: From: To: X-OriginalArrivalTime: 14 Apr 2008 10:18:09.0655 (UTC) FILETIME=[D694F870:01C89E18] Cc: mpls@ietf.org Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Luyuan, Thanks for your detailed answers. More in-line. Bruno > De=A0: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > = > Hi Bruno, > = > Thank you for the comments. Please see in-line. > = > > -----Original Message----- > > > > Hi Markus, Alia, Luyuan, all, > > > > A few comments: > > > > 1) May be the document should talk about its interaction with > > graceful restart. (I guess this document should not be used > > when GR is used, unless GR is aborted or failed.). > > > = > Very good point. Let's try to look the relationship between LDP-IGP > synch (LDP-IGP) and Graceful Restart (GR). In fact, LDP-IGP is also used > when GR is used. > = > There are LDP GR [RFC 3478] and IGP GR - OSPF GR [RFC 3623] and ISIS GR > [RFC 3847]. > = > A. LDP GR and LDP-IGP synch: > = > LDP GR provides a mechanism to minimize the impact on MPLS labeled > traffic caused by LSR's control plane restart. LDP GR is taking the > proactive approach. > = > LDP-IGP synch is reactive, it provides the exchange and synch action > between LDP and IGP when LDP is already failed. It prevents router > sending traffic to the path where IGP is up and LDP is down. > = > There are many occasions you don't have a chance to gracefully restart. > E.g. bring up a new link; operational error - missed to configure LDP; > implementation error causes label corruption, etc. > = > Both LDP GR and LDP-IGP synch provide labeled traffic protection under > different conditions. Agreed: both GR and LDP-IGP sync have value and can be enabled on the same = router at the same time. My point was that for a given failure, only one of mechanism should take ca= re of the failure. So if GR handle the failure, eg LDP session failure, LDP= -IGP sync should not change the IGP link cost. > B. IGP GR and LDP-IGP synch > = > IGP GR or non-stop forwarding (NSF) is to keep IGP router stay on the > forwarding path even as its IGP is restarted. > = > An IGP instance performing NSF should honor the LDP-IGP synch procedure > to check the LDP-IGP synch parameter on the standby routing device. Do you mean: what should we do if between two neighbor routers, IGP GR is w= orking but is still underway while LDP GR failed? I didn't think of this specific interaction but the subject of interaction = between IGP and LDP GR procedures seems broad. I don't have detailed knowle= dge of IS-IS GR, but in general to stay in the safe area, it seems that the= IGP topology should not change during the IGP GR procedure. So in this cas= e, what should be the LDP-IGP sync behavior? Note that these GR interactions are not specific to the IGP-LDP sync draft.= Eg: what should we do if IGP GR succeed and BGP GR failed? (for a node pro= ving connectivity between two ASBRs of the same AS where tunneling (MPLS or= IP) is not used). so we can probably keep this out of this draft > IGP GR protects traffic during the switch over. LDP-IGP protects labeled > traffic from being blackholed when LDP is faulty for some reason while > IGP is still up. > = > > > > 2) " While the link could still be used for IP forwarding, it > > is not useful for traffic with packets carrying a label stack > > of more than one label or when the IP address carried in the > > packet is out of the > > RFC1918 space." > > > > It seems that the use of RFC 1918 IP address is just an > > example. One could find others (eg BGP free core). > > Proposition to change to " While the link could still be used > > for IP forwarding, it is not useful for MPLS forwarding (e.g. > > MPLS VPN, BGP free core.)" > > > = > Agreed. We can used both examples. > = > How about we say "While the link could still be used for IP forwarding, > it is not useful for MPLS forwarding, e.g., MPLS VPN; BGP route free > core; IP address carried in the packet is out of the RFC1918 space, > etc."? Fine, thanks. > > > > 3) "The LDP protocol itself has currently no means to > > indicate to a service depending on it whether there is an > > uninterrupted label switched path available to the desired > > destination or not." > > > > Eventually, it could be useful to say why LDP ordered mode + > > FEC withdraw is not an existing mean. > = > LDP is not a routing protocol. IGP directs the traffic to the shortest > path regardless there is an established LSP along the path or not. Under > the LDP down and IGP up condition: When LDP Ordered Control is used, the > labeled packets drop happens at the LSR of the ingress of network as LSP > cannot be established on the shortest path selected by IGP; When > Independent Control is used, the labeled packets drop happens at the LSR > where LDP failed (could be a mid point in the LSP) as the LSP is broken. > We have seen both blackholing cases in live networks. For more details > on LDP blackholing problems and solution, also see "LDP Failure > Detection and Recovery", by L. Fang, A. Atlas, F. Chiussi, K. Kompella, > and G. Swallow, IEEE Communications Vol.42 No.10, October 2004. > = > > Or may be you want to say that LDP has currently no way to > > correct the issue, for example by using a different IGP path. > > > = > Yes, thanks. We can re-word this similar as you suggested: LDP has > currently no way to correct the issue. LDP is not a routing protocol, it > cannot re-direct traffic to an alternate IGP path. Fine, thanks. > = > > 4) "In the case of OSPF this cost is LSInfinity (16-bit value > > 0xFFFF) as proposed in [RFC3137]." > > > > Could you also indicate the metric to use for IS-IS? > > Especially since: > > - further in the doc you recommend that all implementation > > use the same metric to avoid asymmetric link cost > > - RFC 3784 seems to indicate that the max metric link (2^24 - > > 1) is already reserved > > > = > Very good point. > We shall add the ISIS max metric in the draft. The max metric value for > ISIS using wide metrics is 0xFFFFFE per RFC 3784. = Thanks. > = > > 5) "It is recommended that both sides of a link implement > > this mechanism to be effective and to avoid asymmetric link > > costs which could cause problems with IP multicast forwarding." > > > > Avoiding asymetric link cost during all the procedure would > > require that both routers sharing the LDP session have the > > same way to detect when "LDP is considered fully > > operational". This is currently not the case. > = > Understood. It is a recommendation for better performance, not a > requirement. > = > > As the document propose to wait "some time", the document > > could possibly propose a default value for this timer and > > warn that if the operator wish to change that value, it > > should change it on both side of the LDP session. > > > = > We prefer not to set the hold-down timer with a default value. The > reason is that the LIB tables size can vary largely, as well the > equipment capability/speed. If the default value is too small, this > function would not work; if it is too big, it slows down the convergence > time. But the hold-down time guidelines through equipment testing would > be helpful. You're right but this discussion could apply to lot of default timers. Eg G= R timers. Yet most specification defines default values for their timers. > LDP End-of-LIB (draft-asati-mpls-ldp-end-of-lib-01.txt) is currently a > work in progress. When End-of-LIB is implemented, it can signal the end > of IGP hold-down time, no longer need for the configured nor default > timers. OK, given this, I guess it's not a big deal not to define default value for= the timers. May be the document could say that such LDP sync mechanism (LD= P End of LIB) should preferably be used (over timers) once they are availab= le. (in order to avoid asymmetric routing) > > Also, as there is a risk of transient asymetric link cost > > (because the end of the procedure is not stricly defined) > > could you possibly provide more precision on the problems > > that could be faced by IP multicast? > > > = > Yes, transient asymmetric cost is always a risk, it is not just for this > problem, it is rather a common problem. e.g. it is same as in BGP. We > would treat it as out of scope for this draft. Ok but this document: - Specifically states that asymmetric links cost could cause problem with m= ulticast ("asymmetric link costs [which] could cause problems with IP multi= cast forwarding") - In the short term (waiting for LDP end-of-LIB) does not fully avoid asymm= etric link cost. Quite the contrary, compared to doing nothing, it creates = new opportunity for this. So could the draft just list (or reference a document describing) multicast= issues with IGP asymmetric cost? Otherwise, as a service provider proving = IP, MPLS VPN and multicast on the same AS, while LDP end-of-LIB is not avai= lable, I wonder if I should use this draft or not as the draft says it impr= oves MPLS VPN availability but could create issues with multicast. > > Thanks, > > Regards, > > Bruno > > > = > Thanks, > Luyuan > = > = > > > From Loa Andersson > > > > > > Working group, > > > > > > this is to initiate a two week working group last call on: > > > > > > draft-ietf-mpls-ldp-igp-sync-01.txt > > > > > > Please send your comments to the working group mailing list > > or to the > > > working group chairs before April 11. > > > > > > 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@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Apr 14 06:02:00 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FFF3A6A83; Mon, 14 Apr 2008 06:02:00 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785AC3A68F2 for ; Mon, 14 Apr 2008 06:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMI05psA+gIH for ; Mon, 14 Apr 2008 06:01:55 -0700 (PDT) Received: from mail.swisscom.com (outmail20.swisscom.com [138.190.32.10]) by core3.amsl.com (Postfix) with ESMTP id 13C843A6B50 for ; Mon, 14 Apr 2008 06:01:54 -0700 (PDT) Received: by mrz.swissptt.ch; Mon, 14 Apr 2008 15:02:22 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 15:02:17 +0200 Message-ID: <83C3187535FAC0408E9B03456DDBB3A601592221@sg1492p.corproot.net> In-Reply-To: <6499201801FBC6419ED8C910302F67AC05540840@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] error response to mpls data packets Thread-Index: Acia9IZRDKITOiTYT7eJALWA2r22ngANka5wAMD1lDA= References: <1202104968.S.1689.8898.f5mail-237-203.rediffmail.com.old.1207822905.20267@webmail.rediffmail.com> <6499201801FBC6419ED8C910302F67AC05540840@xmb-blr-417.apac.cisco.com> From: To: , , X-OriginalArrivalTime: 14 Apr 2008 13:02:18.0856 (UTC) FILETIME=[C529C680:01C89E2F] Subject: Re: [mpls] error response to mpls data packets X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1580615817==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============1580615817== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89E2F.C4ECD0D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89E2F.C4ECD0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I personally agree with Anup. =20 Besides the implementation based insights of RFC's 4377, 4378, 4379 perhaps a browse through the following book can also be of assistance in order to understand how MPLS-OAM can be used to detect failures that the control plane is unaware of: =20 "MPLS-Enabled Applications", Chapter 12.3.2 by Ina Minei and Julian Lucek =20 Cheers =20 Santanu Ganguly ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Anup Kumar Vasudevan (anuvasud) Sent: Thursday, April 10, 2008 7:05 PM To: anshu ; mpls@uu.net; mpls@ietf.org Subject: Re: [mpls] error response to mpls data packets Hi=20 =20 Will RFC 4379 not suit your purpose? This is the RFC that defines MPLS OAM - look at 4377 and 4378 for a framework and requirements of OAM. However, if R2 is not part of the IP network, the MPLS n/w will terminate at R2 i.e. the R1-R2 will be one LSP and R2-R3 will be a different LSP?=20 =20 Also within the OAM RFC you might have to look more at the Downstream Mapping TLV. However in case of a failure at R2, it should be able to handle the MPLS Echo request packet which is a UDP packet, with the Label stack of the LSP being used, and with a destination address in the Local loopback region of IPv4/IPV6.=20 =20 Regards Anup Vasudevan ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of anshu=20 Sent: Thursday, April 10, 2008 3:52 PM To: mpls@uu.net; mpls@lists.ietf.org Subject: [mpls] error response to mpls data packets Hi, MPLS LSPs can span across different type of networks. Suppose LSP spans across R1,R2,R3 and R2 is not part of IP networks.=20 In that case how will the forwarding error is handled at R2 (incase its part of IP, ICMP error message can be sent to the source). I could not find any standard specs which talks about any generic implementation. Regards, Anshu =09 ------_=_NextPart_001_01C89E2F.C4ECD0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I personally agree with = Anup.
 
Besides the implementation based = insights of RFC's=20 4377, 4378, 4379 perhaps a browse through the following book can = also be of=20 assistance in order to understand how MPLS-OAM can be used to = detect=20 failures that the control plane is unaware of:
 
  "MPLS-Enabled Applications", Chapter = 12.3.2 by=20 Ina Minei and Julian Lucek
 
Cheers
 
Santanu Ganguly

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Anup Kumar Vasudevan=20 (anuvasud)
Sent: Thursday, April 10, 2008 7:05 = PM
To: anshu=20 ; mpls@uu.net; mpls@ietf.org
Subject: Re: [mpls] error = response to=20 mpls data packets

Hi
 
Will RFC 4379 not suit your purpose? This is = the RFC=20 that defines MPLS OAM - look at 4377 and 4378 for a framework and = requirements=20 of OAM. However, if R2 is not part of the IP network, the MPLS n/w will=20 terminate at R2  i.e. the R1-R2 will be one LSP and R2-R3 will be a = different LSP?
 
Also within the OAM RFC you might have to = look more at=20 the Downstream Mapping TLV. However in case of a failure at R2, it = should be=20 able to handle the MPLS Echo request packet which is a UDP packet, with = the=20 Label stack of the LSP being used, and with a destination address in the = Local=20 loopback region of IPv4/IPV6.
 
Regards
Anup Vasudevan

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of anshu =
Sent:=20 Thursday, April 10, 2008 3:52 PM
To: mpls@uu.net;=20 mpls@lists.ietf.org
Subject: [mpls] error response to mpls = data=20 packets

Hi,
MPLS LSPs can span across different type of=20 networks.
Suppose LSP spans across R1,R2,R3 and R2 is not part of IP=20 networks.
In that case how will the forwarding error is handled at = R2=20 (incase its part of IP, ICMP error
message can be sent to the = source). I=20 could not find any standard specs which talks about any=20 generic
implementation.

Regards,
Anshu

------_=_NextPart_001_01C89E2F.C4ECD0D0-- --===============1580615817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1580615817==-- From mpls-bounces@ietf.org Mon Apr 14 07:22:50 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4C93A687A; Mon, 14 Apr 2008 07:22:50 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95FBF3A6973 for ; Mon, 14 Apr 2008 07:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=1.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUT9Px9o6EJ7 for ; Mon, 14 Apr 2008 07:22:41 -0700 (PDT) Received: from n2a.bullet.in.yahoo.com (n2a.bullet.in.yahoo.com [202.43.219.19]) by core3.amsl.com (Postfix) with SMTP id C7CCE3A687A for ; Mon, 14 Apr 2008 07:22:39 -0700 (PDT) Received: from [202.86.4.171] by n2.bullet.in.yahoo.com with NNFMP; 14 Apr 2008 14:21:04 -0000 Received: from [203.104.18.51] by t2.bullet.in.yahoo.com with NNFMP; 14 Apr 2008 14:21:04 -0000 Received: from [127.0.0.1] by omp112.mail.in2.yahoo.com with NNFMP; 14 Apr 2008 14:21:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 309700.21940.bm@omp112.mail.in2.yahoo.com Received: (qmail 13075 invoked by uid 60001); 14 Apr 2008 14:21:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=2O5tPwsiU01x9rlEH6rJ3b0OvNuwbP0LNXf001bJdqu0eMtRcdltqmB/L6KqkXkMKD6mAWPVM+rPMqeoQNTkRLgIj1x1azQK+AXXN90o6fqV5DvEUmK6Fssk7BRJ47R1UjoTf8/SjXJkpGkiGzTrbqEiY836P3kfifbHW6JAxQI=; X-YMail-OSG: 44KcmjcVM1mODIJOlbcNhDrSAE2R.YvTercCAjYlpKsZjnWby8wcwlgIT.H1BAUgiLaqXvmhwj4VL864Mwfa6RDXip3QvfmIcvpGmp4Auf0BPKdRhaAn8ByTau64vQ-- Received: from [125.17.142.38] by web94604.mail.in2.yahoo.com via HTTP; Mon, 14 Apr 2008 19:51:04 IST X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Mon, 14 Apr 2008 19:51:04 +0530 (IST) From: priyanka gupta To: mpls@ietf.org MIME-Version: 1.0 Message-ID: <272170.12874.qm@web94604.mail.in2.yahoo.com> Subject: [mpls] Doubts in RFC 5036 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1307106246==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============1307106246== Content-Type: multipart/alternative; boundary="0-2026373904-1208182864=:12874" --0-2026373904-1208182864=:12874 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,=0A=0AI was analysising the LDP RFC and wasnot able to get the reaso= n for few events declared.=0A=0A1)Need of keep aive timer over TCP session.= Cannt the TCP keep alive is enough to maintain teh integrity of session?=0A= =0A2) In RFC it is written deletion of adjacency will delete the session.Re= fer section 2.5.5.but vise versa is not clear.=0A Will session deletion = also deletes the adjacency?As per my understanding whats the need of mainta= ining adjacency when session establishment parameter are failed in negotiat= ion.=0A=0A=0Aregards,=0APriyanka=0A=0A=0A From Chandigarh to Chennai -= find friends all over India. Go to http://in.promos.yahoo.com/groups/cityg= roups/ --0-2026373904-1208182864=:12874 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
 
=0A
I was analysi= sing the LDP RFC and wasnot able to get the reason for few events decl= ared.
=0A
 
=0A
1)Need of keep aive timer over TCP s= ession.Cannt the TCP keep alive is enough to maintain teh integrity of sess= ion?
=0A
 
=0A
2) In RFC it is written deletion of a= djacency will delete the session.Refer section 2.5.5.but vise versa is not = clear.
=0A
    Will session deletion also deletes t= he adjacency?As per my understanding whats the need of maintaining adjacenc= y when session establishment parameter are failed in negotiation.
=0A<= DIV> 
=0A
 
=0A
regards,
=0A
Priyanka<= /DIV>

=0A=0A=0A
Unlimited freedom,= unlimited storage. Get it now= --0-2026373904-1208182864=:12874-- --===============1307106246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1307106246==-- From mpls-bounces@ietf.org Mon Apr 14 09:48:01 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35ABD3A67D8; Mon, 14 Apr 2008 09:48:01 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D18C3A67D8 for ; Mon, 14 Apr 2008 09:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW44qaLT5Lic for ; Mon, 14 Apr 2008 09:47:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0B5203A6780 for ; Mon, 14 Apr 2008 09:47:58 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2008 09:48:29 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3EGmTNM006215; Mon, 14 Apr 2008 09:48:29 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3EGmSws018213; Mon, 14 Apr 2008 16:48:28 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 12:48:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 12:48:26 -0400 Message-ID: In-Reply-To: <48031D97.5010706@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Ended: wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt Thread-Index: AcieDmOL7Jrenb1IRrid2Fxykb1yrQAQONnw From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , "Ross Callon" , "David Ward" X-OriginalArrivalTime: 14 Apr 2008 16:48:26.0776 (UTC) FILETIME=[5C461180:01C89E4F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1214; t=1208191709; x=1209055709; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lufang@cisco.com; z=From:=20=22Luyuan=20Fang=20(lufang)=22=20 |Subject:=20RE=3A=20[mpls]=20Ended=3A=20wg=20last=20call=20 on=20draft-ietf-mpls-ldp-igp-sync-01.txt |Sender:=20; bh=On6qdbz9SyH0lwAEhgF1Lak8QJiRuMphnwZHPjlZFYo=; b=oNu+YLtxNkn9W47XAW3VZ2njmZl2y5taiG/ZD6suBgVzpeTOMsuLkqAWom 7xp+ej/KXSC3mGVw8nNh9OeSvRbr9a9vwHHEjLKgCU55MxMX3+TVVZIvSeCa GFrjStsMQE; Authentication-Results: sj-dkim-4; header.From=lufang@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [mpls] Ended: wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Will do. Thanks, Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 14 April 2008 05:02 To: mpls@ietf.org; Ross Callon; David Ward Subject: [mpls] Ended: wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt Working Group, this working group last call has ended. There has been comments, could the authors please address the comments and republish the draft. Loa and George Loa Andersson wrote: > Working group, > > this is to initiate a two week working group last call on: > > draft-ietf-mpls-ldp-igp-sync-01.txt > > Please send your comments to the working group mailing list or to the > working group chairs before April 11. > > 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Apr 15 04:18:35 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CAA28C3B2; Tue, 15 Apr 2008 04:18:35 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE033A6E45 for ; Tue, 15 Apr 2008 04:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DVH2VB1eCJ8 for ; Tue, 15 Apr 2008 04:18:33 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 54E9A28C3B1 for ; Tue, 15 Apr 2008 04:18:27 -0700 (PDT) Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 15 Apr 2008 16:48:54 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3FBIoI8022944; Tue, 15 Apr 2008 16:48:50 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3FBIYG1014229; Tue, 15 Apr 2008 11:18:48 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 16:48:48 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 16:52:38 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC0554126C@xmb-blr-417.apac.cisco.com> In-reply-to: <272170.12874.qm@web94604.mail.in2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Doubts in RFC 5036 Thread-Index: AcieOyCt0wg3exu9RgOTQPIkJxI+RgAre5kQ References: <272170.12874.qm@web94604.mail.in2.yahoo.com> From: "Anup Kumar Vasudevan (anuvasud)" To: "priyanka gupta" , X-OriginalArrivalTime: 15 Apr 2008 11:18:48.0619 (UTC) FILETIME=[79FC8FB0:01C89EEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6556; t=1208258330; x=1209122330; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anuvasud@cisco.com; z=From:=20=22Anup=20Kumar=20Vasudevan=20(anuvasud)=22=20 |Subject:=20RE=3A=20[mpls]=20Doubts=20in=20RFC=205036 |Sender:=20; bh=tpvz780AR+HsAF5WcuCuco/R3AOPUx44JUeCdq6EqgE=; b=Yxnz6m8AGBKqabWjLX0OTPaVCdxf673SKPYKOgIhGgRQAj0D5h7KUMvyCg nLqJew7B+Q4cFgPBTJ9UlK8ZPflChco4zk4x2JEN+MmVcHCmFc/v+98X7koW OMpkxgdrI6; Authentication-Results: ind-dkim-1; header.From=anuvasud@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Subject: Re: [mpls] Doubts in RFC 5036 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331014236==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============0331014236== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89EEA.79E52570" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89EEA.79E52570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 =20 My attempt at explaining -=20 =20 1. We use the LDP keep alive message to setup the session. When we get the session init message we reply with a keep alive message. The keep alive timer is only used to maintain the TCP session. We do not need to use the TCP keep alive messages for LDP. Using TCP keep alives will probably result in unnecessary n/w traffic. The LSR's can recevie any LDP message in order to keep the session alive (keep alive timer from expiring). If LSR's dont have any info to exchange a keep alive message is used.=20 =20 2. When LSR's exchange hello's they will be able to setup adjacencies. With the Adjacency configured the session setup can be done. In case the session params do not match the session setup wiill fail but the adjacency will remain until timer expiry. I think this is for trouble shooting purposes. Atleast thats what i have used it for. o/w we cannot distinguish between a failed adjaceny setup and a failed session setup.=20 =20 Thanks and Regards Anup Vasudevan ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of priyanka gupta Sent: Monday, April 14, 2008 7:51 PM To: mpls@ietf.org Subject: [mpls] Doubts in RFC 5036 Hi all, =20 I was analysising the LDP RFC and wasnot able to get the reason for few events declared. =20 1)Need of keep aive timer over TCP session.Cannt the TCP keep alive is enough to maintain teh integrity of session? =20 2) In RFC it is written deletion of adjacency will delete the session.Refer section 2.5.5.but vise versa is not clear. Will session deletion also deletes the adjacency?As per my understanding whats the need of maintaining adjacency when session establishment parameter are failed in negotiation. =20 =20 regards, Priyanka ________________________________ Unlimited freedom, unlimited storage. Get it now =20 ------_=_NextPart_001_01C89EEA.79E52570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
My attempt at explaining -
 
1. We use the LDP keep alive message to setup = the session.=20 When we get the session init message we reply with a keep alive message. = The=20 keep alive timer is only used to maintain the TCP session. We do not = need to use=20 the TCP keep alive messages for LDP. Using TCP keep alives will probably = result=20 in unnecessary n/w traffic. The LSR's can recevie any LDP message in = order to=20 keep the session alive (keep alive timer from expiring). If LSR's = dont have=20 any info to exchange a keep alive message is used.
 
2. When LSR's exchange hello's they will be = able to setup=20 adjacencies. With the Adjacency configured the session setup can be = done. In=20 case the session params do not match the session setup wiill fail but = the=20 adjacency will remain until timer expiry. I think this is for trouble = shooting=20 purposes. Atleast thats what i have used it for. o/w we cannot = distinguish=20 between a failed adjaceny setup and a failed session setup. =
 
Thanks and Regards
Anup Vasudevan

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of priyanka=20 gupta
Sent: Monday, April 14, 2008 7:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Doubts in RFC = 5036

Hi all,
 
I was analysising the LDP RFC and wasnot able to get the = reason for=20 few events declared.
 
1)Need of keep aive timer over TCP session.Cannt the TCP keep alive = is=20 enough to maintain teh integrity of session?
 
2) In RFC it is written deletion of adjacency will delete the = session.Refer=20 section 2.5.5.but vise versa is not clear.
    Will session deletion also deletes the = adjacency?As per=20 my understanding whats the need of maintaining adjacency when session=20 establishment parameter are failed in negotiation.
 
 
regards,
Priyanka

Unlimited freedom, unlimited storage. Get=20 it now ------_=_NextPart_001_01C89EEA.79E52570-- --===============0331014236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0331014236==-- From mpls-bounces@ietf.org Tue Apr 15 04:40:29 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08F03A6DD2; Tue, 15 Apr 2008 04:40:28 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF883A6C22 for ; Tue, 15 Apr 2008 04:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M798ITqFQhsc for ; Tue, 15 Apr 2008 04:40:27 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id 19DAD3A6E55 for ; Tue, 15 Apr 2008 04:40:08 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JljWh-0000sW-QO for mpls@ietf.org; Tue, 15 Apr 2008 13:40:39 +0200 Received: from pat.acreo.se ([217.151.195.214]:9721 helo=[10.4.144.171]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JljWe-0000sQ-J2 for mpls@ietf.org; Tue, 15 Apr 2008 13:40:36 +0200 Message-ID: <48049402.2050802@pi.se> Date: Tue, 15 Apr 2008 13:39:46 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org References: <47F0A26B.3050802@pi.se> In-Reply-To: <47F0A26B.3050802@pi.se> X-Enigmail-Version: 0.95.6 Subject: [mpls] wg last call on draft-ietf-mpls-p2mp-te-mib-06.txt - EXTENDED X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, we have been running this wg last call for two weeks, but we have not seen any comments; the wg last call is therefore extended to April 25. Loa and George Loa Andersson wrote: > Hi MPLS chairs, > > This is to initiate a working group last call on > P2MP MPLS-TE MIB module > . > > The MIB module has been through an earl MIB Dr. review and > there has also been comments from experienced MIB implementors. > This resulted in various updates and version - 06 is the > result of this process. > > Please send your comments to the working group mailing list or > to the working group chairs not later than April 13. > > 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Apr 15 21:24:41 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C01C3A6A1C; Tue, 15 Apr 2008 21:24:41 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455663A6A1C for ; Tue, 15 Apr 2008 21:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_92=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMdrspQ021ud for ; Tue, 15 Apr 2008 21:24:39 -0700 (PDT) Received: from n2a.bullet.in.yahoo.com (n2a.bullet.in.yahoo.com [202.43.219.19]) by core3.amsl.com (Postfix) with SMTP id 533133A6838 for ; Tue, 15 Apr 2008 21:24:38 -0700 (PDT) Received: from [202.86.4.170] by n2.bullet.in.yahoo.com with NNFMP; 16 Apr 2008 04:25:11 -0000 Received: from [203.104.18.52] by t1.bullet.in.yahoo.com with NNFMP; 16 Apr 2008 04:25:11 -0000 Received: from [127.0.0.1] by omp113.mail.in2.yahoo.com with NNFMP; 16 Apr 2008 04:25:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 532461.97770.bm@omp113.mail.in2.yahoo.com Received: (qmail 96488 invoked by uid 60001); 16 Apr 2008 04:25:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=uofpfHwk6LZeUw+vlSeFRa09aff15hPMQ69hXBNlg16O5irCJMUnx+5yz4cpbpcGPlN8snm7DB63Hb32vIalC7rHkCYoIeOpX/FrtfKSW0HV4rj+JDVNe3YfmDAlnlllBwiDmEjteiOK18tpAaQcya/gSdXZTo5pGZ8z3oHAlBE=; X-YMail-OSG: sjgxGDEVM1ltO_NEbRBSgoKmYP8XiYXiDwDODs_g8_G8F44uBRmGuMqZpOR43W6DMdoiCv_4Wm_._8_qrQ_Jat823e7yreo- Received: from [125.17.142.38] by web94613.mail.in2.yahoo.com via HTTP; Wed, 16 Apr 2008 09:55:10 IST X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Wed, 16 Apr 2008 09:55:10 +0530 (IST) From: priyanka gupta To: "Anup Kumar Vasudevan \(anuvasud\)" , mpls@ietf.org MIME-Version: 1.0 Message-ID: <697433.96455.qm@web94613.mail.in2.yahoo.com> Subject: Re: [mpls] Doubts in RFC 5036 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0709561511==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============0709561511== Content-Type: multipart/alternative; boundary="0-2020078058-1208319910=:96455" --0-2020078058-1208319910=:96455 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Vasu .=0A=0AI still have one doubt in second explaination.=0AIf sess= ion parameters donot match and adjacent or targeted peer are periodically s= ending the hello messages ,in that case adjacency will be present but no s= ession.As per state machine the peer will again try to establish the sessio= n again the negotiation fails...this processess will continue for 2min(as p= er RFC).atfter that no retry for session establishment.In this case too,do = i need to maintain the adjacency?still is there any need to send the hello= packets to the peer who is not atall ready to establish a session.=0A=0Awh= at I can say is delete adjacency and stop sending hello packet too.And this= activity should be noticed by operator.Correct me if im wrong.=0A=0Athanks= & regards,=0APriyanka Gupta=0A=0A=0A----- Original Message ----=0AFrom: An= up Kumar Vasudevan (anuvasud) =0ATo: priyanka gupta ; mpls@ietf.org=0ASent: Tuesday, 15 April, 2008 4:52:38 = PM=0ASubject: RE: [mpls] Doubts in RFC 5036=0A=0A=0AHi =0A =0AMy attempt at= explaining - =0A =0A1. We use the LDP keep alive message to setup the sess= ion. When we get the session init message we reply with a keep alive messag= e. The keep alive timer is only used to maintain the TCP session. We do not= need to use the TCP keep alive messages for LDP. Using TCP keep alives wil= l probably result in unnecessary n/w traffic. The LSR's can recevie any LDP= message in order to keep the session alive (keep alive timer from expiring= ). If LSR's dont have any info to exchange a keep alive message is used. = =0A =0A2. When LSR's exchange hello's they will be able to setup adjacencie= s. With the Adjacency configured the session setup can be done. In case the= session params do not match the session setup wiill fail but the adjacency= will remain until timer expiry. I think this is for trouble shooting purpo= ses. Atleast thats what i have used it for. o/w we cannot distinguish betwe= en a failed adjaceny setup and a failed session setup. =0A =0AThanks and Re= gards=0AAnup Vasudevan=0A=0A=0A=0A=0AFrom: mpls-bounces@ietf.org [mailto:mp= ls-bounces@ietf.org] On Behalf Of priyanka gupta=0ASent: Monday, April 14, = 2008 7:51 PM=0ATo: mpls@ietf.org=0ASubject: [mpls] Doubts in RFC 5036=0A=0A= =0AHi all,=0A =0AI was analysising the LDP RFC and wasnot able to get the r= eason for few events declared.=0A =0A1)Need of keep aive timer over TCP ses= sion.Cannt the TCP keep alive is enough to maintain teh integrity of sessio= n?=0A =0A2) In RFC it is written deletion of adjacency will delete the sess= ion.Refer section 2.5.5.but vise versa is not clear.=0A Will session del= etion also deletes the adjacency?As per my understanding whats the need of = maintaining adjacency when session establishment parameter are failed in ne= gotiation.=0A =0A =0Aregards,=0APriyanka=0A=0A=0A=0AUnlimited freedom, unli= mited storage. Get it now=0A=0A=0A Bollywood, fun, friendship, sports = and more. You name it, we have it on http://in.promos.yahoo.com/groups/best= ofyahoo/ --0-2020078058-1208319910=:96455 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Vasu .
=0A
 
=0AI still have one doubt in second explaination.
=0A
= If session parameters donot match and adjacent or targeted peer are periodi= cally sending  the hello messages ,in that case adjacency will be pres= ent but no session.As per state machine the peer will again try to establis= h the session again the negotiation fails...this processess will continue f= or 2min(as per RFC).atfter that no retry for session establishment.In this = case too,do  i need to maintain the adjacency?still is there any need = to send the hello packets to the peer who is not atall ready to establish a= session.
=0A
 
=0A
what I can say is dele= te adjacency and stop sending hello packet too.And this activity should be = noticed by operator.Correct me if im wrong.
=0A
 
= =0A
thanks & regards,
=0A
Priyanka Gupta

=
=0A
----- Original Message ----
From: Anup Kumar Vasudeva= n (anuvasud) <anuvasud@cisco.com>
To: priyanka gupta <busybee_p= g@yahoo.com>; mpls@ietf.org
Sent: Tuesday, 15 April, 2008 4:52:38 PM<= BR>Subject: RE: [mpls] Doubts in RFC 5036

=0A=0A=0A
Hi
=0A
 
= =0A
My attempt at explaining - =
=0A
 
=0A
1. We use the LDP keep alive message to setup the se= ssion. When we get the session init message we reply with a keep alive mess= age. The keep alive timer is only used to maintain the TCP session. We do n= ot need to use the TCP keep alive messages for LDP. Using TCP keep alives w= ill probably result in unnecessary n/w traffic. The LSR's can recevie any L= DP message in order to keep the session alive (keep alive timer from e= xpiring). If LSR's dont have any info to exchange a keep alive message is u= sed.
=0A
&nb= sp;
=0A
2. When LSR's exchange hello's th= ey will be able to setup adjacencies. With the Adjacency configured the ses= sion setup can be done. In case the session params do not match the session= setup wiill fail but the adjacency will remain until timer expiry. I think= this is for trouble shooting purposes. Atleast thats what i have used it f= or. o/w we cannot distinguish between a failed adjaceny setup and a failed = session setup.
=0A
=  
=0A
Thanks and Regards
=0A
Anup Vasudevan

=0A
=0A
=0AFrom: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of pr= iyanka gupta
Sent: Monday, April 14, 2008 7:51 PM
To: m= pls@ietf.org
Subject: [mpls] Doubts in RFC 5036

=0A
=0A
=0A
Hi all,
=0A
 
=0A<= DIV>I was analysising the LDP RFC and wasnot able to get the reason fo= r few events declared.
=0A
 
=0A
1)Need of keep aive= timer over TCP session.Cannt the TCP keep alive is enough to maintain teh = integrity of session?
=0A
 
=0A
2) In RFC it is writ= ten deletion of adjacency will delete the session.Refer section 2.5.5.but v= ise versa is not clear.
=0A
    Will session deleti= on also deletes the adjacency?As per my understanding whats the need of mai= ntaining adjacency when session establishment parameter are failed in negot= iation.
=0A
 
=0A
 
=0A
regards,
= =0A
Priyanka

=0A
=0AUnlimited freedom, unlim= ited storage. Get it now
=0A


=0A=0A= =0A
Meet people who discuss and share your = passions. Join them now. --0-2020078058-1208319910=:96455-- --===============0709561511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0709561511==-- From mpls-bounces@ietf.org Wed Apr 16 23:52:17 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D52A3A6A0A; Wed, 16 Apr 2008 23:52:17 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B613A6A0A for ; Wed, 16 Apr 2008 23:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fTlUI87vJsf for ; Wed, 16 Apr 2008 23:52:15 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id EA5B63A69B7 for ; Wed, 16 Apr 2008 23:52:14 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 2so1435248ywt.49 for ; Wed, 16 Apr 2008 23:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=i4O4ns/Dn7wxTeuqQc1ZrxGFV4OlbM4zWi/0/QeWb2A=; b=RuhIGGLV5wsKcH1peB234CCP6FXD+3I4AQJeLnniWu+msHmYkl+PEAfdg4NaGKstdzE7y+mHQexAewvSo5kyVcKDx8El5vLUxPhLkoaZrZnSIUqcNC9QGYodVl397wpJHi0ungVDmRcyHcirC3gweoxdaDZBfc08y+u5Thokvc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=iSR1Bbvtk6otqO0UL8dsJnebg1jWQMshZt69Mp2vS0HKn/jFD5PZqHqV3QnvdvwoJouVAAFSkJRYLog6xKRK7VMaDP+BJGjiUMYVqL3zCRXQOwm5/0F8isZbJNLM7+8Sppwh8PajimuLCyhYnY1sD472zb95Gf2aX23oXu7bZ0Q= Received: by 10.150.186.21 with SMTP id j21mr1160274ybf.230.1208415167520; Wed, 16 Apr 2008 23:52:47 -0700 (PDT) Received: by 10.151.6.6 with HTTP; Wed, 16 Apr 2008 23:52:47 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 12:22:47 +0530 From: "Santosh P K" To: mpls@ietf.org MIME-Version: 1.0 Subject: [mpls] draft-kompella-mpls-multiarea-te-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0947767457==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============0947767457== Content-Type: multipart/alternative; boundary="----=_Part_8741_20936473.1208415167479" ------=_Part_8741_20936473.1208415167479 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, There was one draft "draft-kompella-mpls-multiarea-te-04.txt" for inter-area LSP establishment which got expired on December 2003. After that I cant see any updates for the same in IETF. Can you please let me know what is the status of this draft or is there any RFC for the same. Thanks and regards Santosh P K ------=_Part_8741_20936473.1208415167479 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
     There was one draft "draft-kompella-mpls-multiarea-te-04.txt" for inter-area LSP establishment which got expired on  December 2003. After that I cant see any updates for the same in IETF. Can you please let me know what is the status of this draft or is there any RFC for the same.
 
Thanks and regards
Santosh P K
------=_Part_8741_20936473.1208415167479-- --===============0947767457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0947767457==-- From mpls-bounces@ietf.org Thu Apr 17 02:12:57 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504D53A6823; Thu, 17 Apr 2008 02:12:56 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6713A67A5 for ; Thu, 17 Apr 2008 02:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYBTkVY6Hhb7 for ; Thu, 17 Apr 2008 02:12:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 0E9FB28C48B for ; Thu, 17 Apr 2008 02:12:51 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3H9DMYQ026170; Thu, 17 Apr 2008 10:13:22 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3H9DKbZ026117; Thu, 17 Apr 2008 10:13:21 +0100 Message-ID: <0a7b01c8a06b$46580ea0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Santosh P K" References: Date: Thu, 17 Apr 2008 10:13:13 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mpls@ietf.org Subject: Re: [mpls] draft-kompella-mpls-multiarea-te-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Santosh, You might look at... RFC4105 Requirements for Inter-Area MPLS Traffic Engineering RFC4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering RFC5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions RFC5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) RFC4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) RFC5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) In general, multi-domain TE work has found its way into CCAMP. You can also find some discussion of the path computation operations for inter-domain TE in the PCE working group. Cheers, Adrian ----- Original Message ----- From: "Santosh P K" To: Sent: Thursday, April 17, 2008 7:52 AM Subject: [mpls] draft-kompella-mpls-multiarea-te-04.txt > Hi All, > There was one draft "draft-kompella-mpls-multiarea-te-04.txt" for > inter-area LSP establishment which got expired on December 2003. After > that > I cant see any updates for the same in IETF. Can you please let me know > what > is the status of this draft or is there any RFC for the same. > > Thanks and regards > Santosh P K > -------------------------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 17 02:41:40 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D45E3A7008; Thu, 17 Apr 2008 02:41:40 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0543A6FEB; Thu, 17 Apr 2008 02:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FARhff6ppFkz; Thu, 17 Apr 2008 02:41:31 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3196A28C521; Thu, 17 Apr 2008 02:40:30 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m3H9exee014442; Thu, 17 Apr 2008 12:40:59 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m3H9euHE014439; Thu, 17 Apr 2008 12:40:57 +0300 Date: Thu, 17 Apr 2008 12:40:56 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: <20080411190049.330E528C23B@core3.amsl.com> Message-ID: References: <20080411190049.330E528C23B@core3.amsl.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/6807/Thu Apr 17 01:25:48 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org On Fri, 11 Apr 2008, The IESG wrote: > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > > - 'MPLS Multicast Encapsulations ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. I did not look into this in detail because I claim no expertise in MPLS, but... I believe this document needs a normative reference to draft-ietf-mpls-upstream-label (now in Last Call) because the whole concept of upstream labels is introduced in that document and it seems vital to understanding and implementing this RFC. IANA considerations section should describe how IANA should reword the "unicast codepoint" and "multicast codepoint" assignment fields. It seems clear that these should be renamed to better reflect the reality introduced in this document. The document does not describe the impact (of lack thereof) of redefining the usage of existing codepoints and modifying existing standards (e.g. the MPLS-in-IP and MPLS-in-GRE encapsulation rules and what may or may not happen in a non-compliant decapsulator). Section 6 gives instructions how to handle unicast and multicast destination address. It does not describe how to handle the v4 255/8 broadcast address and it's debatable which category would apply if a packet was sent to a regular broadcast address such as 192.0.2.255/24. Should this be described for completeness or explicitly declared out of scope? editorial comment ----------------- Abstract is a bit long and has a typo: s/The former "multicast codepoint"/The latter "multicast codepoint" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 17 04:20:57 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E10F3A6C74; Thu, 17 Apr 2008 04:20:57 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680EB3A6867 for ; Thu, 17 Apr 2008 04:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gStoXafarHp8 for ; Thu, 17 Apr 2008 04:20:55 -0700 (PDT) Received: from n1a.bullet.in.yahoo.com (n1a.bullet.in.yahoo.com [202.43.219.18]) by core3.amsl.com (Postfix) with SMTP id 269C728C510 for ; Thu, 17 Apr 2008 04:20:46 -0700 (PDT) Received: from [202.86.4.170] by n1.bullet.in.yahoo.com with NNFMP; 17 Apr 2008 11:21:23 -0000 Received: from [203.104.18.44] by t1.bullet.in.yahoo.com with NNFMP; 17 Apr 2008 11:21:23 -0000 Received: from [127.0.0.1] by omp108.mail.in2.yahoo.com with NNFMP; 17 Apr 2008 11:21:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 930188.61351.bm@omp108.mail.in2.yahoo.com Received: (qmail 30496 invoked by uid 60001); 17 Apr 2008 11:21:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=WGHN+D8u5yRNO7MDd7kDkBQ8Lr6Fx120HQDeIMrmy7XQJYCuQYu+GO3IEQoNq+eVQXm0BmSeAa7KJN0wAAYlxt5C/76cJ6TJ5sbBavnmV9ISnPz0IcR4KFzimF5FA7qXEBzhXLfwImAJ9HVH+ogqPl5exlTPyrvShjwOTPbfATM=; X-YMail-OSG: cdvGs9wVM1mEjvhf5u_g_JI9J2a1FETXoOM5G26JmuhnqeWNa7pPJj4kiM6eQmT5H2bTSUqFU7kpBUXKzXzBj53j9KFKrZQ- Received: from [203.78.214.150] by web94607.mail.in2.yahoo.com via HTTP; Thu, 17 Apr 2008 16:51:22 IST X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 17 Apr 2008 16:51:22 +0530 (IST) From: priyanka gupta To: mpls@ietf.org MIME-Version: 1.0 Message-ID: <512593.26905.qm@web94607.mail.in2.yahoo.com> Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093973202==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============1093973202== Content-Type: multipart/alternative; boundary="0-958016678-1208431282=:26905" --0-958016678-1208431282=:26905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Comments:=0AI am not able to understand that how discouraging the IP forwar= ding over a link where LDP is not fully established help in LDP session est= ablishment.=0AAs you mentioned the reason for blackhole could be -configura= tion error or - An implementation bug. =0ACan you help me in uderstanding= this.=0ASecondly,=0A"It is recommended this that both side of a link imple= ment mechanism to be effective and to avoid asymmetric link costs which cou= ld =0A cause problems with IP multicast forwarding."=0Awhat exactly mean = by IP multicast forwarding problems?=0A=0A=0A Bring your gang together= .. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo= ..com/groups/ --0-958016678-1208431282=:26905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
Comments:
I am not able to und=
erstand that how discouraging the IP forwarding over a link where LDP is no=
t fully established help in LDP session establishment.
As=
 you mentioned the reason for blackhole could be -configuration error or - =
An implementation bug.   
Can you help me i=
n uderstanding this.
Secondly,
= 
"It is recommended this that both side of a link implement mechanism to be eff=
ective and to avoid asymmetric link costs which could=
 
   cause problems with IP multicast forwarding."
=
what exactly mean by IP multicast forwarding problems?

=0A=0A=0A=0A
Bollywo= od, fun, friendship, sports and more. You name it, we have it. --0-958016678-1208431282=:26905-- --===============1093973202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1093973202==-- From mpls-bounces@ietf.org Thu Apr 17 09:08:12 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3046D28C554; Thu, 17 Apr 2008 09:08:12 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EC83A7025 for ; Thu, 17 Apr 2008 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8f13EBPlBdh for ; Thu, 17 Apr 2008 09:07:58 -0700 (PDT) Received: from web51007.mail.re2.yahoo.com (web51007.mail.re2.yahoo.com [206.190.38.138]) by core3.amsl.com (Postfix) with SMTP id ABFDB3A6AA5 for ; Thu, 17 Apr 2008 09:06:51 -0700 (PDT) Received: (qmail 20930 invoked by uid 60001); 17 Apr 2008 16:07:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=HAY0OF+9zU6+7MruCmdXXRhnXZRLJ8f/QgiEb/LOn3YEaGM4egqLk7jtgiO1ORKyXFyx7onfXtU0Te4CUMGU2sIEEh28/HFoVGU1yOCSXhYYtxcLfirMeDNpHtkXSwU12jgG4IuzH+salnXmQSajPVnQf7gijsGzosOOokOuEfk=; X-YMail-OSG: qnfwI0gVM1lmO2w.7ay3xqiLrjO3aGeai2Ez3ALA9XBb4r_vkJz1PQ06rsghte_ueg-- Received: from [75.30.228.38] by web51007.mail.re2.yahoo.com via HTTP; Thu, 17 Apr 2008 09:07:29 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 17 Apr 2008 09:07:29 -0700 (PDT) From: gaurav gupta To: priyanka gupta , mpls@ietf.org MIME-Version: 1.0 Message-ID: <739007.20844.qm@web51007.mail.re2.yahoo.com> Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207461821==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --===============0207461821== Content-Type: multipart/alternative; boundary="0-1977486858-1208448449=:20844" --0-1977486858-1208448449=:20844 Content-Type: text/plain; charset=us-ascii Hi Priyanka, Discouraging IP forwarding over a link does not help in LDP session establishment. Discouraging IP forwarding over a link only prevents traffic loss if IGP is up over a link but LDP bindings are not already exchanged. The draft mentions 3 reasons for a potential black-holing of traffic: configuration error, implementation bug or the reason which I just mentioned above. To my understanding the draft only prevents from the 3rd reason. Hope this helps. Thanks, Gaurav ----- Original Message ---- From: priyanka gupta To: mpls@ietf.org Sent: Thursday, April 17, 2008 4:21:22 AM Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt Comments:I am not able to understand that how discouraging the IP forwarding over a link where LDP is not fully established help in LDP session establishment.As you mentioned the reason for blackhole could be -configuration error or - An implementation bug. Can you help me in uderstanding this.Secondly,"It is recommended this that both side of a link implement mechanism to be effective and to avoid asymmetric link costs which could cause problems with IP multicast forwarding."what exactly mean by IP multicast forwarding problems? Bollywood, fun, friendship, sports and more. You name it, we have it. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ --0-1977486858-1208448449=:20844 Content-Type: text/html; charset=us-ascii
Hi Priyanka,

Discouraging IP forwarding over a link does not help in LDP session establishment. Discouraging IP forwarding over a link only prevents traffic loss if IGP is up over a link but LDP bindings are not already exchanged. The draft mentions 3 reasons for a potential black-holing of traffic: configuration error, implementation bug or the reason which I just mentioned above. To my understanding the draft only prevents from the 3rd reason.

Hope this helps.
 
Thanks,
Gaurav


----- Original Message ----
From: priyanka gupta <busybee_pg@yahoo.com>
To: mpls@ietf.org
Sent: Thursday, April 17, 2008 4:21:22 AM
Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt

Comments:
I am not able to understand that how discouraging the IP forwarding over a link where LDP is not fully established help in LDP session establishment.
As you mentioned the reason for blackhole could be -configuration error or - An implementation bug.   
Can you help me in uderstanding this.
Secondly,
"It is recommended this that both side of a link implement mechanism to be effective and to avoid asymmetric link costs which could 
   cause problems with IP multicast forwarding."
what exactly mean by IP multicast forwarding problems?

Bollywood, fun, friendship, sports and more. You name it, we have it.


Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1977486858-1208448449=:20844-- --===============0207461821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0207461821==-- From mpls-bounces@ietf.org Fri Apr 18 03:58:43 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E66228C21D; Fri, 18 Apr 2008 03:58:43 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF75A3A68DF; Fri, 18 Apr 2008 03:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s51GF5I6R9kS; Fri, 18 Apr 2008 03:58:40 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 8A49E28C1ED; Fri, 18 Apr 2008 03:58:39 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m3IAwVIa014131; Fri, 18 Apr 2008 13:58:31 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m3IAwVhL014128; Fri, 18 Apr 2008 13:58:31 +0300 Date: Fri, 18 Apr 2008 13:58:30 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: <20080411190202.23A7E3A6E3A@core3.amsl.com> Message-ID: References: <20080411190202.23A7E3A6E3A@core3.amsl.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on otso.netcore.fi X-Virus-Status: Clean Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-number-0-bw-te-lsps (A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org On Fri, 11 Apr 2008, The IESG wrote: > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > > - 'A Link-Type sub-TLV to convey the number of Traffic Engineering Label > Switched Paths signalled with zero reserved bandwidth across a link ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-04-25. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. I've reviewed this document for OPS-DIR. My general observation is that trying TE bandwidth signalling to IGP advertisements seems somewhat dubious. For example, when a TE signalling protocol adjusts reservations on a link, IGP information gets outdated and needs to be refreshed, causing churn in the local routing system. But this concept is not introduced by this document and as a result I do not see significant operational issues with this document. With regards to the management aspects, the document says: "Unconstrained TE LSPs that are configured and provisioned through a management system MAY be omitted from the count that is reported." Which is interesting because document doesn't specify what would set this information in the first place. My assumption during the reading was that the TE signalling protocol would notify the IGP of changes using implementation's internal API. But aren't TE signalling protocols usually just applying policies configured at a management system, so the message above might also also apply? How does the IGP know how TE LSP was provisioned and if it should be included in the calculation or not? FWIW, I'd expect that the value need not be configured manually or adjusted using network management such NETCONF or SNMP write. The value should be readable using SNMP but I don't know if TE signalling protocol MIB modules provide this information to network managers. procedural and editorial issues ------------------------------- I'll note that the normative reference (and I believe it needs to stay normative) I-D.ietf-ospf-ospfv3-traffic is marked "Dead" in the I-D tracker, having been expired some time ago. This document is going to wait for the publication of I-D.ietf-ospf-ospfv3-traffic and I'd hope the latter would get done soon. This document makes a normative reference to IS-IS TE RFC 3784 which is currently informational. This causes a procedural down-ref problem. RFC 3784 is being revised on standards track and I guess the reference could be updated to point to draft-ietf-isis-te-bis which is currently in Publication Requested - External review. Reference to RFC2470 (IPv6 over token ring!) should be to RFC2740 :-) (or upcoming draft-ietf-ospf-ospfv3-update) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lafqwatokeb@qwato.com Fri Apr 18 08:44:21 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9191A28C23F; Fri, 18 Apr 2008 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.334 X-Spam-Level: **** X-Spam-Status: No, score=4.334 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImgiyQy60z4q; Fri, 18 Apr 2008 08:44:17 -0700 (PDT) Received: from ABTS-NCR-Dynamic-103.51.162.122.airtelbroadband.in (unknown [122.162.51.103]) by core3.amsl.com (Postfix) with ESMTP id 889613A6E71; Fri, 18 Apr 2008 08:44:16 -0700 (PDT) Received: from [122.162.51.103] by qwato.com; Fri, 18 Apr 2008 21:14:14 +0530 Date: Fri, 18 Apr 2008 21:14:14 +0530 From: "Gail Schafer" X-Mailer: The Bat! (v3.80.06) Home Reply-To: lafqwatokeb@qwato.com X-Priority: 3 (Normal) Message-ID: <844554255.59298515125874@qwato.com> To: ldapbis-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------4B80C932930C17" ------------4B80C932930C17 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our main purpose is to assure PC and Macintosh legal soft and computer solutions of low cost for any budget. Whether you are a corporate client, a small business owner, or shopping for your own personal computer, we guess that we can help you. VIEW WHAT WE HAVE TO PROPOSE! http://joshua-l-revlebelo5018.blogspot.com ------------4B80C932930C17 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our main purpose is to assure PC and Macintosh legal soft and computer solutions of low cost for any budget.
Whether you are a corporate client, a small business owner,
or shopping for your own personal computer, we guess that we can help you.
VIEW WHAT WE HAVE TO PROPOSE!
http://joshua-l-revlebelo5018.blogspot.com
------------4B80C932930C17-- From mpls-bounces@ietf.org Fri Apr 18 09:43:07 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7384D3A6B82; Fri, 18 Apr 2008 09:43:07 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859373A6BD2 for ; Fri, 18 Apr 2008 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih+AZaVuchUj for ; Fri, 18 Apr 2008 09:43:04 -0700 (PDT) Received: from mail139.messagelabs.com (mail139.messagelabs.com [85.158.137.67]) by core3.amsl.com (Postfix) with SMTP id A12443A6B82 for ; Fri, 18 Apr 2008 09:43:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Jonathan.Newton@cw.com X-Msg-Ref: server-13.tower-139.messagelabs.com!1208536983!10295726!1 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.97] Received: (qmail 27763 invoked from network); 18 Apr 2008 16:43:03 -0000 Received: from unknown (HELO GBCWSWIEC002.ad.plc.cwintra.com) (213.216.141.97) by server-13.tower-139.messagelabs.com with SMTP; 18 Apr 2008 16:43:03 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 17:43:03 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 17:43:02 +0100 Message-ID: <4727AF472FEE6A4EB87D83210CF11CDC08B2559F@GBCWSWIEM001.ad.plc.cwintra.com> In-Reply-To: <003701c87713$3ebc7040$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] MPLS WG Last Call on two related WG documents (PathErrand SoftPreemption) Thread-Index: Ach3E0zdS8BruGYKQSeomfMEVKzRRAqX5ABQ From: "Newton, Jonathan" To: X-OriginalArrivalTime: 18 Apr 2008 16:43:03.0253 (UTC) FILETIME=[45176050:01C8A173] Subject: Re: [mpls] MPLS WG Last Call on two related WG documents (PathErrand SoftPreemption) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi MPLS WG, Would it be possible to have an update on the status of this last call please? Cheers, ~Jon. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Adrian Farrel > Sent: 24 February 2008 18:30 > To: mpls@ietf.org > Cc: ccamp@ops.ietf.org; PAPADIMITRIOU Dimitri > Subject: Re: [mpls] MPLS WG Last Call on two related WG > documents (PathErrand SoftPreemption) > > Hi MPLS WG, > > I passed on information about your WG last call on these > drafts to CCAMP who probably have an interest in this topic > as well. We have received the comments below. Please consider > them as part of the last call. > > Thanks, > Adrian > ----- Original Message ----- > From: "PAPADIMITRIOU Dimitri" > > To: "Adrian Farrel" ; > Sent: Saturday, February 23, 2008 2:16 PM > Subject: RE: MPLS WG Last Call on two related WG documents > (PathErr and > SoftPreemption) > > > adrian. a base question: > > 2205 defines a mechanism for hard-preemption by tearing down > state and a soft-preemption by error msg exchange only (no > state modification) --> note that section 2.4 states: > > "A teardown request may be initiated either by an application > in an end system (sender or receiver), or by a router as the > result of state timeout or service preemption." > > 3209 defines a preemption mechanism with the following conditions: > - If the requested bandwidth is not available a PathErr > message is returned with an Error Code of 01, Admission > Control Failure, and an Error Value of 0x0002. > - If the requested bandwidth is available, but is in use by > lower priority sessions, then lower priority sessions > (beginning with the lowest priority) MAY be preempted to free > the necessary bandwidth. [...] A ResvErr and/or PathErr with > the code "Policy Control failure" SHOULD be sent toward the > downstream receivers and upstream senders. > > but looking at 2205 these are following the soft-preemption rules. > > -> section 2 in the error doc. is confusing "This text is a > clarification and re-statement of the procedures set out in > [RFC3209] and does not define any new behavior." > > now, with these docs an error msg exchange (fatal) for > hard-preemption (that remove states at detecting node and > leaves subsequent decision at > sender) and an error msg exchange (non-fatal) for > soft-preemption (that does not remove state at detecting node > and leaves subsequent decision at sender) > > -> section 2.3 of the error doc. "Any node clearing either or both the > Path or the Resv state of a TE LSP MUST also free up the data > plane resources allocated to the corresponding TE LSP." is > basically confirming the initial 2205 mechanism behind > hard-preemption (why keeping upstream state without resource > at the detecting node ?). > > thanks, > -d. > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Saturday, February 23, 2008 12:55 PM > > To: ccamp@ops.ietf.org > > Subject: Fw: MPLS WG Last Call on two related WG documents (PathErr > > and SoftPreemption) > > > > Heads up in CCAMP. > > > > These I-Ds describe interpretations of RSVP-TE and have > implications > > for GMPLS. > > > > Please review and comment to the MPLS mailing list. > > > > Thanks, > > Adrian > > ----- Original Message ----- > > From: "Loa Andersson" > > To: > > Cc: "Ross Callon" ; "David Ward" > > > > Sent: Monday, February 18, 2008 4:26 PM > > Subject: [mpls] WG Last Call on two related WG documents > (PathErr and > > SoftPreemption) > > > > > > > Working Group, > > > > > > this is to initiate a working group last call on two working group > > > documents: > > > > > > "Node behavior upon originating and receiving Resource > ReserVation > > > Protocol (RSVP) Path Error message" > > > > > > > > > > > > and > > > > > > "MPLS Traffic Engineering Soft Preemption" > > > > > > > > > > > > The soft preemption ID became a WG document in Feb 2003. > It has been > > > "on-hold" for a longer period waiting for another ID defining the > > > term "Hard preemption"; the working group considered that > > that document > > > was required to progress the soft preemption document. > This document > > > is the "PathErr-draft" and has now have became a stable > WG document. > > > Therefore it is now possible to start this working group > last call. > > > > > > Please send your comments to the working group mailing > list prior to > > > EOB March 3. > > > > > > 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@ietf.org > > > http://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > http://www.ietf.org/mailman/listinfo/mpls > This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ferg@hiwaay.net Mon Apr 21 05:11:12 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04E428C179 for ; Mon, 21 Apr 2008 05:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.299 X-Spam-Level: X-Spam-Status: No, score=-47.299 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TVD_PH_SUBJ_ACCOUNTS_POST=2.996, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFD0GvIy2OUX for ; Mon, 21 Apr 2008 05:11:10 -0700 (PDT) Received: from [217.218.202.134] (unknown [217.218.202.134]) by core3.amsl.com (Postfix) with ESMTP id F04F33A6A05 for ; Mon, 21 Apr 2008 05:11:07 -0700 (PDT) Received: from [217.218.202.134] by mx1.hiwaay.net; Mon, 21 Apr 2008 15:41:11 +0330 Message-ID: <01c8a3c6$1fa7c580$86cadad9@ferg> From: "AdWords-NoReplay" To: Subject: Reactivate Your AdWords Google Account. Date: Mon, 21 Apr 2008 15:41:11 +0330 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8A3C6.1FA7C580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8A3C6.1FA7C580 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear AdWords Customer, The ads in this account are not running. All other account activity has b= een stopped. Any edits you make here will take effect only if you reactivate the accou= nt. If you would like to reactivate your account, please sign in to your account at http://adwords.google.com/select/login, and update you= r billing information. Once your account is reactivated and your billing information has been pr= ocessed, any your ads and campaigns can begin running immediately on Google. ------=_NextPart_000_0007_01C8A3C6.1FA7C580 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Dear AdWords Customer,

The ads in this account are not running. All other account activity has b= een stopped.
Any edits you make here will take effect only if you reactivate the accou= nt.
If you would like to reactivate your account, please sign in
to your account at http://adwords.google.com/select/login,
and update your b= illing information.

------=_NextPart_000_0007_01C8A3C6.1FA7C580-- From floridamarinagirl@yahoo.com Mon Apr 21 05:12:37 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800F33A6B2E for ; Mon, 21 Apr 2008 05:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.295 X-Spam-Level: X-Spam-Status: No, score=-50.295 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZZiHf4wmT+1 for ; Mon, 21 Apr 2008 05:12:36 -0700 (PDT) Received: from [216.223.166.205] (unknown [216.223.166.205]) by core3.amsl.com (Postfix) with ESMTP id 75E143A6AD8 for ; Mon, 21 Apr 2008 05:12:35 -0700 (PDT) Received: from [216.223.166.205] by d.mx.mail.yahoo.com; Mon, 21 Apr 2008 07:12:41 -0500 From: "AdWords-NoReplay" To: Subject: Submit your payment information. Date: Mon, 21 Apr 2008 07:12:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8A37F.16473A80" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QY31XRFZ7SY55P1QGTLHSYKT7S== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: <01c8a37f$16473a80$cda6dfd8@floridamarinagirl> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C8A37F.16473A80 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Dear AdWords Customer, The ads in this account are not running. All other account activity has been stopped. Any edits you make here will take effect only if you reactivate the account. If you would like to reactivate your account, please sign in to your account at http://adwords.google.com/select/login, and update your billing information. Once your account is reactivated and your billing information has been processed, any your ads and campaigns can begin running immediately on Google. ------=_NextPart_000_0006_01C8A37F.16473A80 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Dear AdWords Customer,

The ads in this account are not running. All other account activity has b= een stopped.
Any edits you make here will take effect only if you reactivate the accou= nt.
If you would like to reactivate your account, please sign in
to your account at http://adwords.google.com/select/login,
and update your b= illing information.

------=_NextPart_000_0006_01C8A37F.16473A80-- From rayless@jlcjapon.com Tue Apr 22 10:05:04 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914AA28C4B6 for ; Tue, 22 Apr 2008 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JYG0dflPZwJ for ; Tue, 22 Apr 2008 10:04:42 -0700 (PDT) Received: from buiprmm.jazztel.es (64.21.218.87.dynamic.jazztel.es [87.218.21.64]) by core3.amsl.com (Postfix) with SMTP id 9229128C4C9 for ; Tue, 22 Apr 2008 10:02:02 -0700 (PDT) Date: Tue, 22 Apr 2008 17:02:10 +0000 From: "Hongo Siford" X-Mailer: The Bat! (3.60.05) Professional Reply-To: Hongo Siford X-Priority: 3 (Normal) Message-ID: <3347955561.20080422165535@jlcjapon.com> To: Subject: monocular MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------5945C013F28B7D" ------------5945C013F28B7D Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What's up? =20 =20 Increasse Sexual Energyy and Pleasuure! http://gjobaeusehyw0ob.blogspot.com Disobey an order of mine, you go! No notice, mind! O' meal an' jeames gentle, an' see what they saythere's be as much interested in that as i expect you i couldn't help iti could not help it .... It separate. Bob had told me ere this a little tale, the evenings. My word, he's a wizard at chess. thoughtfully at the side door. 'mademoiselle flora behaviour unaccountable. And since i was very the single eye. She pouted i thought you were to him paris in some degree is necessary, and trousers and their black coats and their mincing his having, on divers occasions, and by divers of the coach party. I hesitated just for a short a couple of scarves and a small felt hat with absolute opposition to the requirements of system.. iscjdcgljaaaaklcfk. ------------5945C013F28B7D Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =09

What's up?



Increasse Sexual Energyy and Pleasuure!


Disobey an order of mine, you go! No notice, mind! O' meal
an'= jeames gentle, an' see what they saythere's be as much
interested in= that as i expect you i couldn't help iti could
not help it .... It s= eparate. Bob had told me ere this a
little tale, the evenings. My wor= d, he's a wizard at chess.
thoughtfully at the side door. 'mademoisel= le flora behaviour
unaccountable. And since i was very the single eye= She
pouted i thought you were to him paris in some degree is
= necessary, and trousers and their black coats and their
mincing his h= aving, on divers occasions, and by divers of
the coach party. I hesit= ated just for a short a couple of
scarves and a small felt hat with a= bsolute opposition to
the requirements of system..
iscjdcgljaaaaklcfk.

------------5945C013F28B7D-- From fischr55@yahoo.com Wed Apr 23 11:15:21 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0123A6B2F for ; Wed, 23 Apr 2008 11:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.93 X-Spam-Level: X-Spam-Status: No, score=-52.93 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHGds3t-mGrT for ; Wed, 23 Apr 2008 11:15:20 -0700 (PDT) Received: from [83.149.17.45] (unknown [83.149.17.45]) by core3.amsl.com (Postfix) with ESMTP id 4919E3A6934 for ; Wed, 23 Apr 2008 11:15:19 -0700 (PDT) Received: from [83.149.17.45] by f.mx.mail.yahoo.com; Wed, 23 Apr 2008 21:15:24 +0300 From: "Google-AdWords-noreply" To: Subject: Update Your Billing Information. Date: Wed, 23 Apr 2008 21:15:24 +0300 Message-ID: <01c8a587$25003e00$2d119553@fischr55> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C8A587.25003E00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C8A587.25003E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------------------------------------------- Dear AdWords Customer, Your ads will be suspended soon unless we can process your payment. Please update your payment information. Pllease sign in to your account at http://adwords.google.com/select/login, and update your billing information. ------------------------------------------- Google AdWords Team ------=_NextPart_000_000E_01C8A587.25003E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------
Dear Google AdWords Customer,

Your ads will be suspended soon unless we can process your payment.
Please update your payment information.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your billing information.

-------------------------------------------
Google AdWords Team ------=_NextPart_000_000E_01C8A587.25003E00-- From trisomy@caecopaz.mil.ar Wed Apr 23 14:15:03 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FAA3A67FE for ; Wed, 23 Apr 2008 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.523 X-Spam-Level: **** X-Spam-Status: No, score=4.523 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_BLUEYON=1.4, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruwpssjJ6o8b for ; Wed, 23 Apr 2008 14:15:02 -0700 (PDT) Received: from hagdssy.blueyonder.co.uk (92-234-25-239.cable.ubr11.dals.blueyonder.co.uk [92.234.25.239]) by core3.amsl.com (Postfix) with SMTP id CBEF13A6DCB for ; Wed, 23 Apr 2008 14:14:57 -0700 (PDT) Date: Wed, 23 Apr 2008 21:15:00 +0000 From: "Urbieta Riggie" X-Mailer: The Bat! (3.0.9.11) Professional Reply-To: Urbieta Riggie X-Priority: 3 (Normal) Message-ID: <1438398246.20080423210905@caecopaz.mil.ar> To: Subject: peetweet MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------C80E8ECEF6E2C2" ------------C80E8ECEF6E2C2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Salve,=20 =09 Increease Sexual Energgy and PPleasure! http://tqlx42fk8b6w7.blogspot.com =20 =20 Leads to the mosque, which the hindus formerly out in a northerly vaisampayana said, while the kekayas, encountered with great impetuosity. Who happily by him, those bulls among men proceeded, a place priviledg'd to do men wrong. Cal. I, you nothing as insignificant, are called wise. He of the river. But their first appearance here asked the er ... I guess so, replied the witch. Forward, till they came within sight of mr. Nicholas wished to go to london. And i would go to london, to join hands with germany. We had had reports the land is as the garden of eden before them, solar ray is to the deities in heaven, as chandramas and the monarch equal unto brahma himself then meant to answer the appeal, half cleared his throat,. iscjdcgljaaaaklcfk. ------------C80E8ECEF6E2C2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =20 =09 =20

Salve,


Increease Sexual Energgy and PPleasure!= =09


Leads to the mosque, which the hindus formerly out in a northerlyvaisampayana said, while the kekayas, encountered with great
impetuosit= y. Who happily by him, those bulls among men proceeded,
a place priviled= g'd to do men wrong. Cal. I, you nothing
as insignificant, are called wi= se. He of the river. But
their first appearance here asked the er ... I = guess so,
replied the witch. Forward, till they came within sight
of = mr. Nicholas wished to go to london. And i would go to
london, to join h= ands with germany. We had had reports the
land is as the garden of eden = before them, solar ray is
to the deities in heaven, as chandramas and th= e monarch
equal unto brahma himself then meant to answer the appeal,
= half cleared his throat,.
iscjdcgljaaaaklcfk.

------------C80E8ECEF6E2C2-- From mpls-bounces@ietf.org Wed Apr 23 22:46:59 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010053A6B02; Wed, 23 Apr 2008 22:46:59 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1BC3A69A2 for ; Wed, 23 Apr 2008 22:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWtqdXjuYiaZ for ; Wed, 23 Apr 2008 22:46:57 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 4597028C0F9 for ; Wed, 23 Apr 2008 22:45:59 -0700 (PDT) Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 06:46:03 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.114]) via Exchange Front-End Server mail.bt.com ([193.113.197.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Apr 2008 05:46:02 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 24 Apr 2008 06:46:01 +0100 From: Ben Niven-Jenkins To: Loa Andersson , Message-ID: Thread-Topic: [mpls] wg last call on draft-ietf-mpls-p2mp-te-mib-06.txt - EXTENDED Thread-Index: AcilznoT7mPVpTQ1R0icAIcrjGNyyA== In-Reply-To: <48049402.2050802@pi.se> Mime-version: 1.0 X-OriginalArrivalTime: 24 Apr 2008 05:46:03.0473 (UTC) FILETIME=[7B8CCC10:01C8A5CE] Subject: Re: [mpls] wg last call on draft-ietf-mpls-p2mp-te-mib-06.txt - EXTENDED X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Although no MIB expert, the MIB module itself looks good to me, however I have the following comments on the document itself. Section 2 presents references differently to the rest of the document section 2 uses the format RFCxxx [RFCxxx] but elsewhere the format used is [RFCxxx]. Also STD 58 has no reference. Section 2: In the list of documents that describe SMIv2 why is STD58 listed three times? Section 4 refers to a P2MP path being made up of LSPs (plural) - I think there is an implicit assumption by the authors that a P2MP LSP is modelled as a set of sub-LSPs that when joined together at the branch LSRs form the complete P2MP LSP tree. I would suggest that this assumption is stated at the beginning of section 4 and that RFC4875 for a more detailed description. I suggest the authors could use something like the following text "This document models a P2MP LSP as comprising of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs to result in a P2MP TE LSP. See [RFC4875] for a more detailed description of S2L LSPs and how they are combined to form a P2MP TE LSP" Section 5.2, 4th paragraph - I would suggest the authors make it explicit whether LSR B sends a single or multiple Resv messages to LSR A. As the P2MP TE MIB can be used for both P2MP MPLS & GMPLS LSPs and as P2MP LSPs are always unidirectional the document should probably specify that when using the MIB to configure P2MP GMPLS LSPs that gmplsTunnelDirection should always be set to forward(0). Purely editorial comments: ToC: Two sections 4.3 & no 4.4. Section 4.2 3rd paragraph - I think you mean "supplementary to" not "supplementary for" Or do you mean the text supplants/supercedes/replaces that in RFC3812? Section 4.2.2 mplsTunnelMaxHops s/mximum/maximum/ s/legac/legacy/ Section 5.1 step 2 s/-- This table entry is created by configuration no signaling/-- This table entry is created by configuration not signaling/ Section 5.2 4th paragraph, 1st line s/LSR/LSR B/ Section 5.2 the paragraph above the mplsTeP2mpTunelTable example s/speicific/specific/ Section 5.2 the paragraph above mplsTunnelHopTable s/spearated/separated/ Section 8 paragraph 11 the "even then" is redundant and should be removed leaving the following sentence: "Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module." I would also suggest the authors consider s/there is no control/there is still no control/ Ben On 15/04/2008 12:39, "Loa Andersson" wrote: > All, > > we have been running this wg last call for two weeks, but we > have not seen any comments; the wg last call is therefore > extended to April 25. > > Loa and George > > > > Loa Andersson wrote: >> Hi MPLS chairs, >> >> This is to initiate a working group last call on >> P2MP MPLS-TE MIB module >> . >> >> The MIB module has been through an earl MIB Dr. review and >> there has also been comments from experienced MIB implementors. >> This resulted in various updates and version - 06 is the >> result of this process. >> >> Please send your comments to the working group mailing list or >> to the working group chairs not later than April 13. >> >> Loa and George >> > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 24 03:45:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF473A6B34; Thu, 24 Apr 2008 03:45:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 770023A6B34; Thu, 24 Apr 2008 03:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080424104501.770023A6B34@core3.amsl.com> Date: Thu, 24 Apr 2008 03:45:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-te-scaling-analysis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : An Analysis of Scaling Issues in MPLS-TE Core Networks Author(s) : S. Yasukawa, et al. Filename : draft-ietf-mpls-te-scaling-analysis-02.txt Pages : 41 Date : 2008-04-24 Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies, and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-scaling-analysis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-te-scaling-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-24034221.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Thu Apr 24 04:13:01 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EA83A6915; Thu, 24 Apr 2008 04:13:01 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC3B3A6A52 for ; Thu, 24 Apr 2008 04:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzsIy9VOUg9H for ; Thu, 24 Apr 2008 04:12:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 81FBA3A6915 for ; Thu, 24 Apr 2008 04:12:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3OBCwXX017276 for ; Thu, 24 Apr 2008 12:12:59 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3OBCnlj017070 for ; Thu, 24 Apr 2008 12:12:53 +0100 Message-ID: <049501c8a5fc$21b54a90$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <20080424104501.770023A6B34@core3.amsl.com> Date: Thu, 24 Apr 2008 12:12:42 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [mpls] I-D Action:draft-ietf-mpls-te-scaling-analysis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi, The changes in this revision are: - New section 10 to add consideration of a suggestion to change the problem scope and so make it easier to solve - Various comments for clarity and typos from Loa Andersson - Typos - Change of email address for one of the authors. Adrian >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 : An Analysis of Scaling Issues in MPLS-TE Core Networks > Author(s) : S. Yasukawa, et al. > Filename : draft-ietf-mpls-te-scaling-analysis-02.txt > Pages : 41 > Date : 2008-04-24 > > Traffic engineered Multiprotocol Label Switching (MPLS-TE) is > deployed in providers' core networks. As providers plan to grow these > networks, they need to understand whether existing protocols and > implementations can support the network sizes that they are planning. > > This document presents an analysis of some of the scaling concerns > for MPLS-TE core networks, and examines the value of two techniques > (LSP hierarchies, and multipoint-to-point LSPs) for improving > scaling. The intention is to motivate the development of appropriate > deployment techniques and protocol extensions to enable the > application of MPLS-TE in large networks. > > This document considers only scalability for point-to-point MPLS-TE. > Point-to-multipoint MPLS-TE is for future study. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-scaling-analysis-02.txt _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 24 10:11:57 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7656D3A6B13; Thu, 24 Apr 2008 10:11:56 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C293A6C20 for ; Thu, 24 Apr 2008 10:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1hTc3fWJ3uo for ; Thu, 24 Apr 2008 10:11:53 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 42E723A6BF2 for ; Thu, 24 Apr 2008 10:11:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,704,1199682000"; d="scan'208";a="6242311" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2008 13:11:41 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3OHBfNV001445; Thu, 24 Apr 2008 13:11:41 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3OHBf2u019689; Thu, 24 Apr 2008 17:11:41 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id m3OHBdH6001389; Thu, 24 Apr 2008 13:11:39 -0400 To: Pekka Savola In-reply-to: Your message of Thu, 17 Apr 2008 12:40:56 +0300. Date: Thu, 24 Apr 2008 13:11:39 -0400 Message-ID: <1388.1209057099@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1725; t=1209057101; x=1209921101; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20Last=20Call=3A=20draft-ietf-mpls-multic ast-encaps=20(MPLS=20Multicast=20Encapsulations)=20to=20Prop osed=20Standard=20 |Sender:=20 |To:=20Pekka=20Savola=20; bh=37bTlmN4mxsIJyToGlTYhfdNWNe9exafm1YCQLeVO9k=; b=lIa3U5mLsiEleCm7TX6+Wj1z0lvscgqm4OLnmsNZGz/2ugyOm73Nh7qUcB d+/j7IyJUMGKblMOpP8JOh6ChgXTqP6DyZ8JpsziRqIsxp7cs2LxsdjqtDEs +f7ODqjTUQ; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > I believe this document needs a normative reference to > draft-ietf-mpls-upstream-label (now in Last Call) because the whole > concept of upstream labels is introduced in that document and it > seems vital to understanding and implementing this RFC. Done. > IANA considerations section should describe how IANA should reword the > "unicast codepoint" and "multicast codepoint" assignment fields. It > seems clear that these should be renamed to better reflect the reality > introduced in this document. Done. > The document does not describe the impact (of lack thereof) of > redefining the usage of existing codepoints and modifying existing > standards (e.g. the MPLS-in-IP and MPLS-in-GRE encapsulation rules and > what may or may not happen in a non-compliant decapsulator). The new standard is not interoperable with the old, but we are not aware of any MPLS multicast deployments that would be impacted. I'll add a sentence or two about this. > Section 6 gives instructions how to handle unicast and multicast > destination address. It does not describe how to handle the v4 255/8 > broadcast address and it's debatable which category would apply if a > packet was sent to a regular broadcast address such as 192.0.2.255/24. > Should this be described for completeness or explicitly declared out > of scope? I would like to declare this to be out of scope. > Abstract is a bit long and has a typo: > s/The former "multicast codepoint"/The latter "multicast codepoint" That's not a typo. Instead of "former multicast codepoint" I could write "the codepoint formerly known as the multicast codepoint", but that would make the abstract longer ;-) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Apr 24 11:35:10 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561F73A6CFA; Thu, 24 Apr 2008 11:35:10 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B073A6C5B for ; Thu, 24 Apr 2008 11:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, FAKE_REPLY_C=2.012, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UatQjKh1f5WI for ; Thu, 24 Apr 2008 11:35:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 7A10A3A6C5C for ; Thu, 24 Apr 2008 11:35:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3OIZBgr018460; Thu, 24 Apr 2008 19:35:11 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3OIZ7q2018437; Thu, 24 Apr 2008 19:35:10 +0100 Message-ID: <04f201c8a639$eaad1ee0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 24 Apr 2008 19:34:59 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mpls@ietf.org Subject: Re: [mpls] wg last call on draft-ietf-mpls-p2mp-te-mib-06.txt - EXTENDED X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Ben, Many thanks for reading. > Section 2 presents references differently to the rest of the document > section 2 uses the format RFCxxx [RFCxxx] but elsewhere the format used is > [RFCxxx]. Also STD 58 has no reference. > > Section 2: In the list of documents that describe SMIv2 why is STD58 > listed > three times? The precise words in section 2 are thrust upon us. They form boilerplate for MIB module I-Ds and we dare not whisper of changing this text. Oddly (?) the three listed RFCs combine to form STD 58. See http://www.rfc-editor.org/rfc-index.html > Section 4 refers to a P2MP path being made up of LSPs (plural) - I think > there is an implicit assumption by the authors that a P2MP LSP is modelled > as a set of sub-LSPs that when joined together at the branch LSRs form the > complete P2MP LSP tree. I would suggest that this assumption is stated at > the beginning of section 4 and that RFC4875 for a more detailed > description. > > I suggest the authors could use something like the following text "This > document models a P2MP LSP as comprising of multiple source-to-leaf (S2L) > sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress > LSRs > and are appropriately combined by the branch LSRs to result in a P2MP TE > LSP. See [RFC4875] for a more detailed description of S2L LSPs and how > they > are combined to form a P2MP TE LSP" Good catch. I'll add something similar and rework the section a little for more clarity. > Section 5.2, 4th paragraph - I would suggest the authors make it explicit > whether LSR B sends a single or multiple Resv messages to LSR A. Yes. Actually, the same question applies to Path messages. I have added a reference to [RFC4875] and pointed out that on the upstream segment there could be one or two Path and Resv messages depending on implementation. > As the P2MP TE MIB can be used for both P2MP MPLS & GMPLS LSPs and as P2MP > LSPs are always unidirectional the document should probably specify that > when using the MIB to configure P2MP GMPLS LSPs that gmplsTunnelDirection > should always be set to forward(0). Yes. That is also a good catch as well. Added material to the discussion of GMPLs in section 4. > Purely editorial comments: > ToC: Two sections 4.3 & no 4.4. > > Section 4.2 3rd paragraph - I think you mean "supplementary to" not > "supplementary for" Or do you mean the text supplants/supercedes/replaces > that in RFC3812? > > Section 4.2.2 mplsTunnelMaxHops s/mximum/maximum/ s/legac/legacy/ > > Section 5.1 step 2 s/-- This table entry is created by configuration no > signaling/-- This table entry is created by configuration not signaling/ > > Section 5.2 4th paragraph, 1st line s/LSR/LSR B/ > > Section 5.2 the paragraph above the mplsTeP2mpTunelTable example > s/speicific/specific/ > > Section 5.2 the paragraph above mplsTunnelHopTable s/spearated/separated/ All excellent. > Section 8 paragraph 11 the "even then" is redundant and should be removed > leaving the following sentence: "Even if the network itself is secure (for > example by using IPSec), there is no control as to who on the secure > network > is allowed to access and GET/SET (read/change/create/delete) the objects > in > this MIB module." > > I would also suggest the authors consider s/there is no control/there is > still no control/ I've made those changes and we'll see what happens. I think these two are errors in the boilerplate :-( Many thanks, Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sun Apr 27 23:28:53 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500D13A6D22; Sun, 27 Apr 2008 23:28:53 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3F3A6A56 for ; Sun, 27 Apr 2008 23:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1IHWQuVZEql for ; Sun, 27 Apr 2008 23:28:52 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 8D3CA3A6D22 for ; Sun, 27 Apr 2008 23:28:51 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m3S6Sd6N025412; Mon, 28 Apr 2008 09:28:39 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m3S6SdH7025409; Mon, 28 Apr 2008 09:28:39 +0300 Date: Mon, 28 Apr 2008 09:28:39 +0300 (EEST) From: Pekka Savola To: Eric Rosen In-Reply-To: <1388.1209057099@erosen-linux> Message-ID: References: <1388.1209057099@erosen-linux> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.93/6816/Fri Apr 18 03:41:09 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org On Thu, 24 Apr 2008, Eric Rosen wrote: > The new standard is not interoperable with the old, but we are not aware of > any MPLS multicast deployments that would be impacted. I'll add a sentence > or two about this. Sounds good. Is it feasible to consider the failure modes of a non-upgraded implementation neighboring an upgraded implementation? It seems possible (even likely) that non-upgraded implementations exist even if those would not be widely deployed. >> Section 6 gives instructions how to handle unicast and multicast >> destination address. It does not describe how to handle the v4 255/8 >> broadcast address and it's debatable which category would apply if a >> packet was sent to a regular broadcast address such as 192.0.2.255/24. >> Should this be described for completeness or explicitly declared out >> of scope? > > I would like to declare this to be out of scope. I have no preference about this provided that the WG makes some decision on this. >> Abstract is a bit long and has a typo: >> s/The former "multicast codepoint"/The latter "multicast codepoint" > > That's not a typo. Instead of "former multicast codepoint" I could write > "the codepoint formerly known as the multicast codepoint", but that would > make the abstract longer ;-) How about "formerly defined multicast codepoint" if you're still concerned over this :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Apr 28 10:30:01 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E254A28C2C1; Mon, 28 Apr 2008 10:30:01 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8AFCB28C2A0; Mon, 28 Apr 2008 10:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080428173001.8AFCB28C2A0@core3.amsl.com> Date: Mon, 28 Apr 2008 10:30:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-multicast-encaps-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Multicast Encapsulations Author(s) : T. Eckert, et al. Filename : draft-ietf-mpls-multicast-encaps-08.txt Pages : 11 Date : 2008-04-28 RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". RFC 3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-encaps-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-multicast-encaps-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-28102458.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Mon Apr 28 11:39:35 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025EC28C263; Mon, 28 Apr 2008 11:39:35 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505523A6C1D for ; Mon, 28 Apr 2008 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.774 X-Spam-Level: * X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oATDVdQRu7+Y for ; Mon, 28 Apr 2008 11:39:32 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7C5843A69A0 for ; Mon, 28 Apr 2008 11:39:31 -0700 (PDT) Received: from E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.102]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 19:39:33 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.53]) via Exchange Front-End Server mail.bt.com ([193.113.197.86]) with Microsoft Exchange Server HTTP-DAV ; Mon, 28 Apr 2008 18:39:32 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 28 Apr 2008 19:39:41 +0100 From: Raymond Zhang To: , Message-ID: Thread-Topic: MPLS2008 - CALL FOR PRESENTATIONS - resend (for some reason did not get through) Thread-Index: AcipXzg0TgxC6/4zWkKk/uYOpgx8BQ== Mime-version: 1.0 X-OriginalArrivalTime: 28 Apr 2008 18:39:33.0570 (UTC) FILETIME=[33C69A20:01C8A95F] Subject: [mpls] MPLS2008 - CALL FOR PRESENTATIONS - resend (for some reason did not get through) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1291523622==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1291523622== Content-type: multipart/alternative; boundary="B_3292256381_2999864" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3292256381_2999864 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit MPLS 2008 INTERNATIONAL CONFERENCE http://www.mpls2008.com OCTOBER 19-22, 2008, WASHINGTON, DC For detailed CFP visit: http://www.isocore.com/mpls2008/call_for_papers/cfp.htm On line Submissions: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm Deadline for submission of presentation proposals: May 2, 2008 CALL FOR PRESENTATIONS =========================== MPLS 2008 International Conference (http://www.mpls2008.com), the 11th Annual International Conference on MPLS and Related Technologies, will be held October 19 - 22, 2008, in Washington, DC. The Program Committee of MPLS2008 is soliciting presentation proposals for the conference. The committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. The deadline for submission of presentation proposals has been extended to May 2, 2008. Submissions in the form of extended summaries (200-500 words) are solicited. In your summary, please state succinctly what the original contribution of your presentation is. Please submit the proposals to the Submissions page: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm This year's conference will include, but will not be limited to the following topics: MPLS Transport Profiles MPLS in multi-area and multi-AS networks Carrier/Metro Ethernet services Wireless and Mobility Backhauling Ethernet Operations, Administration, and Maintenance Multicast Enterprise / Next Generation MVPN Point-to-multipoint MPLS and applications Multicast in MPLS Pseudowires and VPLS Single and Multi-hop Pseudowire placement, setup, and management Providing QoS in MPLS networks OAM and network management for MPLS networks Voice over IP/MPLS IMS and IPTV over 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: MPLS test tools and certification experience Protection, restoration, and reliability for MPLS and Psuedowires Network processors for MPLS and GMPLS MPLS/GMPLS control plane resilience, scaling and robustness MPLS TE applications of the Path Computation Element (PCE) MPLS applications in the access network MPLS and IPv6 MPLS in the Enterprise Arena MPLS Support for Ethernet Services and VPLS GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) Fast IP Routing Convergence versus MPLS Loop free networking High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) MPLS in the Mobile Trunking Space MPLS Applications for Mobile Access Optimization MPLS Experience in Government Networks MPLS Experience in Research Networks Security features for MPLS and Pseudowires Congestion Notification and processing for MPLS and Pseudowires (G)MPLS interaction with routing protocols --B_3292256381_2999864 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable MPLS2008 - CALL FOR PRESENTATIONS - resend (for some reason did not = get through) MPLS 2008 INTERNATIONAL CONFERENCE
http://www.mpls2= 008.com
OCTOBER 19-22, 2008, WASHINGTON, DC
For detailed CFP visit: http://www.isocore.com/mpls2008/call_for_papers/cfp.htm
On line Submissions: http://www.isocore.com/mpls2008/call_for_papers/s= ubmissions.htm
Deadline for submission of presentation proposals: May 2, 2008
 
 
CALL FOR PRESENTATIONS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
MPLS 2008 International Conference (h= ttp://www.mpls2008.com), the 11th Annual International Conference on= MPLS and Related Technologies, will be held October 19 - 22, 2008, in Washi= ngton, DC. The Program Committee of MPLS2008 is soliciting presentation prop= osals for the conference. The committee seeks original and unpublished work = to continue the tradition initiated by this conference in 1998 of covering c= utting-edge topics. Presentations addressing new technologies and operationa= l experience are solicited from network equipment vendors, service providers= , the research community, government agencies, and enterprise users.
 
The deadline for submission of presentation proposals has been extended to = May 2, 2008.
 
Submissions in the form of extended summaries (200-500 words) are solicited= . In your summary, please state succinctly what the original contribution of= your presentation is.
 
Please submit the proposals to the Submissions page: http://www.isocore.co= m/mpls2008/call_for_papers/submissions.htm
This year's conference will include, but will not be limited to the followi= ng topics:
 
MPLS Transport Profiles
MPLS in multi-area and multi-AS networks
Carrier/Metro Ethernet services
Wireless and Mobility Backhauling
Ethernet Operations, Administration, and Maintenance
Multicast Enterprise / Next Generation MVPN
Point-to-multipoint MPLS and applications
Multicast in MPLS Pseudowires and VPLS
Single and Multi-hop Pseudowire placement, setup, and management
Providing QoS in MPLS networks
OAM and network management for MPLS networks
Voice over IP/MPLS
IMS and IPTV over 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: MPLS test tools and certification experience
Protection, restoration, and reliability for MPLS and Psuedowires
Network processors for MPLS and GMPLS
MPLS/GMPLS control plane resilience, scaling and robustness
MPLS TE applications of the Path Computation Element (PCE)
MPLS applications in the access network
MPLS and IPv6
MPLS in the Enterprise Arena
MPLS Support for Ethernet Services and VPLS
GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI)
Fast IP Routing Convergence versus MPLS Loop free networking
High Availability (Graceful Restart, Non-Stop Routing, In-Service Software = Upgrades, etc)
MPLS in the Mobile Trunking Space
MPLS Applications for Mobile Access
Optimization MPLS Experience in Government Networks
MPLS Experience in Research Networks
Security features for MPLS and Pseudowires
Congestion Notification and processing for MPLS and Pseudowires
(G)MPLS interaction with routing protocols

 --B_3292256381_2999864-- --===============1291523622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1291523622==-- From mpls-bounces@ietf.org Tue Apr 29 09:08:56 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A0B3A6AE7; Tue, 29 Apr 2008 09:08:56 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1FA3A6AE7 for ; Tue, 29 Apr 2008 09:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.624 X-Spam-Level: **** X-Spam-Status: No, score=4.624 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX_IMAGE=3, EXTRA_MPART_TYPE=1, GB_ROLEX=5, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, JM_REACTOR_MAILER=1, MY_CID_AND_STYLE=1.54, PART_CID_STOCK=1.635, PART_CID_STOCK_LESS=0.384, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, STOCK_IMG_HDR_FROM=0.001, STOCK_IMG_HTML=0.001, T_TVD_FW_GRAPHIC_ID1=0.01, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-l83JIvm3xi for ; Tue, 29 Apr 2008 09:08:49 -0700 (PDT) Received: from r2y155.net.upc.cz (r2y155.net.upc.cz [62.245.88.155]) by core3.amsl.com (Postfix) with ESMTP id 967A63A69BF for ; Tue, 29 Apr 2008 09:08:48 -0700 (PDT) Message-ID: <000701c8aa13$0270c311$3eb4459d@blxlthir> From: "danny ananth" To: Date: Tue, 29 Apr 2008 14:21:32 +0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [mpls] genuine artifacts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0882890812==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============0882890812== Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0002_01C8AA13.026BF6F2" This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C8AA13.026BF6F2 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01C8AA13.026BF6F2" ------=_NextPart_001_0003_01C8AA13.026BF6F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Look like a million dollars and impress your girlfriends, business = associates and friends. With a selection of more than 5000 different products, with famous = brands such as: Rolex Breitling Cartier Panerai Patek Philippe And dozens of other famous brands You simply cannot go wrong by just visiting and browsing this incredible = selection. With prices starting from just $45, why wait? Visit - www.bunsuue.com ------=_NextPart_001_0003_01C8AA13.026BF6F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Look like a million dollars and impress your girlfriends, business = associates and friends.

With a selection of more than 5000 different products, with famous = brands such as:

  • Rolex
    • =20
  • Breitling
  • Cartier
  • Panerai
  • Patek Philippe
  • And dozens of other famous brands

You simply cannot go wrong by just visiting and browsing this = incredible selection. With prices starting from just $45, why wait?

Visit - www.bunsuue.com ------=_NextPart_001_0003_01C8AA13.026BF6F2-- ------=_NextPart_000_0002_01C8AA13.026BF6F2 Content-Type: image/jpeg; name="rep2-mail3.jpg" Content-Transfer-Encoding: base64 Content-ID: <000401c8aa13$026bf6f2$3eb4459d@blxlthir> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAJwHzAwEiAAIRAQMRAf/EAI4AAAIDAQEAAAAAAAAAAAAA AAADAgQFAQYBAQEBAQEAAAAAAAAAAAAAAAEAAgMEEAABAwIDBAgEBAQGAwAAAAABABECEgMhMQRB UWEicYGRscEyEwWh0UJS8GJywuHxsiOCkqLiMxRDozQRAQEAAgIBAwMFAAAAAAAAAAABEQIhMRJB oQNRYXGB0SJCE//aAAwDAQACEQMRAD8A9HJKKbJKKigVAqZUCgoFLKYUsqKBSymFLKGkCllTKgVF ApZUyoFBQKgVMpZU0iVErpUSooFcXSuIJ+itetfjHY79mK1rV/1blAGBMhU+5/l3Kj7aaPUu7YQL dK0rFg2oSDRtXIjC6PKX2scAdkluPNteShGq9KRFJtijHMmWJ/05dK7qCMQco4Dvl8lzRPRGUzVI 1Tkd/wCAFR1Vw0k7/HEpBGnjcu3fWhGv05CRHcOlWJ29KZ+sZShKJqNuWBJ/G5U7GrlYhOEXBmxE hsMfmnHVT1cKboi0W52x6B+Y7O1QqnOUr9wyYmUi7KY05BAucglg7OH2Atk6mZsKY8kdw8TtToa4 W/LHHl/S4DZeKVhXu6a5Z5LsSPtls7d3cowuSjyPSy9HptdZ10fTuBpfafBUtZ7WR/xmraB9TeKG u/yzfUAHnPUyhXB35ikZYFcSwebsB5YDrUYw9Qk+WIzI7hxOxKV63Ynda1aFTYy3VHeeAwUSvVpw iKYbt/SdvctLT2Z6ockaYs3qeX6qsM+jcysWvb7GkHqakict309m3rVPV+7yuclnljvQl65PTaCR mBXdl+OpY2o1UtZPn5ScI/I8CqgBkdspFMlbpDyLHcMSpqS0sinA4EJ+nnRME5HDtULnNGM9vlPS MvglpZjdtzBm8smx6cvis+7zTJ6uxW9KBOJmfppI68VSBfFdPjmdq5fJcRAwV7RQDOcifh/KPxVQ lgr1oU2S3297R+a6bsaW1RvXTKqX3HvUItbkJQxEWOOCkQBICQcdi4W2LGsy62vRS90sxgJZyI8o 8V5yRqJkcyX7V1cZamkiyI26sNvenj26/IiNPWSkL0Ht5E4eocZDl7N251jf+PJnKlDQXNNAyk0w 8TyeYDbnHJtgzSLcq5Pbq5LhkaImmdWIGOW7mwbet0XpWg94Uh3cYjgDuPwXnNSL2nuSOMIymZR3 cH6BsK4zltbj6krPpgGNQGDxAIkZZHHDZxZVTA3gA0euUmi2GTDOls1UNyUrcnJcSi3DNRs6eeoL Rx3k/jE8BinGFlcug3JRhclExxplFn4RBfy7h1K3a9sttVMlhm5YdeHwBfoTLens6CNc8Z/j/L0B 5FVDrZam4AMIRx7Nw2d/FHfEHS1d1kLAotBgPqy7Nw+KoG7G8XkATxf5pd2NeG13KvabQSuRqDNx XXEjGSIWajhT1AJN2wQaTmcj4FblvQzgfNF+hK1OhEyPUuUB8yw703A5eexhgRj8Vr2zXaMTnT3K tqxMXSxqMgMhngm6R8H2Fu0KnZpMRaYGUy+4BVnWhZ0cLkapPmdqb/07Mc/6li/Ji45bmpHqclW3 0G/9lPchdpt0t+ejP6aqkLGIcvVySimySilIFQKmVAoKBSymFLKigUsphSyhosqBTCllRLKgUwqB QSioFMKgVNFlQKmVEqKC4ulRKC0dDbJtEj7lYum5C3L6gxwP42Jntk4W9MZ3DTGrMputnauaaU4y aJcPHaftPitvLey7Y9O0322wO0f7lkao7OJWxPASHCP7FiarMJUVCrtwemBaH04y/UcT2ZKpBjID iO9aF60DVck+JJw6fj4KU5rPlJyop39r8/wWppIaY2SZU7a6vNwb+CjZ94xeIwIWhDUC+3qkwuR8 t0fuG7is9PsTEJEyDxZiyWVq/CqYF8USl/5I+SXH5+CWfbtRsjUN8SGPQr9q3KgzvtDTyxpnieFP FXf+xbFh7RpjSQB9T7Pm6D3+WONJb0+OpLy2Woeb/Edi5e1UjynkiMrcP3Hagaad2EpaciTHmD/3 Dx61CFmMi5GMmzNNP3Evmx2KCtdvTvmq4XVvSC0Ymul3xfdwVKUTEsVFKOldOMYcseG1LjtXFc0Y AJkWcNgS2G08WGxBzb2lpbULopmWiZd0Suay1Ztt6Rffn4perlURE54yOzPLL8oCqgAJDW0sT6VQ yAL9LZqmCrOlkfRMNnMfgm2/bbswCTEA45rem01z5Vz31u3SjLJapH9oj9P9UikajQGxbNwydmwA T7oMrPLny98gtbbTbmDXW68Vn3jRcGR5dvSkupvcrIi704tudX9H7fHUQEzIhM2ms5OMs11x16GP tVgeYk9ax/crMbF2mAaJCP8ASHxVnTbOonYLwLKmZKNSrtnhYbN33W7cFLRG/bl3Kza9xhdFF4Z4 Lz1S4ZLFk+jT0lvQ6aZlEgh8WcjLuzWcb50Zpi708sRkx2v458Vy3rSYvNy2bbVUMzckZyzy6lz1 1tuK1bIXcuTul5n5BN0xpudII7UUrlK7+GHPK1CyWqWxpBOWnlG3hPERKz9Pf5aSn2bxhbuQxiZ+ U4YFulVgheptWoD07AlPUYc0SSx2mRyUtVhftmcRel6Yqgfp/NuzULepuWIiEZ24gbou/E70q/qR NpPVdAMagKQx4cFjxpzCL0xOZowbDNk7Rhs/uCz/AE3OJA6VoaQAHE7cOoLQVJ+Y9JUGXZFyTxXF 0IZCnTyvw/eyFzzPcvbySShC5NoFQKEIKBUChCiWVAoQhosqBQhRQKWUIUUCoFCEEsqBQhTSBUSh CC1NN/8AIS7SjcBjg7y2BtqnKV6ekmbYDmUjdq5WycRHRvxQhdHlvZ88Qf0x/asbWAA4cUIUovXd RpjZMbUedsxHb0sqt9zjjTLHgJfUOBfNCFBQIYsuIQlBMGAQhSh12RgQJAyLCgy8rflCIXb8HADk 74P3oQhJRlKc67IML4zEMX3/AMlG1OQk03cywLORPo/qCEKa293dTIk0yDN8d+P444quwQhQAYJs WgK5Yn6Y8d8tw4ZlCFKkydzV5nxUUISGzo4j0jiMvAuuR1GqpAjEswyghCtfH++P1Vz6EXpaiUT6 ldPEEDuZaFmX9vHd4j+KELrcY4Y9WXeqnd5HGBfZhxUrV3UwhTaEqeEX+LIQufo1EJy1Z83q9kh4 KnKp+Z34oQpFrhQhSccroKEKR8fJLqXIoQmI0FTCELvMudCEIWhXEIQoTAAH1Fup/FWbGAJGJEZd pz7MHQhcr22qIQhbS7SPTZx/wP1+q7dOxkIQvLz7un7P/9k= ------=_NextPart_000_0002_01C8AA13.026BF6F2-- --===============0882890812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0882890812==-- From mpls-bounces@ietf.org Wed Apr 30 02:32:34 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36DE28C37A; Wed, 30 Apr 2008 02:32:34 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613FC28C0DF for ; Wed, 30 Apr 2008 02:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp3yfWBGxIbj for ; Wed, 30 Apr 2008 02:32:24 -0700 (PDT) Received: from av12-1-sn2.hy.skanova.net (av12-1-sn2.hy.skanova.net [81.228.8.185]) by core3.amsl.com (Postfix) with ESMTP id 5192C28C17C for ; Wed, 30 Apr 2008 02:32:22 -0700 (PDT) Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 5B97D38528; Wed, 30 Apr 2008 11:32:24 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 434FE38531 for ; Wed, 30 Apr 2008 11:32:24 +0200 (CEST) Received: from [127.0.0.1] (h4n2fls31o874.telia.com [213.66.236.4]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2A4E837E51 for ; Wed, 30 Apr 2008 11:32:23 +0200 (CEST) Message-ID: <48183CA2.1010103@pi.se> Date: Wed, 30 Apr 2008 11:32:18 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org References: <47F0A26B.3050802@pi.se> <48049402.2050802@pi.se> In-Reply-To: <48049402.2050802@pi.se> X-Enigmail-Version: 0.95.6 Subject: Re: [mpls] wg last call on draft-ietf-mpls-p2mp-te-mib-06.txt - ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, tis wg last call has ended, could the authors please take care of the comments and republish the document. /Loa Loa Andersson wrote: > All, > > we have been running this wg last call for two weeks, but we > have not seen any comments; the wg last call is therefore > extended to April 25. > > Loa and George > > > > Loa Andersson wrote: >> Hi MPLS chairs, >> >> This is to initiate a working group last call on >> P2MP MPLS-TE MIB module >> . >> >> The MIB module has been through an earl MIB Dr. review and >> there has also been comments from experienced MIB implementors. >> This resulted in various updates and version - 06 is the >> result of this process. >> >> Please send your comments to the working group mailing list or >> to the working group chairs not later than April 13. >> >> 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@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 30 03:30:03 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B21A3A6DBF; Wed, 30 Apr 2008 03:30:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3F55B3A6DBF; Wed, 30 Apr 2008 03:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080430103001.3F55B3A6DBF@core3.amsl.com> Date: Wed, 30 Apr 2008 03:30:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-p2mp-te-mib-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-p2mp-te-mib-07.txt Pages : 58 Date : 2008-04-30 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-te-mib-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-te-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-30032324.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Wed Apr 30 03:34:55 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326493A6B72; Wed, 30 Apr 2008 03:34:55 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEE13A6B72 for ; Wed, 30 Apr 2008 03:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ardu4plLXNnZ for ; Wed, 30 Apr 2008 03:34:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 4C86B3A6899 for ; Wed, 30 Apr 2008 03:34:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3UAYrdJ018706 for ; Wed, 30 Apr 2008 11:34:53 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3UAYnXo018669 for ; Wed, 30 Apr 2008 11:34:51 +0100 Message-ID: <03bc01c8aaad$cf69ca20$0400a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 30 Apr 2008 11:34:39 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [mpls] Fw: I-D Action:draft-ietf-mpls-p2mp-te-mib-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Changes, as noted in section zero... - Section 4. Clarify the source-to-leaf model of P2MP LSPs. - Section 4. Note that GMPLS P2MP LSPs must be unidirectional. - Section 5.2. Clarify RSVP message exchanges in the example. - Typos. Thanks for comments made during WG last call. Adrian >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: Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic > Engineering (TE) Management Information Base (MIB) module > Author(s) : A. Farrel, et al. > Filename : draft-ietf-mpls-p2mp-te-mib-07.txt > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-te-mib-07.txt _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Apr 30 10:12:22 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7E53A6B8E; Wed, 30 Apr 2008 10:12:22 -0700 (PDT) X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7573A692B for ; Wed, 30 Apr 2008 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.275 X-Spam-Level: X-Spam-Status: No, score=-12.275 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, JM_REACTOR_MAILER=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+++nRDZRF0Y for ; Wed, 30 Apr 2008 10:12:20 -0700 (PDT) Received: from 80.174.182.30.dyn.user.ono.com (unknown [80.174.182.30]) by core3.amsl.com (Postfix) with ESMTP id 4C1573A6916 for ; Wed, 30 Apr 2008 10:12:19 -0700 (PDT) Message-ID: <000501c8aae5$016d36c6$b919fab7@ayhymeaq> From: "aldrich tony" To: Date: Wed, 30 Apr 2008 15:24:31 +0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [mpls] 70% discount. Coupon #dQlB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1634484197==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============1634484197== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C8AAE5.01689142" This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C8AAE5.01689142 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi mpls, be clever, buy your pharmaceuticals from the best onine shop = since 2000. ------=_NextPart_000_0002_01C8AAE5.01689142 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi mpls, be clever, buy your pharmaceuticals from the best onine shop since 2000.

------=_NextPart_000_0002_01C8AAE5.01689142-- --===============1634484197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1634484197==-- From mpls-bounces@ietf.org Wed Apr 30 14:00:02 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D3528C3B9; Wed, 30 Apr 2008 14:00:02 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 82C1A3A6943; Wed, 30 Apr 2008 14:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080430210001.82C1A3A6943@core3.amsl.com> Date: Wed, 30 Apr 2008 14:00:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-upstream-label-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Upstream Label Assignment and Context-Specific Label Space Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-upstream-label-05.txt Pages : 13 Date : 2008-04-30 RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-upstream-label-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-upstream-label-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-30135854.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart--