From mailman-bounces@ietf.org Fri Oct 1 05:37:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10587 for ; Fri, 1 Oct 2004 05:37:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJz5-0002m8-Ns for mpls-archive@ietf.org; Fri, 01 Oct 2004 05:45:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJLL-000354-5Q for mpls-archive@ietf.org; Fri, 01 Oct 2004 05:04:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mpls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:01:18 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for mpls-archive@ietf.org: List Password // URL ---- -------- mpls@lists.ietf.org duubek https://www1.ietf.org/mailman/options/mpls/mpls-archive%40ietf.org From mpls-bounces@ietf.org Fri Oct 1 11:02:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07158; Fri, 1 Oct 2004 11:02:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDP3i-0000aD-D7; Fri, 01 Oct 2004 11:10:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKKC-0003wz-Ni; Fri, 01 Oct 2004 06:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJMn-0003IE-RZ for mpls@megatron.ietf.org; Fri, 01 Oct 2004 05:06:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08290 for ; Fri, 1 Oct 2004 05:06:15 -0400 (EDT) Received: from web8501.mail.in.yahoo.com ([202.43.219.163]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDJVA-00025B-Dl for mpls@ietf.org; Fri, 01 Oct 2004 05:15:00 -0400 Message-ID: <20041001090540.94084.qmail@web8501.mail.in.yahoo.com> Received: from [203.200.200.162] by web8501.mail.in.yahoo.com via HTTP; Fri, 01 Oct 2004 10:05:40 BST Date: Fri, 1 Oct 2004 10:05:40 +0100 (BST) From: Harish Kumtakar To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 8bit Subject: [mpls] Fast Reroute - Path message onto a bypass tunnel X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 8bit <1> I've a question on draft 'draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt' The question is related to the Path message handling sent over the bypass tunnel (facility backup) for the protected LSP before/after failure. Consider the following example, [R1]---[R2]----[R3]----[R4]---[R5] \\ // [R6]===[R7] Protected LSP : [R1->R2->R3->R4->R5] Bypass LSP Tunnel: [R2->R6->R7->R4] Section 7.4.4 of the draft says, More specifically, the PLR MUST: - remove all the sub-objects proceeding the first address belonging to the MP. - replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.) So, the ERO of the Path message sent over the bypass tunnel contains the IP address of MP (i.e R4) as its sub-object. Now, when R6 recieves this Path message, as per the ERO processing rules specified in Section 4.3.4 of RFC 3209:Extensions to RSVP for LSP Tunnels, should it not return "Bad initial subobject" error to PLR R2? I know I'm definitely missing something here OR my understanding of the draft itself is partially incorrect. Please clear the grey area, TIA, Regards, -Harish ===== ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 1 12:33:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21900; Fri, 1 Oct 2004 12:33:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQTY-0002ZE-4q; Fri, 01 Oct 2004 12:41:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDP8V-0000fu-DH; Fri, 01 Oct 2004 11:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKcE-0003aX-KU for mpls@megatron.ietf.org; Fri, 01 Oct 2004 06:26:18 -0400 Received: from web8502.mail.in.yahoo.com (web8502.mail.in.yahoo.com [202.43.219.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14638 for ; Fri, 1 Oct 2004 06:26:15 -0400 (EDT) Message-ID: <20041001102524.74202.qmail@web8502.mail.in.yahoo.com> Received: from [203.200.200.162] by web8502.mail.in.yahoo.com via HTTP; Fri, 01 Oct 2004 11:25:24 BST Date: Fri, 1 Oct 2004 11:25:24 +0100 (BST) From: Harish Kumtakar To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [mpls] Fast Reroute - Path message onto a bypass tunnel X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 8bit I've a question on draft 'draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt' The question is related to the Path message handling sent over the bypass tunnel (facility backup) for the protected LSP before/after failure. Consider the following example, [R1]---[R2]----[R3]----[R4]---[R5] \\ // [R6]===[R7] Protected LSP : [R1->R2->R3->R4->R5] Bypass LSP Tunnel: [R2->R6->R7->R4] Section 7.4.4 of the draft says, More specifically, the PLR MUST: - remove all the sub-objects proceeding the first address belonging to the MP. - replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.) So, the ERO of the Path message sent over the bypass tunnel contains the IP address of MP (i.e R4) as its sub-object. (My understanding is that, all the sub-objects that appear before MP's address are removed from ERO) Now, when R6 recieves this Path message, as per the ERO processing rules specified in Section 4.3.4 of RFC 3209:Extensions to RSVP for LSP Tunnels, should it not return "Bad initial subobject" error to PLR R2? I know I'm definitely missing something here OR my understanding of the draft itself is partially incorrect. Please clear the grey area, TIA, Regards, -Harish ===== ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 1 13:48:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00892; Fri, 1 Oct 2004 13:48:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDReX-0005eP-4U; Fri, 01 Oct 2004 13:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDREU-0000OI-Cr; Fri, 01 Oct 2004 13:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQe5-0007mc-It for mpls@megatron.ietf.org; Fri, 01 Oct 2004 12:52:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23946 for ; Fri, 1 Oct 2004 12:52:34 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQmW-0003E1-Qz for mpls@ietf.org; Fri, 01 Oct 2004 13:01:24 -0400 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i91Gpm75012120; Fri, 1 Oct 2004 12:51:48 -0400 Message-Id: <5.1.0.14.2.20041001125126.020ab320@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Oct 2004 12:52:01 -0400 To: Harish Kumtakar From: Alia Atlas Subject: Re: [mpls] Fast Reroute - Path message onto a bypass tunnel In-Reply-To: <20041001090540.94084.qmail@web8501.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 R6 doesn't receive the path message because it is encapsulated inside the bypass tunnel. Alia At 05:05 AM 10/1/2004, Harish Kumtakar wrote: ><1> > >I've a question on draft >'draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt' >The question is related to the Path message handling >sent over the bypass tunnel (facility backup) for the >protected LSP before/after failure. > >Consider the following example, > > [R1]---[R2]----[R3]----[R4]---[R5] > \\ // > [R6]===[R7] > > Protected LSP : [R1->R2->R3->R4->R5] > Bypass LSP Tunnel: [R2->R6->R7->R4] > >Section 7.4.4 of the draft says, > > More specifically, the PLR MUST: > > - remove all the sub-objects proceeding the first >address belonging > to the MP. > > - replace this first MP address with an IP >address of the MP. > (Note that this could be same address that was >just removed.) > >So, the ERO of the Path message sent over the bypass >tunnel contains the IP address of MP (i.e R4) as its >sub-object. > >Now, when R6 recieves this Path message, as per the >ERO processing rules specified in Section 4.3.4 of RFC >3209:Extensions to RSVP for LSP Tunnels, should it not >return "Bad initial subobject" error to PLR R2? I know >I'm definitely missing something here OR my >understanding of the draft itself is partially >incorrect. > >Please clear the grey area, > >TIA, Regards, >-Harish > >===== > > > >________________________________________________________________________ >Yahoo! India Matrimony: Find your life partner online >Go to: http://yahoo.shaadi.com/india-matrimony > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 1 14:15:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03166; Fri, 1 Oct 2004 14:15:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDS5E-0006RL-6j; Fri, 01 Oct 2004 14:24:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRXv-0006Z1-C2; Fri, 01 Oct 2004 13:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRJq-0002pv-Cd for mpls@megatron.ietf.org; Fri, 01 Oct 2004 13:35:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28973 for ; Fri, 1 Oct 2004 13:35:43 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRSL-000511-3M for mpls@ietf.org; Fri, 01 Oct 2004 13:44:33 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D5B2EB76A3D; Fri, 1 Oct 2004 10:35:41 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17490-10; Fri, 1 Oct 2004 10:35:41 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 3CC1CB76A3C; Fri, 1 Oct 2004 10:35:41 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id KAA04146; Fri, 1 Oct 2004 10:35:41 -0700 (PDT) Message-Id: <200410011735.KAA04146@redback.com> To: Harish Kumtakar Subject: Re: [mpls] Fast Reroute - Path message onto a bypass tunnel In-reply-to: Mail from Harish Kumtakar dated Fri, 01 Oct 2004 11:25:24 BST <20041001102524.74202.qmail@web8502.mail.in.yahoo.com> Date: Fri, 01 Oct 2004 10:35:40 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 the trick is for R2 to send the path msg 'directly' to R4 through the tunnel, not hop-by-hop. ] ] I've a question on draft ] 'draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt' ] The question is related to the Path message handling ] sent over the bypass tunnel (facility backup) for the ] protected LSP before/after failure. ] ] Consider the following example, ] ] [R1]---[R2]----[R3]----[R4]---[R5] ] \\ // ] [R6]===[R7] ] ] Protected LSP : [R1->R2->R3->R4->R5] ] Bypass LSP Tunnel: [R2->R6->R7->R4] ] ] Section 7.4.4 of the draft says, ] ] More specifically, the PLR MUST: ] ] - remove all the sub-objects proceeding the first ] address belonging ] to the MP. ] ] - replace this first MP address with an IP ] address of the MP. ] (Note that this could be same address that was ] just removed.) ] ] So, the ERO of the Path message sent over the bypass ] tunnel contains the IP address of MP (i.e R4) as its ] sub-object. (My understanding is that, all the ] sub-objects that appear before MP's address are ] removed from ERO) ] ] Now, when R6 recieves this Path message, as per the ] ERO processing rules specified in Section 4.3.4 of RFC ] 3209:Extensions to RSVP for LSP Tunnels, should it not ] return "Bad initial subobject" error to PLR R2? I know ] I'm definitely missing something here OR my ] understanding of the draft itself is partially ] incorrect. ] ] Please clear the grey area, ] ] TIA, Regards, ] -Harish ] ] ] ===== ] ] ] ] ________________________________________________________________________ ] Yahoo! India Matrimony: Find your life partner online ] Go to: http://yahoo.shaadi.com/india-matrimony ] ] _______________________________________________ ] mpls mailing list ] mpls@lists.ietf.org ] https://www1.ietf.org/mailman/listinfo/mpls - Naiming _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 1 17:18:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22218; Fri, 1 Oct 2004 17:18:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDUvs-0001eS-7W; Fri, 01 Oct 2004 17:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTmz-0007rU-Ex; Fri, 01 Oct 2004 16:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTR2-00032D-FB; Fri, 01 Oct 2004 15:51:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11151; Fri, 1 Oct 2004 15:51:18 -0400 (EDT) Message-Id: <200410011951.PAA11151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 01 Oct 2004 15:51:18 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-soft-preemption-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Traffic Engineering Soft preemption Author(s) : M. Meyer, et al. Filename : draft-ietf-mpls-soft-preemption-03.txt Pages : 12 Date : 2004-10-1 This document details MPLS Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/eliminating traffic disruption of preempted Traffic Engineered Label Switched Paths. Initially MPLS RSVP-TE was defined supporting only immediate Label Switched Path displacement upon preemption. The utilization of a preemption pending flag helps more gracefully mitigate the re-route process of preempted Label Switched Paths. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the Label Switched Path can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-soft-preemption-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-soft-preemption-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-1153638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-soft-preemption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-soft-preemption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-1153638.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Fri Oct 1 20:07:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11912; Fri, 1 Oct 2004 20:07:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDXZp-0001O7-De; Fri, 01 Oct 2004 20:16:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDXBD-0006d9-E3; Fri, 01 Oct 2004 19:51:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDX1z-0007jt-Fu for mpls@megatron.ietf.org; Fri, 01 Oct 2004 19:41:43 -0400 Received: from MailEssentials.sta.samsung.com (mail1.sta.samsung.com [63.166.115.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10553 for ; Fri, 1 Oct 2004 19:41:40 -0400 (EDT) Received: from OWA.telecom.sna.samsung.com ([105.52.12.211]) by MailEssentials.sta.samsung.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Oct 2004 18:40:56 -0500 Received: from mx1.telecom.sna.samsung.com ([105.52.12.120]) by OWA.telecom.sna.samsung.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 18:41:11 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 1 Oct 2004 18:40:56 -0500 Message-ID: <94ACE02E80F7804DB54C816CA9AA331C07E922@mx1.telecom.sna.samsung.com> Thread-Topic: RSVP-TE control message forwarding Thread-Index: AcSoEBiJgkYLpI6vReek0J13DLmA3A== From: "Ning Zhuang" To: X-OriginalArrivalTime: 01 Oct 2004 23:41:11.0531 (UTC) FILETIME=[21EC8BB0:01C4A810] Subject: [mpls] RSVP-TE control message forwarding X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0381181557==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 This is a multi-part message in MIME format. --===============0381181557== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A810.18BEA711" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A810.18BEA711 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I'd like to ask a question related to RSVP-TE control messages forwarding. Assume CSPF is not turned on, do we want to allow the RSVP-TE control messages to go through MPLS LSPs? A further question would be when we do the nexthop lookup for the RSVP-TE control messages, do we considered the IGP shortcut routes? (This question apply to both ingress and transit nodes). Also, does anybody know Cisco's implementation for this issue? =20 Thanks, =20 Ning Zhuang Samsung Enterprise Network Lab P. (408)-544-4615 F. (408)-544-4617 nzhuang@sta.samsung.com =20 ------_=_NextPart_001_01C4A810.18BEA711 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I’d like to ask a question related to RSVP-TE = control messages forwarding. Assume CSPF is not turned on, do = we

want to allow the RSVP-TE control messages to go = through MPLS LSPs? A further question would be when we

do the nexthop lookup for the RSVP-TE control = messages, do we considered the IGP shortcut routes? (This question

apply to both ingress and transit nodes). Also, does = anybody know Cisco’s implementation for this issue?

 

Thanks,

 

Ning Zhuang

Samsung = Enterprise Network Lab

P. = (408)-544-4615

F. = (408)-544-4617

nzhuang@sta.samsung.com

 

=00 ------_=_NextPart_001_01C4A810.18BEA711-- --===============0381181557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0381181557==-- From mpls-bounces@ietf.org Sat Oct 2 14:33:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01056; Sat, 2 Oct 2004 14:33:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDopX-0000YC-FK; Sat, 02 Oct 2004 14:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDocy-00014i-S3; Sat, 02 Oct 2004 14:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDoZu-0008JO-Nx for mpls@megatron.ietf.org; Sat, 02 Oct 2004 14:25:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00799 for ; Sat, 2 Oct 2004 14:25:53 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDoic-0000Q0-RZ for mpls@ietf.org; Sat, 02 Oct 2004 14:34:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Oct 2004 11:39:33 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i92IPIEE026358; Sat, 2 Oct 2004 11:25:18 -0700 (PDT) Received: from [66.189.47.89] (rtp-vpn2-218.cisco.com [10.82.240.218]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA18616; Sat, 2 Oct 2004 11:25:20 -0700 (PDT) In-Reply-To: <94ACE02E80F7804DB54C816CA9AA331C07E922@mx1.telecom.sna.samsung.com> References: <94ACE02E80F7804DB54C816CA9AA331C07E922@mx1.telecom.sna.samsung.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <6B272314-14A0-11D9-976D-000D93330B14@cisco.com> From: JP Vasseur Subject: Re: [mpls] RSVP-TE control message forwarding Date: Sat, 2 Oct 2004 14:25:20 -0400 To: "Ning Zhuang" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0471450677==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc --===============0471450677== Content-Type: multipart/alternative; boundary=Apple-Mail-6-322720334 --Apple-Mail-6-322720334 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On Oct 1, 2004, at 7:40 PM, Ning Zhuang wrote: > Hi All, > > =A0 > > I=92d like to ask a question related to RSVP-TE control messages=20 > forwarding. Assume CSPF is not turned on, do we > > want to allow the RSVP-TE control messages to go through MPLS LSPs? Path computation is orthogonal to signaling: in other words, the path=20 can be computed in a distributed or centralized fashion, using CSPF or=20= any other algorithms. Then RSVP-TE is in charge of establishing the TE=20= LSP by means of signaling. > A further question would be when we > > do the nexthop lookup for the RSVP-TE control messages, do we=20 > considered the IGP shortcut routes? (This question > > apply to both ingress and transit nodes). On the topic of how to steer traffic to a particular TE LSP instead of=20= following the IGP shortest path, should both paths be distinct, there=20 are several mechanisms: take the TE LSP into account during RIB=20 computation, use of static route for specific traffic and so on. > Also, does anybody know Cisco=92s implementation for this issue? > Since this is an IETF mailing list, it is probably more appropriate to=20= ask the question on other lists. In short, the answer is yes, and there=20= are many possible mechanisms. JP. > =A0 > > Thanks, > > =A0 > > Ning Zhuang > > Samsung Enterprise Network Lab > > P. (408)-544-4615 > > F. (408)-544-4617 > > nzhuang@sta.samsung.com > > =A0 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls --Apple-Mail-6-322720334 Content-Type: text/enriched; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, On Oct 1, 2004, at 7:40 PM, Ning Zhuang wrote: Hi = All, = =A0 I=92d like to ask a question related to RSVP-TE control messages forwarding. Assume CSPF is not turned on, do = we want to allow the RSVP-TE control messages to go through MPLS LSPs? Path computation is orthogonal to signaling: in other words, the path can be computed in a distributed or centralized fashion, using CSPF or any other algorithms. Then RSVP-TE is in charge of establishing the TE LSP by means of signaling.=20 A further question would be when = we do the nexthop lookup for the RSVP-TE control messages, do we considered the IGP shortcut routes? (This = question= apply to both ingress and transit nodes).=20 On the topic of how to steer traffic to a particular TE LSP instead of following the IGP shortest path, should both paths be distinct, there are several mechanisms: take the TE LSP into account during RIB computation, use of static route for specific traffic and so on.=20 Also, does anybody know Cisco=92s implementation for this = issue? Since this is an IETF mailing list, it is probably more appropriate to ask the question on other lists. In short, the answer is yes, and there are many possible mechanisms. JP. = =A0 = Thanks,= = =A0 Apple = Chancery8080,8080,FFFFNing Zhuang = 8080,8080,FFFFSamsung Enterprise Network = Lab = 8080,8080,FFFFP. = (408)-544-4615 = 8080,8080,FFFFF. = (408)-544-4617 = 0000,0000,FFFFnzhuang@sta.samsung.com Times New = Roman=A0<= /fontfamily> _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls = --Apple-Mail-6-322720334-- --===============0471450677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0471450677==-- From mpls-bounces@ietf.org Mon Oct 4 11:49:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15413; Mon, 4 Oct 2004 11:49:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEVFC-0003PF-80; Mon, 04 Oct 2004 11:59:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEV4C-0006LH-SN; Mon, 04 Oct 2004 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETz5-0004wj-6Y for mpls@megatron.ietf.org; Mon, 04 Oct 2004 10:38:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10218 for ; Mon, 4 Oct 2004 10:38:36 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEU8A-0003hO-OO for mpls@ietf.org; Mon, 04 Oct 2004 10:48:03 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb8ND019838; Mon, 4 Oct 2004 23:37:08 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb7Wa013430; Mon, 4 Oct 2004 23:37:07 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb7o0013427; Mon, 4 Oct 2004 23:37:07 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb62r006049; Mon, 4 Oct 2004 23:37:07 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb6Ew006046; Mon, 4 Oct 2004 23:37:06 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb6il025291; Mon, 4 Oct 2004 23:37:06 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb5PR020337; Mon, 4 Oct 2004 23:37:06 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb52H020334; Mon, 4 Oct 2004 23:37:05 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id XAA21854; Mon, 4 Oct 2004 23:37:05 +0900 (JST) Message-Id: <5.0.2.5.2.20041004232056.055feeb8@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Mon, 04 Oct 2004 23:49:39 +0900 To: mpls@ietf.org From: Seisho Yasukawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-Mailman-Approved-At: Mon, 04 Oct 2004 11:47:58 -0400 Cc: andy.malis@tellabs.com, jpv@cisco.com, dimitri.papadimitriou@alcatel.be Subject: [mpls] Requesting Help With Unresolved P2MP MPLS TE Requirements X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Dear list, We have just published http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-requirement-04.txt which you would find a notable update on the previous revision. The draft contains changes to reflect feedback from the mailing list, private discussions, and from the work of the P2MP MPLS TE signaling solutions team. The draft, titled "Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", aims to focus only on the requirements for establishing point-to-multipoint TE LSPs. That is, it is not concerned with multicast MPLS, but only with P2MP traffic engineering. Several issues remain unresolved in the current version of the draft and I (as editor) would like to solicit your input to help resolve them. The issues are described below and may be found in the draft by searching for the key word "DISCUSS". Please email your thoughts to the MPLS list or to me privately. Many thanks, Seisho Yasukawa ---------------------------------------------------- Issue 1 : Variation of LSP Parameters on different LSP Branches. (section 5.9) Is it a requirement that any of the parameters of an LSP (such as priority, bandwidth, etc.) are allowed to vary on different branches of the P2MP LSP? If so, which parameters and under what circumstances? Currently the draft states that no variation by any transit node is allowed for any parameter set by the ingress, and that homogenous QoS must be provided from the root to all leaves. ---------------------------------------------------- Issue 2 : Partial Re-optimization Initiated by Transit Nodes. (section 5.10) Is it a requirement that a branch node should be able to *independently* re-optimize the P2MP tree downstream of the branch point? There are two questions here: a. Should the branch node have the facility to set up an alternate P2MP tree downstream of the branch and then splice the traffic onto that tree, or should all re-optimization be as the result of the generation of a new P2MP path at the ingress? b. If the branch is capable of performing this function, should it be controlled (i.e. given explicit permission) by the ingress? ---------------------------------------------------- Issue 3 : Tree Re-merge (section 5.11) If (for whatever reason) the P2MP LSP re-merges what should be the behavior in the control and data planes? Consider a node that receives two LSP setup request messages on different upstream interfaces each relating to the same P2MP LSP, but each identifying a different set of receivers. (We may assume that somewhere upstream a branch decision was made that was not necessary.) Further, consider that the two LSP setup messages are forwarded out of the same downstream interface. What should happen in the data plane? There MUST/SHOULD/MAY/SHOULD_NOT be a sharing of labels and resources on the downstream interface? (see also issue 4) What should happen in the control plane? The downstream interface MUST/SHOULD/MAY/SHOULD_NOT see a single LSP setup message that is built by merging the two received requests? Or: should we say that this situation is pathologically broken and attempt to select only one of the setup requests while failing the other? ---------------------------------------------------- Issue 4 : Handling Data Duplication (section 5.12) Can data duplication be tolerated or must every possible measure be taken to prevent it? It is well-known that some applications are sensitive to the receipt of duplicate data, but the manipulation of P2MP trees, in particular in the presence of re-merge (see issue3), but also during tree modification procedures, may lead to duplicate data being delivered to a receiver. Thus, duplication may arise as the result of legitimate network operations. The draft currently states that the solution MUST provide a mechanism to resolve, limit or avoid data duplication at either or both of the point at which the data path diverges and the point at which the data paths converge. ---------------------------------------------------- Issue 5 : Absolute Limits and Design Targets (section 5.19.1) In order to guide the solutions team we have attempted to provide some limits for the scaling and rate of change of P2MP MPLS TE LSP. We are aware that limiting the requirements to traffic engineering should imply some qualitative differences from, say, multicast trees, but we have struggled with determining the absolutes (or even approximations) that are needed to help the solutions team prioritize the different features of the protocol solution. It may be that no specific values can be stated, but that some general principles do exist. Currently we are trying to make statements about the following points for an individual P2MP TE LSP. - Number of recipients. - Number of branch points. - Rate of change of recipients. - Rate of change of core topology. Are you satisfied with current text ? What are appropriate target conditions for above numbers ? ---------------------------------------------------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 5 14:59:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25772; Tue, 5 Oct 2004 14:59:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEug0-00027w-2X; Tue, 05 Oct 2004 15:08:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEuN3-0001e8-9Y; Tue, 05 Oct 2004 14:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEuFs-0008N4-Dh for mpls@megatron.ietf.org; Tue, 05 Oct 2004 14:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24021 for ; Tue, 5 Oct 2004 14:41:42 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEuPB-0007jh-MF for mpls@ietf.org; Tue, 05 Oct 2004 14:51:22 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2004 20:51:51 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i95IefVI025214; Tue, 5 Oct 2004 20:41:07 +0200 (MEST) Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 20:40:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Oct 2004 20:40:45 +0200 Message-ID: Thread-Topic: "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP Thread-Index: AcSrCtMgyn6wcLEaRSmncgLL4dU43Q== From: "Monique Morrow \(mmorrow\)" To: X-OriginalArrivalTime: 05 Oct 2004 18:40:46.0173 (UTC) FILETIME=[D3A030D0:01C4AB0A] X-Spam-Score: 0.9 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 Cc: "Tom Nadeau \(tnadeau\)" Subject: [mpls] "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0862019514==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f This is a multi-part message in MIME format. --===============0862019514== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AB0A.D35AB37B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AB0A.D35AB37B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "Challenges in Enabling Inter-Provider Service Quality on the Internet." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Regards, Monique =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************ ******************************************** As carriers and service providers build multi-services networks based on IP/MPLS-enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end,improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm =20 Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided there is consent of the Guest Editor;more than three equations require permission from the Editor-in-Chief).=20 Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html . ** Please submit no later than 30 October 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: 30 October 2004 Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C4AB0A.D35AB37B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,

The IEEE Communications Magazine has just = approved=20 the publication of

a Feature Topic issue on "Challenges in = Enabling=20 Inter-Provider Service Quality = on the=20 Internet." The CFP is attached=20 below.

We invite those working in this = area to=20 consider sending in = their contributions. If you intend to submit a = paper for=20 this

special issue, please do drop one = of the Guest=20 Editors a note, so that we can plan the issue.

We look forward to your = participation!

Regards, = Monique

=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

CALL FOR PAPERS

IEEE Communications Magazine

Feature Topic on=20 "Challenges in Enabling = Inter-Provider Service Quality on the Internet"

****************************************************************= ****************************************************

As carriers and service providers build=20 multi-services networks based on

IP/MPLS-enabled=20 infrastructures that are able to meet evermore stringent = service

level=20 agreements (SLAs) and=20 quality-of-service (QoS) requirements, it becomes a

key=20 issue to extend the = ability to=20 deliver these services across carrier and

service=20 provider domain = boundaries, while=20 at the same time preserving the same SLAs

and=20 QoS assurances as those = provided=20 within a given provider's network.

The advent of new end-user = applications, as=20 well as new services based on=20 MPLS technology, such = as Layer 2=20 Virtual Private LAN Services (VPLS) and

Layer 3 Virtual Private Networks = (L3VPNs), also=20 means the emergence of = added service quality

requirements from operators = deploying and=20 interoperating these networks and = the end-users=20 themselves. As a result, providers and vendors require = efficient

means to=20 enable inter-provider service quality, which comprises of several = key elements including=20 quality of service, class of service, security, OAM, and

restoration and=20 repair.

This will is lead to the emergence = of improved=20 or novel tools and techniques=20 to address these = aspects, with the=20 goal of guaranteeing service quality

end-to-end,improving=20 security and billing/accounting, and reducing operating = costs.

Standards=20 organizations such as the IETF and the ITU are taking on = significant work=20 in this

area, and various aspects of this = subject are=20 also being investigated by=20 bodies such

as the OIF, the MSF, the MPLS/Frame = Relay=20 Alliance, the IEEE, and the Metro=20 Ethernet Forum, and are = the themes=20 for numerous upcoming conferences.

This feature topic issue of the = IEEE=20 Communications Magazine has a=20 multi-pronged

focus on the delivery of inter-provider = service=20 quality:

* Highlight operator and end-user = concerns and=20 requirements.

* Feature current and/or planned = deployment=20 experiences.

* Survey modern research and engineering=20 developments.

* Spotlight contemporary standards=20 activity.

Thus, focused tutorial and survey = contributions=20 as well as research papers=20 are

solicited on (but certainly not limited = to) the=20 following topics:

* Carrier requirements for efficient = inter-provider=20 service quality: Current

operational needs, bottlenecks, future=20 demands

* Deployment experience with = inter-provider service=20 quality on IP/MPLS-

based networks: comparative analysis, = case=20 studies

* QoS management in an inter-provider = environment:=20 interconnection

architectures using MPLS, Diffserv, QoS = performance,=20 path

characterization, routing = policies

* Service assurance in inter-provider=20 infrastructures: End-to-end SLA

management, service billing/reporting, = admission=20 control

* Failure and restoration = requirements/challenges in=20 inter-provider contexts

* Interoperability and inter-working of = diverse=20 equipment types and

technologies (ATM, FR, = Ethernet)

* Current engineering and research = developments: E.g.=20 Passive and active

performance measurement and monitoring, = TE, modelling=20 and simulation

* Standards activities and initiatives: = new services=20 and network

architectures

On-line CFP with submission instructions = can be found=20 at:

http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm=

Submission

Articles should be tutorial in nature and = should be=20 written in a style

comprehensible

to readers outside the specialty of the = article.=20 Articles may be edited for

clarity and grammatical accuracy, and = will be=20 copyedited according to the

Magazine's style.

Mathematical equations should not = be used (in=20 justified cases up to three=20 simple

equations could be allowed, provided = there is consent=20 of the Guest Editor;more = than

three equations require permission from = the=20 Editor-in-Chief).

Articles should have no=20 more than 4,500 words, no more than 6 tables/figures, and = no more=20 than 15

references. Guidelines for prospective = authors can be=20 found on-line at

http://www.comsoc.org/pubs/commag/sub_guidelines.html= .

** Please submit no later than 30 October = 2004.**

Accepted papers will also be included in=20 Communications

Interactive (CI), the online version of=20 Communications Magazine.

Manuscript Due: 30 October = 2004

Acceptance Notification: 15 January = 2004

Final Manuscript Due: 28 February = 2005

Publication Date: June 2005

Guest Editors

Monique J. Morrow, Cisco Systems,=20 (mmorrow@cisco.com)

Vishal Sharma, Metanoia, Inc.=20 (v.sharma@ieee.org)

Thomas D.Nadeau, Cisco Systems=20 (tnadeau@cisco.com)

Loa Andersson, Acreo = (loa@pi.se)

 

 
 
 
 
 
------_=_NextPart_001_01C4AB0A.D35AB37B-- --===============0862019514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0862019514==-- From mpls-bounces@ietf.org Wed Oct 6 06:08:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08371; Wed, 6 Oct 2004 06:08:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8sd-0006LN-Aq; Wed, 06 Oct 2004 06:18:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8hI-0002BT-SL; Wed, 06 Oct 2004 06:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8cQ-0001kY-9X for mpls@megatron.ietf.org; Wed, 06 Oct 2004 06:01:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07869 for ; Wed, 6 Oct 2004 06:01:55 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8ls-0005om-O9 for mpls@ietf.org; Wed, 06 Oct 2004 06:11:46 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96A39hZ007354 for ; Wed, 6 Oct 2004 03:03:09 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i96A1omY028623 for ; Wed, 6 Oct 2004 05:01:51 -0500 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Oct 2004 15:31:49 +0530 Message-ID: <653138C25D8AD6118292000347080A370B478D94@zin05exm02.corp.mot.com> From: Dillikar Satyanarayana-G19471 To: "'mpls@ietf.org'" , "'mpls-ops@mplsrc.com'" Date: Wed, 6 Oct 2004 15:31:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarification needed. X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi, We have some confusion in understanding the Data Plane Capability Flags (B-bit & E-bit) from draft-vasseur-ccamp-te-router-info-00.txt (a) Does E-bit ON implies B-bit ON always ? (assuming ON = set and OFF = unset). (b) E-bit = ON & B-bit = OFF, is it a valid combination. (c) Please tell us the E-bit and B-bit status for a node which is a destination node but does not have branch capability. We are also curious to know (1)The idea behind combing two things (egress status & transit status) in a single E-bit. rather than making use of B-bit(branch) and having E-bit just for egress status. (2) Why the TE Node Capability Descriptor TLV should have E-bit & how it should be used in CSPF path computation. Thanks Satya _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 6 21:16:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06912; Wed, 6 Oct 2004 21:16:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFN2k-0001YS-HL; Wed, 06 Oct 2004 21:26:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFMmJ-0005l0-9h; Wed, 06 Oct 2004 21:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7JK-0005s0-EO for mpls@megatron.ietf.org; Wed, 06 Oct 2004 04:38:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02059 for ; Wed, 6 Oct 2004 04:38:08 -0400 (EDT) Received: from web51103.mail.yahoo.com ([206.190.38.145]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CF7Sl-0000mD-TN for mpls@ietf.org; Wed, 06 Oct 2004 04:47:57 -0400 Message-ID: <20041006083738.91829.qmail@web51103.mail.yahoo.com> Received: from [203.126.136.220] by web51103.mail.yahoo.com via HTTP; Wed, 06 Oct 2004 01:37:38 PDT Date: Wed, 6 Oct 2004 01:37:38 -0700 (PDT) From: Satyanarayana Dillikar To: mpls@ietf.org, mpls-ops@mplsrc.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Wed, 06 Oct 2004 21:09:05 -0400 Subject: [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarification needed. X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi, We have some confusion in understanding the Data Plane Capability Flags (B-bit & E-bit) from draft-vasseur-ccamp-te-router-info-00.txt (a) Does E-bit ON implies B-bit ON always ? (assuming ON = set and OFF = unset). (b) E-bit = ON & B-bit = OFF, is it a valid combination. (c) Please tell us the E-bit and B-bit status for a node which is a destination node but does not have branch capability. We are also curious to know (1)The idea behind combing two things (egress status & transit status) in a single E-bit. rather than making use of B-bit(branch) and having E-bit just for egress status. (2) Why the TE Node Capability Descriptor TLV should have E-bit & how it should be used in CSPF path computation. Thanks Satya _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 03:37:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19035; Thu, 7 Oct 2004 03:37:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFSzX-0007ub-7C; Thu, 07 Oct 2004 03:47:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFSj4-0001gE-Bb; Thu, 07 Oct 2004 03:30:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFSY1-0007g3-PV for mpls@megatron.ietf.org; Thu, 07 Oct 2004 03:18:46 -0400 Received: from oberon.imc.kth.se (oberon.imc.kth.se [193.10.152.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17619 for ; Thu, 7 Oct 2004 03:18:43 -0400 (EDT) Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i977Eor30169 for ; Thu, 7 Oct 2004 09:14:50 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Thu, 07 Oct 2004 09:16:52 +0200 Message-ID: <4164ED59.9020200@pi.se> Date: Thu, 07 Oct 2004 09:16:41 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpls] Please comment on the "Issues/errors/clarifications in RFC3036" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Working group, Ina Minei are making very good progress in preparing the LDP spec for Draft Standards. We plan to have a draft published before the cuf-off date for the Washington meeting. In the mean time Ina has asked for comments on a marked up version of the LDP spec sent to the mailing list Sep 29 in a mail with "For your review - Issues/errors/clarifications in RFC3036" in the subject line. She also asked operators for their help on experiences with LDP deployment in a mail Sep 27 "Operators - please share your experience with LDP deployments". To support Ina in this task the working group chairs would like to encourage more commetns. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 05:29:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26944; Thu, 7 Oct 2004 05:29:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFUk5-0006KH-IF; Thu, 07 Oct 2004 05:39:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFUQc-0000gc-Hv; Thu, 07 Oct 2004 05:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFUOw-0000EW-9t for mpls@megatron.ietf.org; Thu, 07 Oct 2004 05:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26034 for ; Thu, 7 Oct 2004 05:17:27 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFUYY-0005na-Qx for mpls@ietf.org; Thu, 07 Oct 2004 05:27:30 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <4HNQP2GV>; Thu, 7 Oct 2004 10:16:51 +0100 Message-ID: <16E71652255A3E4796A7AF3A9E5068F90270B5@blakey.datcon.co.uk> From: Andy Baker To: "'manoj@juniper.net'" , "'yakov@juniper.net'" , "'rahul@redback.com'" Date: Thu, 7 Oct 2004 10:14:17 +0100 Deferred-Delivery: Thu, 7 Oct 2004 10:15:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "'mpls@ietf.org'" Subject: [mpls] Avoiding LDP graceful restart with planned node shutdown. X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, In the case where a node is to be permanently disabled in a network in an orderly manner (planned shutdown), but where normally it advertises to its LDP peers that it supports graceful restart procedures, it is desirable that peers do not use graceful restart procedures when they detect that the node has gone. This is to prevent the peers continuing to forward data to the stopped node on the assumption that the node's forwarding state is still intact. Such forwarded data will be black-holed until the peer neighbour reconnect timer expires. To prevent graceful restart usage under these circumstances requires that nodes can detect the difference between the planned and unplanned shutdown of a peer. While RFC3478 makes no specific comment on how to do so, a possible approach would be that when a node detects the failure of a peer through receipt of a Notification (shutdown), the receiving node assumes this is a planned shutdown of the peer, and disables graceful restart. In all other cases (TCP socket error, keepalive timeout etc.), the node assumes unplanned shutdown, and starts its graceful restart neighbour reconnect / liveness timer for the session. I'd like to get clarification if this is in fact the intent in the standard? Thanks, Andy. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 11:14:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25706; Thu, 7 Oct 2004 11:14:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFa8A-0003Hr-VL; Thu, 07 Oct 2004 11:24:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZl4-0003rK-GB; Thu, 07 Oct 2004 11:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZes-0002Lh-B3 for mpls@megatron.ietf.org; Thu, 07 Oct 2004 10:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23835 for ; Thu, 7 Oct 2004 10:54:15 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZob-0001tk-4H for mpls@ietf.org; Thu, 07 Oct 2004 11:04:21 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <4HNQPL35>; Thu, 7 Oct 2004 15:53:42 +0100 Message-ID: <16E71652255A3E4796A7AF3A9E5068F90304A9@blakey.datcon.co.uk> From: Nick Weeds To: "'Ina Minei'" Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Thu, 7 Oct 2004 15:53:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Ina, Just a couple of points on the update to RFC 3036... First, the list of issues not addressed says that RFC 3036 already says that loop detection should not be used in DU mode. I can't find this statement in RFC 3036. Which section is it in? Second, the LDP protocol can fail if a Label Mapping crosses with a Label Release. This was raised by Kishore Tiruveedhula [tiruveedhula@avici.com] on 25th August in connection with loop detection, but it is a more general problem with the protocol. The problem arises with the following sequence: (1) Router D sends a Label Mapping (2) Router U sends a Label Release (3) Independently router D sends an updated Label Mapping (same FEC and label, different details). If messages (2) and (3) cross in transit then the label mapping is programmed on U (on receipt of the updated Label Mapping) but released on D (on receipt of the Label Release). Any data sent using the label will be lost. The problem can occur whenever the downstream router sends a Label Mapping message to update an existing mapping. This is probably unusual in practice, but RFC 3036 allows it and indeed describes it for hop count changes when using independent control (see Kishore's email). From a quick check, the MTU signaling extension (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to require Label Mapping updates. I am not aware of other examples, but the problem is a potential trap for any LDP protocol extension. It is unclear how to proceed on this, as potential fixes are likely to require protocol changes. Perhaps it would be sufficient to explain the problem and suggest how to avoid it. (This problem was drawn to my attention in discussions of C-bit negotiation in draft-ietf-pwe3-control-protocol-xx.txt. This negotiation takes care to avoid Label Release messages in response to Label Withdraw "Wrong C-bit". The protocol problem in RFC 3036 was suggested as one reason for suppressing the Label Release, but there are probably other reasons too.) Nick. > -----Original Message----- > From: mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org]On > Behalf Of Ina Minei > Sent: 27 September 2004 19:31 > To: mpls@ietf.org > Subject: [mpls] For your review - Issues/errors/clarifications in > RFC3036 > > > > As part of the effort to move RFC3036 to draft standard, here is an > annotated version of RFC3036, with the changes enclosed by ###. > There is a separate section summarizing all changes towards > the end of the > document. > > Please review the changes and send comments to the list by October > 11th. > > At the end of this mail is a list of issues that were raised but > were not included in the annotated RFC (with an explanation of > why). > > Please review both the RFC changes and the list of issues not > included. Also let me know if I forgot to include any other issues > that were raised on the list. > > Many thanks to all who contributed, and in particular to Bob Thomas > for maintaining an extensive list of errors/issues over the years. > > > Thank you, > > Ina > > > Issues that were raised but not included in the annotated RFC > ============================================================= > > - Issue: discussion on the merits/drawbacks of independent-control and > ordered-control > - Issue: discussion on which FECs should be advertised > Reason why not included: The above two issues are either for the > applicability doc or for the "experiences with the protocol" document. > > - Issue: minor optimization: if A is a stub node, i.e., only one LDP > session, does it really have to send a label mapping for > every FEC that > it has, or can it do it lazily, e.g., when it has a second > LDP session? > Reason why not included : It is not clear what problem this change in > behavior brings, and what would be the added benefit,the issue must > be discussed on the list first. > > - Issue: the ldp loop detection mechanisms don't make sense in DU. > We should add something explicitly that > says that these TLVs should not be used in DU mode. ( This is the > current practice in all implementations that I know of ) > Why not included: RFC 3036 already states this in the section > describing these TLVs, when it talks about the usage of the TLVs. > > - Issue: the rfc should specifically say that a wildcard release > message should be sent only in response to a wildcard > withdraw message. > Reason not included: it is covered in the rules in the appendix. > > - There is a long list of issues that was added to the "for future > study" area of the RFC. The list is quite long, we could probably > remove some of the items. > Nick Weeds Software Developer Network Protocols Group Data Connection Ltd Tel: +44 1244 305200 Fax: +44 1244 312422 Email: Nick.Weeds@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 11:58:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29212; Thu, 7 Oct 2004 11:58:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaoo-0005gK-65; Thu, 07 Oct 2004 12:08:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaOH-0004Qk-C8; Thu, 07 Oct 2004 11:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaF0-00023S-C2 for mpls@megatron.ietf.org; Thu, 07 Oct 2004 11:31:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27121 for ; Thu, 7 Oct 2004 11:31:35 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaOj-0004AJ-Gl for mpls@ietf.org; Thu, 07 Oct 2004 11:41:41 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i97FV4Bm038651; Thu, 7 Oct 2004 08:31:05 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i97FV4e55637; Thu, 7 Oct 2004 08:31:04 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 7 Oct 2004 08:31:04 -0700 (PDT) From: Ina Minei To: Nick Weeds Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 In-Reply-To: <16E71652255A3E4796A7AF3A9E5068F90304A9@blakey.datcon.co.uk> Message-ID: <20041007082401.W86397@garnet.juniper.net> References: <16E71652255A3E4796A7AF3A9E5068F90304A9@blakey.datcon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Nick, I think I am missing something... The label release is sent by router B in response to a label withdraw it received from router A. A should wait for the release before attempting to send a label map again. In the meantime, the label is considered dead on A, and if A wants to resurrect it, A should wait until receiving the release. Are you suggesting that A can resurrect the label it just killed before waiting for the release to come? Thank you, Ina On Thu, 7 Oct 2004, Nick Weeds wrote: > Ina, > > Just a couple of points on the update to RFC 3036... > > First, the list of issues not addressed says that RFC 3036 already says that > loop detection should not be used in DU mode. I can't find this statement > in RFC 3036. Which section is it in? > > Second, the LDP protocol can fail if a Label Mapping crosses with a Label > Release. > This was raised by Kishore Tiruveedhula [tiruveedhula@avici.com] on 25th > August in connection with loop detection, but it is a more general problem > with the protocol. > > The problem arises with the following sequence: > (1) Router D sends a Label Mapping > (2) Router U sends a Label Release > (3) Independently router D sends an updated Label Mapping (same FEC and > label, different details). > > If messages (2) and (3) cross in transit then the label mapping is > programmed on U (on receipt of the updated Label Mapping) but released on D > (on receipt of the Label Release). Any data sent using the label will be > lost. > > The problem can occur whenever the downstream router sends a Label Mapping > message to update an existing mapping. This is probably unusual in > practice, but RFC 3036 allows it and indeed describes it for hop count > changes when using independent control (see Kishore's email). From a quick > check, the MTU signaling extension > (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to require Label > Mapping updates. I am not aware of other examples, but the problem is a > potential trap for any LDP protocol extension. > > It is unclear how to proceed on this, as potential fixes are likely to > require protocol changes. Perhaps it would be sufficient to explain the > problem and suggest how to avoid it. > > (This problem was drawn to my attention in discussions of C-bit negotiation > in draft-ietf-pwe3-control-protocol-xx.txt. This negotiation takes care to > avoid Label Release messages in response to Label Withdraw "Wrong C-bit". > The protocol problem in RFC 3036 was suggested as one reason for suppressing > the Label Release, but there are probably other reasons too.) > > Nick. > > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org > > [mailto:mpls-bounces@lists.ietf.org]On > > Behalf Of Ina Minei > > Sent: 27 September 2004 19:31 > > To: mpls@ietf.org > > Subject: [mpls] For your review - Issues/errors/clarifications in > > RFC3036 > > > > > > > > As part of the effort to move RFC3036 to draft standard, here is an > > annotated version of RFC3036, with the changes enclosed by ###. > > There is a separate section summarizing all changes towards > > the end of the > > document. > > > > Please review the changes and send comments to the list by October > > 11th. > > > > At the end of this mail is a list of issues that were raised but > > were not included in the annotated RFC (with an explanation of > > why). > > > > Please review both the RFC changes and the list of issues not > > included. Also let me know if I forgot to include any other issues > > that were raised on the list. > > > > Many thanks to all who contributed, and in particular to Bob Thomas > > for maintaining an extensive list of errors/issues over the years. > > > > > > Thank you, > > > > Ina > > > > > > Issues that were raised but not included in the annotated RFC > > ============================================================= > > > > - Issue: discussion on the merits/drawbacks of independent-control and > > ordered-control > > - Issue: discussion on which FECs should be advertised > > Reason why not included: The above two issues are either for the > > applicability doc or for the "experiences with the protocol" document. > > > > - Issue: minor optimization: if A is a stub node, i.e., only one LDP > > session, does it really have to send a label mapping for > > every FEC that > > it has, or can it do it lazily, e.g., when it has a second > > LDP session? > > Reason why not included : It is not clear what problem this change in > > behavior brings, and what would be the added benefit,the issue must > > be discussed on the list first. > > > > - Issue: the ldp loop detection mechanisms don't make sense in DU. > > We should add something explicitly that > > says that these TLVs should not be used in DU mode. ( This is the > > current practice in all implementations that I know of ) > > Why not included: RFC 3036 already states this in the section > > describing these TLVs, when it talks about the usage of the TLVs. > > > > - Issue: the rfc should specifically say that a wildcard release > > message should be sent only in response to a wildcard > > withdraw message. > > Reason not included: it is covered in the rules in the appendix. > > > > - There is a long list of issues that was added to the "for future > > study" area of the RFC. The list is quite long, we could probably > > remove some of the items. > > > > Nick Weeds > Software Developer > Network Protocols Group > Data Connection Ltd > Tel: +44 1244 305200 > Fax: +44 1244 312422 > Email: Nick.Weeds@dataconnection.com > Web: http://www.dataconnection.com > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 12:51:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03976; Thu, 7 Oct 2004 12:51:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbeE-0000jU-JW; Thu, 07 Oct 2004 13:01:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbQU-0006WL-F9; Thu, 07 Oct 2004 12:47:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbHk-0004vR-NV for mpls@megatron.ietf.org; Thu, 07 Oct 2004 12:38:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03219 for ; Thu, 7 Oct 2004 12:38:28 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbRR-0008MB-HU for mpls@ietf.org; Thu, 07 Oct 2004 12:48:36 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <4HNQPMSY>; Thu, 7 Oct 2004 17:37:56 +0100 Message-ID: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> From: Nick Weeds To: "'Ina Minei'" Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Thu, 7 Oct 2004 17:37:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Ina, Sorry I didn't explain this clearly. The problem arises in window cases where the upstream (U,B) and downstream (D,A) routers happen to send LDP messages at the same time. The likelihood of this is low, but it is possible. ! ! ! /---<----! Label Mapping ! / ! ! / ! ! / ! ! / ! ! / ! !<-------/ ! ! ! Label Release !---->---\ ! ! \ ! ! \ ! <-- ROUTE CHANGE ! \ ! ! \ /---<----! Label Mapping (update) ! X ! ! / \------->! ! / ! ! / ! ! / ! !<-------/ ! ! ! The Label Release is initiated by the upstream router. It is not a response to a Label Withdraw. For example, the upstream router might send the Label Release because it is using conservative retention. The downstream router sends the 2nd Label Mapping before receiving the Label Release. For example, a route change might cause the downstream router to signaling a change of hop count or a change of MTU. At the end of this sequence the downstream router has sent two Label Mappings and received a Label Release, so it considers the label to be released. The upstream router has sent a Label Release and received a subsequent Label Mapping, so it considers the label to be valid. In most cases the upstream router would send another Label Release, but if the route has changed then the upstream router might install the label for forwarding/switching use. If so then any data sent using the label will be dropped by the downstream router. This isn't a transient condition, it can continue indefinitely. As I said, the likelihood of this happening is low. I believe typical LDP usage would avoid this problem by avoiding loop detection, MTU signaling etc. Nevertheless, RFC 3036 allows such usage, describes hop count behaviour that can lead to the problem, and fails to mention or prevent the problem. Is that clearer? Nick. > -----Original Message----- > From: Ina Minei [mailto:ina@juniper.net] > Sent: 07 October 2004 16:31 > To: Nick Weeds > Cc: mpls@ietf.org (E-mail) > Subject: RE: [mpls] For your review - Issues/errors/clarifications in > RFC3 036 > > > > Nick, > > I think I am missing something... The label release is sent by > router B in response to a label withdraw it received from router A. > A should wait for the release before attempting to send a label map > again. In the meantime, the label is considered dead on A, and > if A wants to resurrect it, A should wait until receiving the release. > > Are you suggesting that A can resurrect the label it just killed > before waiting for the release to come? > > Thank you, > > Ina > > On Thu, 7 Oct 2004, Nick Weeds wrote: > > > Ina, > > > > Just a couple of points on the update to RFC 3036... > > > > First, the list of issues not addressed says that RFC 3036 > already says that > > loop detection should not be used in DU mode. I can't find > this statement > > in RFC 3036. Which section is it in? > > > > Second, the LDP protocol can fail if a Label Mapping > crosses with a Label > > Release. > > This was raised by Kishore Tiruveedhula > [tiruveedhula@avici.com] on 25th > > August in connection with loop detection, but it is a more > general problem > > with the protocol. > > > > The problem arises with the following sequence: > > (1) Router D sends a Label Mapping > > (2) Router U sends a Label Release > > (3) Independently router D sends an updated Label Mapping > (same FEC and > > label, different details). > > > > If messages (2) and (3) cross in transit then the label mapping is > > programmed on U (on receipt of the updated Label Mapping) > but released on D > > (on receipt of the Label Release). Any data sent using the > label will be > > lost. > > > > The problem can occur whenever the downstream router sends > a Label Mapping > > message to update an existing mapping. This is probably unusual in > > practice, but RFC 3036 allows it and indeed describes it > for hop count > > changes when using independent control (see Kishore's > email). From a quick > > check, the MTU signaling extension > > (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to > require Label > > Mapping updates. I am not aware of other examples, but the > problem is a > > potential trap for any LDP protocol extension. > > > > It is unclear how to proceed on this, as potential fixes > are likely to > > require protocol changes. Perhaps it would be sufficient > to explain the > > problem and suggest how to avoid it. > > > > (This problem was drawn to my attention in discussions of > C-bit negotiation > > in draft-ietf-pwe3-control-protocol-xx.txt. This > negotiation takes care to > > avoid Label Release messages in response to Label Withdraw > "Wrong C-bit". > > The protocol problem in RFC 3036 was suggested as one > reason for suppressing > > the Label Release, but there are probably other reasons too.) > > > > Nick. > > > > > -----Original Message----- > > > From: mpls-bounces@lists.ietf.org > > > [mailto:mpls-bounces@lists.ietf.org]On > > > Behalf Of Ina Minei > > > Sent: 27 September 2004 19:31 > > > To: mpls@ietf.org > > > Subject: [mpls] For your review - Issues/errors/clarifications in > > > RFC3036 > > > > > > > > > > > > As part of the effort to move RFC3036 to draft > standard, here is an > > > annotated version of RFC3036, with the changes enclosed by ###. > > > There is a separate section summarizing all changes towards > > > the end of the > > > document. > > > > > > Please review the changes and send comments to the > list by October > > > 11th. > > > > > > At the end of this mail is a list of issues that were > raised but > > > were not included in the annotated RFC (with an explanation of > > > why). > > > > > > Please review both the RFC changes and the list of issues not > > > included. Also let me know if I forgot to include any other issues > > > that were raised on the list. > > > > > > Many thanks to all who contributed, and in particular > to Bob Thomas > > > for maintaining an extensive list of errors/issues over the years. > > > > > > > > > Thank you, > > > > > > Ina > > > > > > > > > Issues that were raised but not included in the annotated RFC > > > ============================================================= > > > > > > - Issue: discussion on the merits/drawbacks of > independent-control and > > > ordered-control > > > - Issue: discussion on which FECs should be advertised > > > Reason why not included: The above two issues are either for the > > > applicability doc or for the "experiences with the > protocol" document. > > > > > > - Issue: minor optimization: if A is a stub node, i.e., > only one LDP > > > session, does it really have to send a label mapping for > > > every FEC that > > > it has, or can it do it lazily, e.g., when it has a second > > > LDP session? > > > Reason why not included : It is not clear what problem > this change in > > > behavior brings, and what would be the added benefit,the > issue must > > > be discussed on the list first. > > > > > > - Issue: the ldp loop detection mechanisms don't make sense in DU. > > > We should add something explicitly that > > > says that these TLVs should not be used in DU mode. ( This is the > > > current practice in all implementations that I know of ) > > > Why not included: RFC 3036 already states this in the section > > > describing these TLVs, when it talks about the usage of the TLVs. > > > > > > - Issue: the rfc should specifically say that a wildcard release > > > message should be sent only in response to a wildcard > > > withdraw message. > > > Reason not included: it is covered in the rules in the appendix. > > > > > > - There is a long list of issues that was added to the "for future > > > study" area of the RFC. The list is quite long, we could probably > > > remove some of the items. > > > > > > > Nick Weeds > Software Developer > Network Protocols Group > Data Connection Ltd > Tel: +44 1244 305200 > Fax: +44 1244 312422 > Email: Nick.Weeds@dataconnection.com > Web: http://www.dataconnection.com > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From Isocore_events-bounces@isocore.com Thu Oct 7 14:25:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09019; Thu, 7 Oct 2004 14:21:28 -0400 (EDT) Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcPH-0003tu-PY; Thu, 07 Oct 2004 13:50:25 -0400 Received: from localhost ([127.0.0.1] helo=ns1.cpanel.btnaccess.com) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.42) id 1CFbwJ-0005mK-5e; Thu, 07 Oct 2004 13:20:27 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.42) id 1CFbwA-0005lp-F6 for isocore_events@isocore.com; Thu, 07 Oct 2004 13:20:18 -0400 Received: from 68.100.11.8 ([68.100.11.8]) by isocore.com (IMP) with HTTP for ; Thu, 7 Oct 2004 13:20:18 -0400 Message-ID: <1097169618.41657ad268fc5@isocore.com> Date: Thu, 7 Oct 2004 13:20:18 -0400 From: kkhanna@isocore.com To: isocore_events@isocore.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 68.100.11.8 Subject: [Isocore_events] MPLS 2004: October 17-19, 2004 X-BeenThere: Isocore_events@isocore.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: list-admin@isocore.com List-Id: isocore_events_isocore.com.isocore.com List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Isocore_events-bounces@isocore.com Errors-To: Isocore_events-bounces@isocore.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit Greetings, We wanted to remind you that there are only a few days left for MPLS 2004 () - the premier conference on MPLS & related technologies. This 7th Annual International Conference is scheduled to be held from October 17 to 19, 2004 at the Omni Shoreham Hotel in Washington D.C. Conference registration would gain you access to all the keynotes, tutorials, technical sessions, exhibit hall, and reception banquet. Conference highlights include: - Opening Speech, "Public Policy Considerations Regarding IP-Enabled Services" by FCC Commissioner K. Abernathy - Keynote Speech, "NTT's Vision for the Future Network" by T. Okada, VP, Executive Director of NTT Network Service Systems Laboratories - Two Discussion Panels: * Service Providers Panel: Inter-Carrier MPLS Issues * Vendors Panel: Vendors' Perspective on MPLS - Tutorial Sessions by Industry Leading Experts - On-site Live Demonstration of Inter-AS Layer 2 VPN Deployment - 5th Public Interoperability Demonstration (Wednesday, October 20) at Isocore Internetworking Lab - Exhibits by over 30 vendors and service providers in the industry For details on the program, please visit . Visit to register NOW! Thank you. Regards, Kavita _______________________________________________ Isocore_events mailing list http://www.isocore.com To unsubscribe, send email to list-admin@isocore.com From mpls-bounces@ietf.org Thu Oct 7 15:14:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13265; Thu, 7 Oct 2004 15:14:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdsY-0003Vh-OE; Thu, 07 Oct 2004 15:24:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdXw-0006dr-OU; Thu, 07 Oct 2004 15:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdU9-0001to-Nd for mpls@megatron.ietf.org; Thu, 07 Oct 2004 14:59:29 -0400 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11432 for ; Thu, 7 Oct 2004 14:59:27 -0400 (EDT) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CFdFn-0006Zp-6e; Thu, 07 Oct 2004 14:44:39 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 07 Oct 2004 14:44:39 -0400 Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The IESG has approved the following document: - 'Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary In various applications of MPLS, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. Working Group Summary The draft has gone through a discussion within the WG and the WG LC. There was a WG consensus on this document. Protocol Quality The document has been review for the IESG by Alex Zinin and Routing Area Directorate. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 15:39:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16232; Thu, 7 Oct 2004 15:39:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFeGN-00057m-Qy; Thu, 07 Oct 2004 15:49:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFe0f-0007O1-JC; Thu, 07 Oct 2004 15:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdrs-0002vH-6l for mpls@megatron.ietf.org; Thu, 07 Oct 2004 15:24:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14883 for ; Thu, 7 Oct 2004 15:23:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFe1b-0003zb-5X for mpls@ietf.org; Thu, 07 Oct 2004 15:34:05 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i97JNMr2009287; Thu, 7 Oct 2004 15:23:22 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29213; Thu, 7 Oct 2004 15:23:21 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Oct 2004 15:23:21 -0400 Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F800013045@usvissfp01.win.marconi.com> From: "Naidu, Venkata" To: "'Nick Weeds'" , "'Ina Minei'" Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Thu, 7 Oct 2004 15:23:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Nick, Yes, I recollect that this problem is already discussed long time back (Jan'02). And there is no concrete solution proposed for this problem, yet. http://www.cell-relay.com/mhonarc/mpls/2002-Jan/msg00117.html Venkata. -> -----Original Message----- -> From: mpls-bounces@lists.ietf.org -> [mailto:mpls-bounces@lists.ietf.org]On -> Behalf Of Nick Weeds -> Sent: Thursday, October 07, 2004 12:38 PM -> To: 'Ina Minei' -> Cc: mpls@ietf.org (E-mail) -> Subject: RE: [mpls] For your review - Issues/errors/clarifications in -> RFC3 036 -> -> -> Ina, -> -> Sorry I didn't explain this clearly. -> -> The problem arises in window cases where the upstream (U,B) -> and downstream -> (D,A) routers happen to -> send LDP messages at the same time. The likelihood of this -> is low, but it -> is possible. -> -> ! ! -> ! /---<----! Label Mapping -> ! / ! -> ! / ! -> ! / ! -> ! / ! -> ! / ! -> !<-------/ ! -> ! ! -> Label Release !---->---\ ! -> ! \ ! -> ! \ ! <-- ROUTE CHANGE -> ! \ ! -> ! \ /---<----! Label Mapping (update) -> ! X ! -> ! / \------->! -> ! / ! -> ! / ! -> ! / ! -> !<-------/ ! -> ! ! -> -> -> The Label Release is initiated by the upstream router. It -> is not a response -> to a Label Withdraw. For example, the upstream router might -> send the Label -> Release because it is using conservative retention. -> -> The downstream router sends the 2nd Label Mapping before -> receiving the Label -> Release. For example, a route change might cause the -> downstream router to -> signaling a change of hop count or a change of MTU. -> -> At the end of this sequence the downstream router has sent two Label -> Mappings and received a Label Release, so it considers the -> label to be -> released. The upstream router has sent a Label Release and -> received a -> subsequent Label Mapping, so it considers the label to be -> valid. In most -> cases the upstream router would send another Label Release, -> but if the route -> has changed then the upstream router might install the label for -> forwarding/switching use. If so then any data sent using -> the label will be -> dropped by the downstream router. This isn't a transient -> condition, it can -> continue indefinitely. -> -> As I said, the likelihood of this happening is low. I -> believe typical LDP -> usage would avoid this problem by avoiding loop detection, -> MTU signaling -> etc. Nevertheless, RFC 3036 allows such usage, describes hop count -> behaviour that can lead to the problem, and fails to mention -> or prevent the -> problem. -> -> Is that clearer? -> -> Nick. -> -> > -----Original Message----- -> > From: Ina Minei [mailto:ina@juniper.net] -> > Sent: 07 October 2004 16:31 -> > To: Nick Weeds -> > Cc: mpls@ietf.org (E-mail) -> > Subject: RE: [mpls] For your review - -> Issues/errors/clarifications in -> > RFC3 036 -> > -> > -> > -> > Nick, -> > -> > I think I am missing something... The label release is sent by -> > router B in response to a label withdraw it received from router A. -> > A should wait for the release before attempting to send a -> label map -> > again. In the meantime, the label is considered dead on A, and -> > if A wants to resurrect it, A should wait until receiving -> the release. -> > -> > Are you suggesting that A can resurrect the label it just killed -> > before waiting for the release to come? -> > -> > Thank you, -> > -> > Ina -> > -> > On Thu, 7 Oct 2004, Nick Weeds wrote: -> > -> > > Ina, -> > > -> > > Just a couple of points on the update to RFC 3036... -> > > -> > > First, the list of issues not addressed says that RFC 3036 -> > already says that -> > > loop detection should not be used in DU mode. I can't find -> > this statement -> > > in RFC 3036. Which section is it in? -> > > -> > > Second, the LDP protocol can fail if a Label Mapping -> > crosses with a Label -> > > Release. -> > > This was raised by Kishore Tiruveedhula -> > [tiruveedhula@avici.com] on 25th -> > > August in connection with loop detection, but it is a more -> > general problem -> > > with the protocol. -> > > -> > > The problem arises with the following sequence: -> > > (1) Router D sends a Label Mapping -> > > (2) Router U sends a Label Release -> > > (3) Independently router D sends an updated Label Mapping -> > (same FEC and -> > > label, different details). -> > > -> > > If messages (2) and (3) cross in transit then the label -> mapping is -> > > programmed on U (on receipt of the updated Label Mapping) -> > but released on D -> > > (on receipt of the Label Release). Any data sent using the -> > label will be -> > > lost. -> > > -> > > The problem can occur whenever the downstream router sends -> > a Label Mapping -> > > message to update an existing mapping. This is probably -> unusual in -> > > practice, but RFC 3036 allows it and indeed describes it -> > for hop count -> > > changes when using independent control (see Kishore's -> > email). From a quick -> > > check, the MTU signaling extension -> > > (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to -> > require Label -> > > Mapping updates. I am not aware of other examples, but the -> > problem is a -> > > potential trap for any LDP protocol extension. -> > > -> > > It is unclear how to proceed on this, as potential fixes -> > are likely to -> > > require protocol changes. Perhaps it would be sufficient -> > to explain the -> > > problem and suggest how to avoid it. -> > > -> > > (This problem was drawn to my attention in discussions of -> > C-bit negotiation -> > > in draft-ietf-pwe3-control-protocol-xx.txt. This -> > negotiation takes care to -> > > avoid Label Release messages in response to Label Withdraw -> > "Wrong C-bit". -> > > The protocol problem in RFC 3036 was suggested as one -> > reason for suppressing -> > > the Label Release, but there are probably other reasons too.) -> > > -> > > Nick. -> > > -> > > > -----Original Message----- -> > > > From: mpls-bounces@lists.ietf.org -> > > > [mailto:mpls-bounces@lists.ietf.org]On -> > > > Behalf Of Ina Minei -> > > > Sent: 27 September 2004 19:31 -> > > > To: mpls@ietf.org -> > > > Subject: [mpls] For your review - -> Issues/errors/clarifications in -> > > > RFC3036 -> > > > -> > > > -> > > > -> > > > As part of the effort to move RFC3036 to draft -> > standard, here is an -> > > > annotated version of RFC3036, with the changes enclosed by ###. -> > > > There is a separate section summarizing all changes towards -> > > > the end of the -> > > > document. -> > > > -> > > > Please review the changes and send comments to the -> > list by October -> > > > 11th. -> > > > -> > > > At the end of this mail is a list of issues that were -> > raised but -> > > > were not included in the annotated RFC (with an explanation of -> > > > why). -> > > > -> > > > Please review both the RFC changes and the list of -> issues not -> > > > included. Also let me know if I forgot to include any -> other issues -> > > > that were raised on the list. -> > > > -> > > > Many thanks to all who contributed, and in particular -> > to Bob Thomas -> > > > for maintaining an extensive list of errors/issues -> over the years. -> > > > -> > > > -> > > > Thank you, -> > > > -> > > > Ina -> > > > -> > > > -> > > > Issues that were raised but not included in the annotated RFC -> > > > ============================================================= -> > > > -> > > > - Issue: discussion on the merits/drawbacks of -> > independent-control and -> > > > ordered-control -> > > > - Issue: discussion on which FECs should be advertised -> > > > Reason why not included: The above two issues are -> either for the -> > > > applicability doc or for the "experiences with the -> > protocol" document. -> > > > -> > > > - Issue: minor optimization: if A is a stub node, i.e., -> > only one LDP -> > > > session, does it really have to send a label mapping for -> > > > every FEC that -> > > > it has, or can it do it lazily, e.g., when it has a second -> > > > LDP session? -> > > > Reason why not included : It is not clear what problem -> > this change in -> > > > behavior brings, and what would be the added benefit,the -> > issue must -> > > > be discussed on the list first. -> > > > -> > > > - Issue: the ldp loop detection mechanisms don't make -> sense in DU. -> > > > We should add something explicitly that -> > > > says that these TLVs should not be used in DU mode. ( -> This is the -> > > > current practice in all implementations that I know of ) -> > > > Why not included: RFC 3036 already states this in the section -> > > > describing these TLVs, when it talks about the usage -> of the TLVs. -> > > > -> > > > - Issue: the rfc should specifically say that a -> wildcard release -> > > > message should be sent only in response to a wildcard -> > > > withdraw message. -> > > > Reason not included: it is covered in the rules in the -> appendix. -> > > > -> > > > - There is a long list of issues that was added to the -> "for future -> > > > study" area of the RFC. The list is quite long, we -> could probably -> > > > remove some of the items. -> > > > -> > > -> > -> > Nick Weeds -> > Software Developer -> > Network Protocols Group -> > Data Connection Ltd -> > Tel: +44 1244 305200 -> > Fax: +44 1244 312422 -> > Email: Nick.Weeds@dataconnection.com -> > Web: http://www.dataconnection.com -> > -> -> _______________________________________________ -> mpls mailing list -> mpls@lists.ietf.org -> https://www1.ietf.org/mailman/listinfo/mpls -> _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 17:06:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27389; Thu, 7 Oct 2004 17:06:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFfdC-0004SH-Jq; Thu, 07 Oct 2004 17:16:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFfLy-0005Lc-Gb; Thu, 07 Oct 2004 16:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFeW9-00060B-TE for mpls@megatron.ietf.org; Thu, 07 Oct 2004 16:05:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18435 for ; Thu, 7 Oct 2004 16:05:35 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFefr-00071d-Dm for mpls@ietf.org; Thu, 07 Oct 2004 16:15:43 -0400 Received: from tiruveedhulapc (tiruveedhula-pc.avici.com [10.2.20.229]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id i97K4oYn004649; Thu, 7 Oct 2004 16:04:50 -0400 From: "Kishore Tiruveedhula" To: "'Nick Weeds'" , "'Ina Minei'" Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Thu, 7 Oct 2004 16:05:03 -0400 Message-ID: <003001c4aca8$efc9a7b0$e514020a@avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tiruveedhula@avici.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: 7bit Yes. This problem happens if the the downstream router re-sends Label Mapping to upstream router to update the parameters like hop count or path vectors and if the receiving label release message is on the wire. There is no one-to-one mapping between Label Mapping and Label Release messages. And one more issue: ****************** Note 1 of A.1.4 says, When the label Release Message is received from upstream peer, the router shouldn't send Label Mapping until the upstream router requests it. Is it make sense for not sending the Mapping until the MsgSource requests it ?? ************************************************** A.1.4. Receive Label Release Notes: 1. If LSR is using Downstream Unsolicited label distribution, it should not re-advertise a label mapping for FEC to MsgSource until MsgSource requests it. ***************************************************** Thanks, Kishore -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]On Behalf Of Nick Weeds Sent: Thursday, October 07, 2004 12:38 PM To: 'Ina Minei' Cc: mpls@ietf.org (E-mail) Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Ina, Sorry I didn't explain this clearly. The problem arises in window cases where the upstream (U,B) and downstream (D,A) routers happen to send LDP messages at the same time. The likelihood of this is low, but it is possible. ! ! ! /---<----! Label Mapping ! / ! ! / ! ! / ! ! / ! ! / ! !<-------/ ! ! ! Label Release !---->---\ ! ! \ ! ! \ ! <-- ROUTE CHANGE ! \ ! ! \ /---<----! Label Mapping (update) ! X ! ! / \------->! ! / ! ! / ! ! / ! !<-------/ ! ! ! The Label Release is initiated by the upstream router. It is not a response to a Label Withdraw. For example, the upstream router might send the Label Release because it is using conservative retention. The downstream router sends the 2nd Label Mapping before receiving the Label Release. For example, a route change might cause the downstream router to signaling a change of hop count or a change of MTU. At the end of this sequence the downstream router has sent two Label Mappings and received a Label Release, so it considers the label to be released. The upstream router has sent a Label Release and received a subsequent Label Mapping, so it considers the label to be valid. In most cases the upstream router would send another Label Release, but if the route has changed then the upstream router might install the label for forwarding/switching use. If so then any data sent using the label will be dropped by the downstream router. This isn't a transient condition, it can continue indefinitely. As I said, the likelihood of this happening is low. I believe typical LDP usage would avoid this problem by avoiding loop detection, MTU signaling etc. Nevertheless, RFC 3036 allows such usage, describes hop count behaviour that can lead to the problem, and fails to mention or prevent the problem. Is that clearer? Nick. > -----Original Message----- > From: Ina Minei [mailto:ina@juniper.net] > Sent: 07 October 2004 16:31 > To: Nick Weeds > Cc: mpls@ietf.org (E-mail) > Subject: RE: [mpls] For your review - Issues/errors/clarifications in > RFC3 036 > > > > Nick, > > I think I am missing something... The label release is sent by > router B in response to a label withdraw it received from router A. > A should wait for the release before attempting to send a label map > again. In the meantime, the label is considered dead on A, and > if A wants to resurrect it, A should wait until receiving the release. > > Are you suggesting that A can resurrect the label it just killed > before waiting for the release to come? > > Thank you, > > Ina > > On Thu, 7 Oct 2004, Nick Weeds wrote: > > > Ina, > > > > Just a couple of points on the update to RFC 3036... > > > > First, the list of issues not addressed says that RFC 3036 > already says that > > loop detection should not be used in DU mode. I can't find > this statement > > in RFC 3036. Which section is it in? > > > > Second, the LDP protocol can fail if a Label Mapping > crosses with a Label > > Release. > > This was raised by Kishore Tiruveedhula > [tiruveedhula@avici.com] on 25th > > August in connection with loop detection, but it is a more > general problem > > with the protocol. > > > > The problem arises with the following sequence: > > (1) Router D sends a Label Mapping > > (2) Router U sends a Label Release > > (3) Independently router D sends an updated Label Mapping > (same FEC and > > label, different details). > > > > If messages (2) and (3) cross in transit then the label mapping is > > programmed on U (on receipt of the updated Label Mapping) > but released on D > > (on receipt of the Label Release). Any data sent using the > label will be > > lost. > > > > The problem can occur whenever the downstream router sends > a Label Mapping > > message to update an existing mapping. This is probably unusual in > > practice, but RFC 3036 allows it and indeed describes it > for hop count > > changes when using independent control (see Kishore's > email). From a quick > > check, the MTU signaling extension > > (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to > require Label > > Mapping updates. I am not aware of other examples, but the > problem is a > > potential trap for any LDP protocol extension. > > > > It is unclear how to proceed on this, as potential fixes > are likely to > > require protocol changes. Perhaps it would be sufficient > to explain the > > problem and suggest how to avoid it. > > > > (This problem was drawn to my attention in discussions of > C-bit negotiation > > in draft-ietf-pwe3-control-protocol-xx.txt. This > negotiation takes care to > > avoid Label Release messages in response to Label Withdraw > "Wrong C-bit". > > The protocol problem in RFC 3036 was suggested as one > reason for suppressing > > the Label Release, but there are probably other reasons too.) > > > > Nick. > > > > > -----Original Message----- > > > From: mpls-bounces@lists.ietf.org > > > [mailto:mpls-bounces@lists.ietf.org]On > > > Behalf Of Ina Minei > > > Sent: 27 September 2004 19:31 > > > To: mpls@ietf.org > > > Subject: [mpls] For your review - Issues/errors/clarifications in > > > RFC3036 > > > > > > > > > > > > As part of the effort to move RFC3036 to draft > standard, here is an > > > annotated version of RFC3036, with the changes enclosed by ###. > > > There is a separate section summarizing all changes towards > > > the end of the > > > document. > > > > > > Please review the changes and send comments to the > list by October > > > 11th. > > > > > > At the end of this mail is a list of issues that were > raised but > > > were not included in the annotated RFC (with an explanation of > > > why). > > > > > > Please review both the RFC changes and the list of issues not > > > included. Also let me know if I forgot to include any other issues > > > that were raised on the list. > > > > > > Many thanks to all who contributed, and in particular > to Bob Thomas > > > for maintaining an extensive list of errors/issues over the years. > > > > > > > > > Thank you, > > > > > > Ina > > > > > > > > > Issues that were raised but not included in the annotated RFC > > > ============================================================= > > > > > > - Issue: discussion on the merits/drawbacks of > independent-control and > > > ordered-control > > > - Issue: discussion on which FECs should be advertised > > > Reason why not included: The above two issues are either for the > > > applicability doc or for the "experiences with the > protocol" document. > > > > > > - Issue: minor optimization: if A is a stub node, i.e., > only one LDP > > > session, does it really have to send a label mapping for > > > every FEC that > > > it has, or can it do it lazily, e.g., when it has a second > > > LDP session? > > > Reason why not included : It is not clear what problem > this change in > > > behavior brings, and what would be the added benefit,the > issue must > > > be discussed on the list first. > > > > > > - Issue: the ldp loop detection mechanisms don't make sense in DU. > > > We should add something explicitly that > > > says that these TLVs should not be used in DU mode. ( This is the > > > current practice in all implementations that I know of ) > > > Why not included: RFC 3036 already states this in the section > > > describing these TLVs, when it talks about the usage of the TLVs. > > > > > > - Issue: the rfc should specifically say that a wildcard release > > > message should be sent only in response to a wildcard > > > withdraw message. > > > Reason not included: it is covered in the rules in the appendix. > > > > > > - There is a long list of issues that was added to the "for future > > > study" area of the RFC. The list is quite long, we could probably > > > remove some of the items. > > > > > > > Nick Weeds > Software Developer > Network Protocols Group > Data Connection Ltd > Tel: +44 1244 305200 > Fax: +44 1244 312422 > Email: Nick.Weeds@dataconnection.com > Web: http://www.dataconnection.com > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 18:56:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06979; Thu, 7 Oct 2004 18:56:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhKr-0002d6-Pk; Thu, 07 Oct 2004 19:06:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFh4N-0000JH-Kk; Thu, 07 Oct 2004 18:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFh0G-0008FN-Uu for mpls@megatron.ietf.org; Thu, 07 Oct 2004 18:44:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06578 for ; Thu, 7 Oct 2004 18:44:49 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhA3-00024V-Kv for mpls@ietf.org; Thu, 07 Oct 2004 18:55:00 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 00:27:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Date: Fri, 8 Oct 2004 00:26:57 +0200 Message-ID: Thread-Topic: [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Thread-Index: AcSsC0Upqd88AHo3RK2erZmFJZycOQArB3jA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Satyanarayana Dillikar" , , X-OriginalArrivalTime: 07 Oct 2004 22:27:01.0803 (UTC) FILETIME=[C4286FB0:01C4ACBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ops.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Hi Dillikar, Sorry for this delayed answer. Thanks for these useful comments, that will help clarifying this spec. Please see inline. Regards, JL PS: I'm copying ccamp >-----Message d'origine----- >De : mpls-bounces@lists.ietf.org=20 >[mailto:mpls-bounces@lists.ietf.org] De la part de=20 >Satyanarayana Dillikar >Envoy=E9 : mercredi 6 octobre 2004 10:38 >=C0 : mpls@ietf.org; mpls-ops@mplsrc.com >Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20 >clarificationneeded. > > >Hi, > We have some confusion in understanding the Data >Plane Capability Flags (B-bit & E-bit) from=20 >draft-vasseur-ccamp-te-router-info-00.txt > >(a) Does E-bit ON implies B-bit ON always ? (assuming >ON =3D set and OFF =3D unset). Basically bud (transit + Egress) capability requires some branching in = the data plane so in general E ON will imply B ON, but note that these capabilities does not necessarily reflect real = hardware capabilities as they may be activated/deactivated by the operator for various reasons. We will clarify this point in next revision. >(b) E-bit =3D ON & B-bit =3D OFF, is it a valid >combination. Yes see above, there may be cases where the operator want to deactivate = branch capability on a node (He does't want that the node act as a = branch LSR), even if its data plane is physically branch capable, but he = allows the node to act as a bud-LSR (transit + egress). This gives more operational flexibility. >(c) Please tell us the E-bit and B-bit status for a >node which is a destination node but does not have >branch capability. If its data plane is not branch capable then it will also probably not = be bud capable so=20 E =3D 0 and B =3D 0 In return, if its data plane is branch capable but branch LSR capability = has been deactivated by configuration and bud-LSR capability is = activated, then E =3D 1 and B =3D 0 > > >We are also curious to know >(1)The idea behind combing two things (egress status & >transit status) in a single E-bit. rather than making >use of B-bit(branch) and having E-bit just for egress >status. Remind that these capabilities are used for tree computation purpose, = and the egress is an entry=20 of the computation. So, IMHO it does't really make any sense to = advertise egress capability only.=20 >(2) Why the TE Node Capability Descriptor TLV should >have E-bit & how it should be used in CSPF path >computation. This allows advertising if an LSR can be transit and egress.=20 This is particulary useful for steiner tree topologies.=20 See the following example:=20 Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4 R1 | R2--R3---R4 Such tree can be setup only if R3 has Egress + Transit capability. Regards, JL > >Thanks >Satya=20 > > > =09 >_______________________________ >Do you Yahoo!? >Declare Yourself - Register online to vote today! http://vote.yahoo.com > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 19:01:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07546; Thu, 7 Oct 2004 19:01:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhQ0-0002zG-ME; Thu, 07 Oct 2004 19:11:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFh9f-00010f-7P; Thu, 07 Oct 2004 18:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaN1-00042K-RL for mpls@megatron.ietf.org; Thu, 07 Oct 2004 11:39:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27737; Thu, 7 Oct 2004 11:39:50 -0400 (EDT) Received: from tornado.amsl.com ([64.170.98.5] helo=puddle.amsl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaWX-0004Uo-VC; Thu, 07 Oct 2004 11:49:56 -0400 Received: from AlexaDellLat600 ([195.56.72.35]) (authenticated bits=0) by puddle.amsl.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i97FhVOE013263; Thu, 7 Oct 2004 08:43:38 -0700 Message-Id: <200410071543.i97FhVOE013263@puddle.amsl.com> From: "Alexa Morris" To: , , "'o George Swallow'" , "'o Loa Anderssom'" , "'o Ina Minei'" Date: Thu, 7 Oct 2004 08:38:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcSsg6EJeqoHCizzSgG+qMTfh5rFog== X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Oct 2004 18:54:32 -0400 Cc: rcheruku@cisco.com Subject: [mpls] Liaison from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit This email is being sent on behalf of Rao Cherukuri, rcheruku@cisco.com. Dear George, Loa and Ina: A recent message on the MPLS WG mailing list (http://www.cell-relay.com/mhonarc/mpls/2004-Sep/msg00043.html) has suggested changes to RFC 3036 ("LDP Specification") and called for comments on the proposed changes. One of the proposed changes is to deprecate the use of the Host Address FEC TLV. Two Implementation Agreements published by the MPLS & Frame Relay Alliance (MFA), "MPLS Proxy Admission Control Definition" and "MPLS Proxy Admission Control Protocol", MFA.6.0.0 and MFA.7.0.0 (http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pd f and http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf) make use of the Host Address FEC TLV. MPLS Proxy Admission Control provides a bandwidth-based reservation/admission facility for MPLS networks. There are implementations of this protocol in progress. While the proposed changes make a Prefix FEC TLV with a 32-bit mask equivalent to a Host Address FEC TLV, adopting the Prefix FEC TLV would require changes to approved and published MFA documents, and changes to the implementations. Also, since MPLS Proxy Admission Control only uses host addresses, using the Prefix FEC TLV would necessitate an additional check that the prefix was always 32 bits. Therefore, the MFA kindly requests that the Host Address FEC TLV not be deprecated, and that it continues to be supported in future revisions of LDP. In RFC 3036, there is a semantic difference between a Host Address and a prefix with length 32. The new version proposes to remove the semantic difference. This is not a problem for the MPLS Proxy Admission Control; we are just requesting that the Host Address codepoint not be deprecated. Please advise us as soon as possible about the decision on this issue. Cordially, Rao Cherukuri MPLS & Frame Relay Alliance Technical Committee Chair _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 19:35:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10733; Thu, 7 Oct 2004 19:35:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhwl-0005El-Bz; Thu, 07 Oct 2004 19:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFhgt-0008CO-I3; Thu, 07 Oct 2004 19:28:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFhbG-0007JM-KK for mpls@megatron.ietf.org; Thu, 07 Oct 2004 19:23:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09620 for ; Thu, 7 Oct 2004 19:23:03 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhl3-0004PR-QC for mpls@ietf.org; Thu, 07 Oct 2004 19:33:14 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.7.) id v.5.e9d2fad (22681); Thu, 7 Oct 2004 19:22:25 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in04.mx.aol.com (v101_r1.4) with ESMTP id MAILININ42-58994165cfb0d4; Thu, 07 Oct 2004 19:22:25 -0400 Message-ID: <4165CFAA.2050300@netscape.net> Date: Thu, 07 Oct 2004 19:22:18 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Nick Weeds Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <16E71652255A3E4796A7AF3A9E5068F90304A9@blakey.datcon.co.uk> In-Reply-To: <16E71652255A3E4796A7AF3A9E5068F90304A9@blakey.datcon.co.uk> X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.5 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0625431549==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f --===============0625431549== Content-Type: multipart/alternative; boundary="------------030805050905090609050000" --------------030805050905090609050000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nick, See in line. Nick Weeds wrote: >Ina, > >Just a couple of points on the update to RFC 3036... > >First, the list of issues not addressed says that RFC 3036 already says that >loop detection should not be used in DU mode. I can't find this statement >in RFC 3036. Which section is it in? > > I'm pretty sure discussed this on the list, and determined that it is more appropriate to address when a feature should or should not be used in an applicability document - such as RFC 3037. I don't know that there is universal agreement that loop detection is not used in the DU mode, nor is it relevant from a specification perspective whether or not it "should" be used - as long as there is agreement that it either is or is not required to be supported. >Second, the LDP protocol can fail if a Label Mapping crosses with a Label >Release. >This was raised by Kishore Tiruveedhula [tiruveedhula@avici.com] on 25th >August in connection with loop detection, but it is a more general problem >with the protocol. > >The problem arises with the following sequence: >(1) Router D sends a Label Mapping >(2) Router U sends a Label Release >(3) Independently router D sends an updated Label Mapping (same FEC and >label, different details). > >If messages (2) and (3) cross in transit then the label mapping is >programmed on U (on receipt of the updated Label Mapping) but released on D >(on receipt of the Label Release). Any data sent using the label will be >lost. > >The problem can occur whenever the downstream router sends a Label Mapping >message to update an existing mapping. This is probably unusual in >practice, but RFC 3036 allows it and indeed describes it for hop count >changes when using independent control (see Kishore's email). From a quick >check, the MTU signaling extension >(draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to require Label >Mapping updates. I am not aware of other examples, but the problem is a >potential trap for any LDP protocol extension. > > > This is not a problem with any reasonably robust implementation. A "reasonably robust" implementation does something intelligent with the knowledge that it is getting packets with labels it does not know how to handle. Something obvious, like sending a (possibly redundant) label release to the router from which it receives them. This is not as simple, if the labels it is getting are the result of PHP. But even this can be dealt with. >It is unclear how to proceed on this, as potential fixes are likely to >require protocol changes. Perhaps it would be sufficient to explain the >problem and suggest how to avoid it. > > There is no "potential fix", and this has been discussed before. It is not the task of the author(s) of an RFC to tell their competitors how to build an implementation that works. No number of messages - where each message is intended to be an acknowledgement of the one it is response to - can ever ensure that two parties to an exchange are in possession of exactly the same awareness of the state of a particular exchange token. This is known variously as the "two generals" or "common knowledge" problem. >(This problem was drawn to my attention in discussions of C-bit negotiation >in draft-ietf-pwe3-control-protocol-xx.txt. This negotiation takes care to >avoid Label Release messages in response to Label Withdraw "Wrong C-bit". >The protocol problem in RFC 3036 was suggested as one reason for suppressing >the Label Release, but there are probably other reasons too.) > > Nick. > > > >>-----Original Message----- >>From: mpls-bounces@lists.ietf.org >>[mailto:mpls-bounces@lists.ietf.org]On >>Behalf Of Ina Minei >>Sent: 27 September 2004 19:31 >>To: mpls@ietf.org >>Subject: [mpls] For your review - Issues/errors/clarifications in >>RFC3036 >> >> >> >> As part of the effort to move RFC3036 to draft standard, here is an >>annotated version of RFC3036, with the changes enclosed by ###. >>There is a separate section summarizing all changes towards >>the end of the >>document. >> >> Please review the changes and send comments to the list by October >>11th. >> >> At the end of this mail is a list of issues that were raised but >>were not included in the annotated RFC (with an explanation of >>why). >> >> Please review both the RFC changes and the list of issues not >>included. Also let me know if I forgot to include any other issues >>that were raised on the list. >> >> Many thanks to all who contributed, and in particular to Bob Thomas >>for maintaining an extensive list of errors/issues over the years. >> >> >> Thank you, >> >> Ina >> >> >>Issues that were raised but not included in the annotated RFC >>============================================================= >> >>- Issue: discussion on the merits/drawbacks of independent-control and >>ordered-control >>- Issue: discussion on which FECs should be advertised >>Reason why not included: The above two issues are either for the >>applicability doc or for the "experiences with the protocol" document. >> >>- Issue: minor optimization: if A is a stub node, i.e., only one LDP >>session, does it really have to send a label mapping for >>every FEC that >>it has, or can it do it lazily, e.g., when it has a second >>LDP session? >>Reason why not included : It is not clear what problem this change in >>behavior brings, and what would be the added benefit,the issue must >>be discussed on the list first. >> >>- Issue: the ldp loop detection mechanisms don't make sense in DU. >>We should add something explicitly that >>says that these TLVs should not be used in DU mode. ( This is the >>current practice in all implementations that I know of ) >>Why not included: RFC 3036 already states this in the section >>describing these TLVs, when it talks about the usage of the TLVs. >> >>- Issue: the rfc should specifically say that a wildcard release >>message should be sent only in response to a wildcard >>withdraw message. >>Reason not included: it is covered in the rules in the appendix. >> >>- There is a long list of issues that was added to the "for future >>study" area of the RFC. The list is quite long, we could probably >>remove some of the items. >> >> >> > >Nick Weeds >Software Developer >Network Protocols Group >Data Connection Ltd >Tel: +44 1244 305200 >Fax: +44 1244 312422 >Email: Nick.Weeds@dataconnection.com >Web: http://www.dataconnection.com > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > --------------030805050905090609050000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nick,

    See in line.

Nick Weeds wrote:
Ina,

Just a couple of points on the update to RFC 3036...

First, the list of issues not addressed says that RFC 3036 already says that
loop detection should not be used in DU mode.  I can't find this statement
in RFC 3036.  Which section is it in?

I'm pretty sure discussed this on the list, and determined that it is more
appropriate to address when a feature should or should not be used in
an applicability document - such as RFC 3037.

I don't know that there is universal agreement that loop detection is not
used in the DU mode, nor is it relevant from a specification perspective
whether or not it "should" be used - as long as there is agreement that it
either is or is not required to be supported.
Second, the LDP protocol can fail if a Label Mapping crosses with a Label
Release.
This was raised by Kishore Tiruveedhula [tiruveedhula@avici.com] on 25th
August in connection with loop detection, but it is a more general problem
with the protocol.

The problem arises with the following sequence:
(1) Router D sends a Label Mapping
(2) Router U sends a Label Release
(3) Independently router D sends an updated Label Mapping (same FEC and
label, different details).

If messages (2) and (3) cross in transit then the label mapping is
programmed on U (on receipt of the updated Label Mapping) but released on D
(on receipt of the Label Release).  Any data sent using the label will be
lost.

The problem can occur whenever the downstream router sends a Label Mapping
message to update an existing mapping.  This is probably unusual in
practice, but RFC 3036 allows it and indeed describes it for hop count
changes when using independent control (see Kishore's email).  From a quick
check, the MTU signaling extension
(draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to require Label
Mapping updates.  I am not aware of other examples, but the problem is a
potential trap for any LDP protocol extension.
This is not a problem with any reasonably robust implementation.
A "reasonably robust" implementation does something intelligent
with the knowledge that it is getting packets with labels it does not
know how to handle.  Something obvious, like sending a (possibly
redundant) label release to the router from which it receives them.

This is not as simple, if the labels it is getting are the result of PHP.
But even this can be dealt with.

It is unclear how to proceed on this, as potential fixes are likely to
require protocol changes.  Perhaps it would be sufficient to explain the
problem and suggest how to avoid it.
There is no "potential fix", and this has been discussed before. It is
not the task of the author(s) of an RFC to tell their competitors how
to build an implementation that works.

No number of messages - where each message is intended to be
an acknowledgement of the one it is  response to - can ever ensure
that two parties to an exchange are in possession of exactly the same
awareness of the state of a particular exchange token. This is known
variously as the "two generals" or "common knowledge" problem.

(This problem was drawn to my attention in discussions of C-bit negotiation
in draft-ietf-pwe3-control-protocol-xx.txt.  This negotiation takes care to
avoid Label Release messages in response to Label Withdraw "Wrong C-bit".
The protocol problem in RFC 3036 was suggested as one reason for suppressing
the Label Release, but there are probably other reasons too.)

    Nick.

  
-----Original Message-----
From: mpls-bounces@lists.ietf.org 
[mailto:mpls-bounces@lists.ietf.org]On
Behalf Of Ina Minei
Sent: 27 September 2004 19:31
To: mpls@ietf.org
Subject: [mpls] For your review - Issues/errors/clarifications in
RFC3036



   As part of the effort to move RFC3036 to draft standard, here is an
annotated version of RFC3036, with the changes enclosed by ###.
There is a separate section summarizing all changes towards 
the end of the
document.

   Please review the changes and send comments to the list by October
11th.

   At the end of this mail is a list of issues that were raised but
were not included in the annotated RFC (with an explanation of
why).

   Please review both the RFC changes and the list of issues not
included. Also let me know if I forgot to include any other issues
that were raised on the list.

   Many thanks to all who contributed, and in particular to Bob Thomas
for maintaining an extensive list of errors/issues over the years.


            Thank you,

            Ina


Issues that were raised but not included in the annotated RFC
=============================================================

- Issue: discussion on the merits/drawbacks of independent-control and
ordered-control
- Issue: discussion on which FECs should be advertised
Reason why not included: The above two issues are either for the
applicability doc or for the "experiences with the protocol" document.

- Issue:  minor optimization: if A is a stub node, i.e., only one LDP
session, does it really have to send a label mapping for 
every FEC that
it has, or can it do it lazily, e.g., when it has a second 
LDP session?
Reason why not included : It is not clear what problem this change in
behavior brings, and what would be the added benefit,the issue must
be discussed on the list first.

- Issue: the ldp loop detection mechanisms don't make sense in DU.
We should add something explicitly that
says that these TLVs should not be used in DU mode. ( This is the
current practice in all implementations that I know of )
Why not included: RFC 3036 already states this in the section
describing these TLVs, when it talks about the usage of the TLVs.

- Issue: the rfc should specifically say that  a  wildcard release
message should be sent only in response to a wildcard 
withdraw message.
Reason not included: it is covered in the rules in the appendix.

- There is a long list of issues that was added to the "for future
study" area of the RFC. The list is quite long, we could probably
remove some of the items.

    

Nick Weeds
Software Developer
Network Protocols Group
Data Connection Ltd
Tel:    +44 1244 305200
Fax:    +44 1244 312422
Email:  Nick.Weeds@dataconnection.com
Web:    http://www.dataconnection.com

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------030805050905090609050000-- --===============0625431549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0625431549==-- From mpls-bounces@ietf.org Thu Oct 7 19:36:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10827; Thu, 7 Oct 2004 19:36:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhy2-0005Il-Sj; Thu, 07 Oct 2004 19:46:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFhgx-0008H1-R8; Thu, 07 Oct 2004 19:28:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFhfH-0007qr-6S for mpls@megatron.ietf.org; Thu, 07 Oct 2004 19:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10278 for ; Thu, 7 Oct 2004 19:27:11 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhoz-0004nZ-QS for mpls@ietf.org; Thu, 07 Oct 2004 19:37:23 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.7.) id v.1c.ed4c86e (16237); Thu, 7 Oct 2004 19:26:34 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in03.mx.aol.com (v101_r1.4) with ESMTP id MAILININ31-3f6d4165d0a82a8; Thu, 07 Oct 2004 19:26:33 -0400 Message-ID: <4165D0A3.2090101@netscape.net> Date: Thu, 07 Oct 2004 19:26:27 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Nick Weeds Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> In-Reply-To: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.5 (/) X-Scan-Signature: baa5f0d7df7d67a6bff4df65bb02daf5 Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0866475378==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: c2427de1554ed8e3804597b4bf60f110 --===============0866475378== Content-Type: multipart/alternative; boundary="------------000108080806080404070601" --------------000108080806080404070601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nick, Thanks for filling in the details. Please see one comment below. Nick Weeds wrote: >Ina, > >Sorry I didn't explain this clearly. > >The problem arises in window cases where the upstream (U,B) and downstream >(D,A) routers happen to >send LDP messages at the same time. The likelihood of this is low, but it >is possible. > > ! ! > ! /---<----! Label Mapping > ! / ! > ! / ! > ! / ! > ! / ! > ! / ! > !<-------/ ! > ! ! > Label Release !---->---\ ! > ! \ ! > ! \ ! <-- ROUTE CHANGE > ! \ ! > ! \ /---<----! Label Mapping (update) > ! X ! > ! / \------->! > ! / ! > ! / ! > ! / ! > !<-------/ ! > ! ! > > >The Label Release is initiated by the upstream router. It is not a response >to a Label Withdraw. For example, the upstream router might send the Label >Release because it is using conservative retention. > >The downstream router sends the 2nd Label Mapping before receiving the Label >Release. For example, a route change might cause the downstream router to >signaling a change of hop count or a change of MTU. > >At the end of this sequence the downstream router has sent two Label >Mappings and received a Label Release, so it considers the label to be >released. The upstream router has sent a Label Release and received a >subsequent Label Mapping, so it considers the label to be valid. In most >cases the upstream router would send another Label Release, but if the route >has changed then the upstream router might install the label for >forwarding/switching use. If so then any data sent using the label will be >dropped by the downstream router. This isn't a transient condition, it can >continue indefinitely. > > > Not if the downstream router sends a label withdraw as an appropriate recovery response to getting a packet with a label that is invalid. >As I said, the likelihood of this happening is low. I believe typical LDP >usage would avoid this problem by avoiding loop detection, MTU signaling >etc. Nevertheless, RFC 3036 allows such usage, describes hop count >behaviour that can lead to the problem, and fails to mention or prevent the >problem. > >Is that clearer? > > Nick. > > > >>-----Original Message----- >>From: Ina Minei [mailto:ina@juniper.net] >>Sent: 07 October 2004 16:31 >>To: Nick Weeds >>Cc: mpls@ietf.org (E-mail) >>Subject: RE: [mpls] For your review - Issues/errors/clarifications in >>RFC3 036 >> >> >> >> Nick, >> >> I think I am missing something... The label release is sent by >>router B in response to a label withdraw it received from router A. >>A should wait for the release before attempting to send a label map >>again. In the meantime, the label is considered dead on A, and >>if A wants to resurrect it, A should wait until receiving the release. >> >> Are you suggesting that A can resurrect the label it just killed >>before waiting for the release to come? >> >> Thank you, >> >> Ina >> >>On Thu, 7 Oct 2004, Nick Weeds wrote: >> >> >> >>>Ina, >>> >>>Just a couple of points on the update to RFC 3036... >>> >>>First, the list of issues not addressed says that RFC 3036 >>> >>> >>already says that >> >> >>>loop detection should not be used in DU mode. I can't find >>> >>> >>this statement >> >> >>>in RFC 3036. Which section is it in? >>> >>>Second, the LDP protocol can fail if a Label Mapping >>> >>> >>crosses with a Label >> >> >>>Release. >>>This was raised by Kishore Tiruveedhula >>> >>> >>[tiruveedhula@avici.com] on 25th >> >> >>>August in connection with loop detection, but it is a more >>> >>> >>general problem >> >> >>>with the protocol. >>> >>>The problem arises with the following sequence: >>>(1) Router D sends a Label Mapping >>>(2) Router U sends a Label Release >>>(3) Independently router D sends an updated Label Mapping >>> >>> >>(same FEC and >> >> >>>label, different details). >>> >>>If messages (2) and (3) cross in transit then the label mapping is >>>programmed on U (on receipt of the updated Label Mapping) >>> >>> >>but released on D >> >> >>>(on receipt of the Label Release). Any data sent using the >>> >>> >>label will be >> >> >>>lost. >>> >>>The problem can occur whenever the downstream router sends >>> >>> >>a Label Mapping >> >> >>>message to update an existing mapping. This is probably unusual in >>>practice, but RFC 3036 allows it and indeed describes it >>> >>> >>for hop count >> >> >>>changes when using independent control (see Kishore's >>> >>> >>email). From a quick >> >> >>>check, the MTU signaling extension >>>(draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to >>> >>> >>require Label >> >> >>>Mapping updates. I am not aware of other examples, but the >>> >>> >>problem is a >> >> >>>potential trap for any LDP protocol extension. >>> >>>It is unclear how to proceed on this, as potential fixes >>> >>> >>are likely to >> >> >>>require protocol changes. Perhaps it would be sufficient >>> >>> >>to explain the >> >> >>>problem and suggest how to avoid it. >>> >>>(This problem was drawn to my attention in discussions of >>> >>> >>C-bit negotiation >> >> >>>in draft-ietf-pwe3-control-protocol-xx.txt. This >>> >>> >>negotiation takes care to >> >> >>>avoid Label Release messages in response to Label Withdraw >>> >>> >>"Wrong C-bit". >> >> >>>The protocol problem in RFC 3036 was suggested as one >>> >>> >>reason for suppressing >> >> >>>the Label Release, but there are probably other reasons too.) >>> >>> Nick. >>> >>> >>> >>>>-----Original Message----- >>>>From: mpls-bounces@lists.ietf.org >>>>[mailto:mpls-bounces@lists.ietf.org]On >>>>Behalf Of Ina Minei >>>>Sent: 27 September 2004 19:31 >>>>To: mpls@ietf.org >>>>Subject: [mpls] For your review - Issues/errors/clarifications in >>>>RFC3036 >>>> >>>> >>>> >>>> As part of the effort to move RFC3036 to draft >>>> >>>> >>standard, here is an >> >> >>>>annotated version of RFC3036, with the changes enclosed by ###. >>>>There is a separate section summarizing all changes towards >>>>the end of the >>>>document. >>>> >>>> Please review the changes and send comments to the >>>> >>>> >>list by October >> >> >>>>11th. >>>> >>>> At the end of this mail is a list of issues that were >>>> >>>> >>raised but >> >> >>>>were not included in the annotated RFC (with an explanation of >>>>why). >>>> >>>> Please review both the RFC changes and the list of issues not >>>>included. Also let me know if I forgot to include any other issues >>>>that were raised on the list. >>>> >>>> Many thanks to all who contributed, and in particular >>>> >>>> >>to Bob Thomas >> >> >>>>for maintaining an extensive list of errors/issues over the years. >>>> >>>> >>>> Thank you, >>>> >>>> Ina >>>> >>>> >>>>Issues that were raised but not included in the annotated RFC >>>>============================================================= >>>> >>>>- Issue: discussion on the merits/drawbacks of >>>> >>>> >>independent-control and >> >> >>>>ordered-control >>>>- Issue: discussion on which FECs should be advertised >>>>Reason why not included: The above two issues are either for the >>>>applicability doc or for the "experiences with the >>>> >>>> >>protocol" document. >> >> >>>>- Issue: minor optimization: if A is a stub node, i.e., >>>> >>>> >>only one LDP >> >> >>>>session, does it really have to send a label mapping for >>>>every FEC that >>>>it has, or can it do it lazily, e.g., when it has a second >>>>LDP session? >>>>Reason why not included : It is not clear what problem >>>> >>>> >>this change in >> >> >>>>behavior brings, and what would be the added benefit,the >>>> >>>> >>issue must >> >> >>>>be discussed on the list first. >>>> >>>>- Issue: the ldp loop detection mechanisms don't make sense in DU. >>>>We should add something explicitly that >>>>says that these TLVs should not be used in DU mode. ( This is the >>>>current practice in all implementations that I know of ) >>>>Why not included: RFC 3036 already states this in the section >>>>describing these TLVs, when it talks about the usage of the TLVs. >>>> >>>>- Issue: the rfc should specifically say that a wildcard release >>>>message should be sent only in response to a wildcard >>>>withdraw message. >>>>Reason not included: it is covered in the rules in the appendix. >>>> >>>>- There is a long list of issues that was added to the "for future >>>>study" area of the RFC. The list is quite long, we could probably >>>>remove some of the items. >>>> >>>> >>>> >>Nick Weeds >>Software Developer >>Network Protocols Group >>Data Connection Ltd >>Tel: +44 1244 305200 >>Fax: +44 1244 312422 >>Email: Nick.Weeds@dataconnection.com >>Web: http://www.dataconnection.com >> >> >> > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > --------------000108080806080404070601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nick,

    Thanks for filling in the details. Please see one comment below.

Nick Weeds wrote:
Ina,

Sorry I didn't explain this clearly.

The problem arises in window cases where the upstream (U,B) and downstream
(D,A) routers happen to 
send LDP messages at the same time.  The likelihood of this is low, but it
is possible.

                !                       !
                !              /---<----! Label Mapping
                !             /         !
                !            /          !
                !           /           !
                !          /            !
                !         /             !
                !<-------/              !
                !                       !
  Label Release !---->---\              !
                !         \             !
                !          \            ! <-- ROUTE CHANGE
                !           \           !
                !            \ /---<----! Label Mapping (update)
                !             X         !
                !            / \------->!
                !           /           !
                !          /            !
                !         /             !
                !<-------/              !
                !                       !


The Label Release is initiated by the upstream router.  It is not a response
to a Label Withdraw.  For example, the upstream router might send the Label
Release because it is using conservative retention.

The downstream router sends the 2nd Label Mapping before receiving the Label
Release.  For example, a route change might cause the downstream router to
signaling a change of hop count or a change of MTU.

At the end of this sequence the downstream router has sent two Label
Mappings and received a Label Release, so it considers the label to be
released.  The upstream router has sent a Label Release and received a
subsequent Label Mapping, so it considers the label to be valid.  In most
cases the upstream router would send another Label Release, but if the route
has changed then the upstream router might install the label for
forwarding/switching use.  If so then any data sent using the label will be
dropped by the downstream router.  This isn't a transient condition, it can
continue indefinitely.
Not if the downstream router sends a label withdraw as an appropriate
recovery response to getting a packet with a label that is invalid.

As I said, the likelihood of this happening is low.  I believe typical LDP
usage would avoid this problem by avoiding loop detection, MTU signaling
etc.  Nevertheless, RFC 3036 allows such usage, describes hop count
behaviour that can lead to the problem, and fails to mention or prevent the
problem.

Is that clearer?

    Nick.

  
-----Original Message-----
From: Ina Minei [mailto:ina@juniper.net]
Sent: 07 October 2004 16:31
To: Nick Weeds
Cc: mpls@ietf.org (E-mail)
Subject: RE: [mpls] For your review - Issues/errors/clarifications in
RFC3 036



    Nick,

    I think I am missing something... The label release is sent by
router B in response to a label withdraw it received from router A.
A should  wait for the release before attempting to send a label map
again. In the meantime, the label is considered dead on A, and
if A wants to resurrect it, A should wait until receiving the release.

    Are you suggesting that A can resurrect the label it just killed
before waiting for the release to come?

                Thank you,

                    Ina

On Thu, 7 Oct 2004, Nick Weeds wrote:

    
Ina,

Just a couple of points on the update to RFC 3036...

First, the list of issues not addressed says that RFC 3036 
      
already says that
    
loop detection should not be used in DU mode.  I can't find 
      
this statement
    
in RFC 3036.  Which section is it in?

Second, the LDP protocol can fail if a Label Mapping 
      
crosses with a Label
    
Release.
This was raised by Kishore Tiruveedhula 
      
[tiruveedhula@avici.com] on 25th
    
August in connection with loop detection, but it is a more 
      
general problem
    
with the protocol.

The problem arises with the following sequence:
(1) Router D sends a Label Mapping
(2) Router U sends a Label Release
(3) Independently router D sends an updated Label Mapping 
      
(same FEC and
    
label, different details).

If messages (2) and (3) cross in transit then the label mapping is
programmed on U (on receipt of the updated Label Mapping) 
      
but released on D
    
(on receipt of the Label Release).  Any data sent using the 
      
label will be
    
lost.

The problem can occur whenever the downstream router sends 
      
a Label Mapping
    
message to update an existing mapping.  This is probably unusual in
practice, but RFC 3036 allows it and indeed describes it 
      
for hop count
    
changes when using independent control (see Kishore's 
      
email).  From a quick
    
check, the MTU signaling extension
(draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to 
      
require Label
    
Mapping updates.  I am not aware of other examples, but the 
      
problem is a
    
potential trap for any LDP protocol extension.

It is unclear how to proceed on this, as potential fixes 
      
are likely to
    
require protocol changes.  Perhaps it would be sufficient 
      
to explain the
    
problem and suggest how to avoid it.

(This problem was drawn to my attention in discussions of 
      
C-bit negotiation
    
in draft-ietf-pwe3-control-protocol-xx.txt.  This 
      
negotiation takes care to
    
avoid Label Release messages in response to Label Withdraw 
      
"Wrong C-bit".
    
The protocol problem in RFC 3036 was suggested as one 
      
reason for suppressing
    
the Label Release, but there are probably other reasons too.)

    Nick.

      
-----Original Message-----
From: mpls-bounces@lists.ietf.org
[mailto:mpls-bounces@lists.ietf.org]On
Behalf Of Ina Minei
Sent: 27 September 2004 19:31
To: mpls@ietf.org
Subject: [mpls] For your review - Issues/errors/clarifications in
RFC3036



   As part of the effort to move RFC3036 to draft 
        
standard, here is an
    
annotated version of RFC3036, with the changes enclosed by ###.
There is a separate section summarizing all changes towards
the end of the
document.

   Please review the changes and send comments to the 
        
list by October
    
11th.

   At the end of this mail is a list of issues that were 
        
raised but
    
were not included in the annotated RFC (with an explanation of
why).

   Please review both the RFC changes and the list of issues not
included. Also let me know if I forgot to include any other issues
that were raised on the list.

   Many thanks to all who contributed, and in particular 
        
to Bob Thomas
    
for maintaining an extensive list of errors/issues over the years.


            Thank you,

            Ina


Issues that were raised but not included in the annotated RFC
=============================================================

- Issue: discussion on the merits/drawbacks of 
        
independent-control and
    
ordered-control
- Issue: discussion on which FECs should be advertised
Reason why not included: The above two issues are either for the
applicability doc or for the "experiences with the 
        
protocol" document.
    
- Issue:  minor optimization: if A is a stub node, i.e., 
        
only one LDP
    
session, does it really have to send a label mapping for
every FEC that
it has, or can it do it lazily, e.g., when it has a second
LDP session?
Reason why not included : It is not clear what problem 
        
this change in
    
behavior brings, and what would be the added benefit,the 
        
issue must
    
be discussed on the list first.

- Issue: the ldp loop detection mechanisms don't make sense in DU.
We should add something explicitly that
says that these TLVs should not be used in DU mode. ( This is the
current practice in all implementations that I know of )
Why not included: RFC 3036 already states this in the section
describing these TLVs, when it talks about the usage of the TLVs.

- Issue: the rfc should specifically say that  a  wildcard release
message should be sent only in response to a wildcard
withdraw message.
Reason not included: it is covered in the rules in the appendix.

- There is a long list of issues that was added to the "for future
study" area of the RFC. The list is quite long, we could probably
remove some of the items.

        
Nick Weeds
Software Developer
Network Protocols Group
Data Connection Ltd
Tel:    +44 1244 305200
Fax:    +44 1244 312422
Email:  Nick.Weeds@dataconnection.com
Web:    http://www.dataconnection.com

    

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------000108080806080404070601-- --===============0866475378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0866475378==-- From mpls-bounces@ietf.org Thu Oct 7 20:22:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17910; Thu, 7 Oct 2004 20:22:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFigO-0000Cd-48; Thu, 07 Oct 2004 20:32:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFiTG-00022g-Gv; Thu, 07 Oct 2004 20:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFi63-0004BO-V9 for mpls@megatron.ietf.org; Thu, 07 Oct 2004 19:54:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12810 for ; Thu, 7 Oct 2004 19:54:47 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFiFk-0006O2-Av for mpls@ietf.org; Thu, 07 Oct 2004 20:04:57 -0400 Received: from elmo.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id QAA16439; Thu, 7 Oct 2004 16:54:13 -0700 (PDT) Received: from riverstonenet.com (localhost [127.0.0.1]) by elmo.riverstonenet.com (8.11.6+Sun/8.11.6) with ESMTP id i97No1w05050; Thu, 7 Oct 2004 16:50:02 -0700 (PDT) Message-ID: <4165D629.1070406@riverstonenet.com> Date: Thu, 07 Oct 2004 16:50:01 -0700 From: Rama Ramakrishnan User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ewgray@GraIyMage.com Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> <4165D0A3.2090101@netscape.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Content-Transfer-Encoding: 7bit Eric Gray wrote: > Nick, > > Thanks for filling in the details. Please see one comment below. > > Nick Weeds wrote: > >>Ina, >> >>Sorry I didn't explain this clearly. >> >>The problem arises in window cases where the upstream (U,B) and downstream >>(D,A) routers happen to >>send LDP messages at the same time. The likelihood of this is low, but it >>is possible. >> >> ! ! >> ! /---<----! Label Mapping >> ! / ! >> ! / ! >> ! / ! >> ! / ! >> ! / ! >> !<-------/ ! >> ! ! >> Label Release !---->---\ ! >> ! \ ! >> ! \ ! <-- ROUTE CHANGE >> ! \ ! >> ! \ /---<----! Label Mapping (update) >> ! X ! >> ! / \------->! >> ! / ! >> ! / ! >> ! / ! >> !<-------/ ! >> ! ! >> >> >>The Label Release is initiated by the upstream router. It is not a response >>to a Label Withdraw. For example, the upstream router might send the Label >>Release because it is using conservative retention. >> >>The downstream router sends the 2nd Label Mapping before receiving the Label >>Release. For example, a route change might cause the downstream router to >>signaling a change of hop count or a change of MTU. >> >>At the end of this sequence the downstream router has sent two Label >>Mappings and received a Label Release, so it considers the label to be >>released. The upstream router has sent a Label Release and received a >>subsequent Label Mapping, so it considers the label to be valid. In most >>cases the upstream router would send another Label Release, but if the route >>has changed then the upstream router might install the label for >>forwarding/switching use. If so then any data sent using the label will be >>dropped by the downstream router. This isn't a transient condition, it can >>continue indefinitely. >> >> >> > Not if the downstream router sends a label withdraw as an appropriate > recovery response to getting a packet with a label that is invalid. > But there may be a problem if the downstream router allocates the same label for a different FEC (may be for a different protocol like RSVP) Regards, Rama >>As I said, the likelihood of this happening is low. I believe typical LDP >>usage would avoid this problem by avoiding loop detection, MTU signaling >>etc. Nevertheless, RFC 3036 allows such usage, describes hop count >>behaviour that can lead to the problem, and fails to mention or prevent the >>problem. >> >>Is that clearer? >> >> Nick. >> >> >> >>>-----Original Message----- >>>From: Ina Minei [mailto:ina@juniper.net] >>>Sent: 07 October 2004 16:31 >>>To: Nick Weeds >>>Cc: mpls@ietf.org (E-mail) >>>Subject: RE: [mpls] For your review - Issues/errors/clarifications in >>>RFC3 036 >>> >>> >>> >>> Nick, >>> >>> I think I am missing something... The label release is sent by >>>router B in response to a label withdraw it received from router A. >>>A should wait for the release before attempting to send a label map >>>again. In the meantime, the label is considered dead on A, and >>>if A wants to resurrect it, A should wait until receiving the release. >>> >>> Are you suggesting that A can resurrect the label it just killed >>>before waiting for the release to come? >>> >>> Thank you, >>> >>> Ina >>> >>>On Thu, 7 Oct 2004, Nick Weeds wrote: >>> >>> >>> >>>>Ina, >>>> >>>>Just a couple of points on the update to RFC 3036... >>>> >>>>First, the list of issues not addressed says that RFC 3036 >>>> >>>> >>>already says that >>> >>> >>>>loop detection should not be used in DU mode. I can't find >>>> >>>> >>>this statement >>> >>> >>>>in RFC 3036. Which section is it in? >>>> >>>>Second, the LDP protocol can fail if a Label Mapping >>>> >>>> >>>crosses with a Label >>> >>> >>>>Release. >>>>This was raised by Kishore Tiruveedhula >>>> >>>> >>>[tiruveedhula@avici.com] on 25th >>> >>> >>>>August in connection with loop detection, but it is a more >>>> >>>> >>>general problem >>> >>> >>>>with the protocol. >>>> >>>>The problem arises with the following sequence: >>>>(1) Router D sends a Label Mapping >>>>(2) Router U sends a Label Release >>>>(3) Independently router D sends an updated Label Mapping >>>> >>>> >>>(same FEC and >>> >>> >>>>label, different details). >>>> >>>>If messages (2) and (3) cross in transit then the label mapping is >>>>programmed on U (on receipt of the updated Label Mapping) >>>> >>>> >>>but released on D >>> >>> >>>>(on receipt of the Label Release). Any data sent using the >>>> >>>> >>>label will be >>> >>> >>>>lost. >>>> >>>>The problem can occur whenever the downstream router sends >>>> >>>> >>>a Label Mapping >>> >>> >>>>message to update an existing mapping. This is probably unusual in >>>>practice, but RFC 3036 allows it and indeed describes it >>>> >>>> >>>for hop count >>> >>> >>>>changes when using independent control (see Kishore's >>>> >>>> >>>email). From a quick >>> >>> >>>>check, the MTU signaling extension >>>>(draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to >>>> >>>> >>>require Label >>> >>> >>>>Mapping updates. I am not aware of other examples, but the >>>> >>>> >>>problem is a >>> >>> >>>>potential trap for any LDP protocol extension. >>>> >>>>It is unclear how to proceed on this, as potential fixes >>>> >>>> >>>are likely to >>> >>> >>>>require protocol changes. Perhaps it would be sufficient >>>> >>>> >>>to explain the >>> >>> >>>>problem and suggest how to avoid it. >>>> >>>>(This problem was drawn to my attention in discussions of >>>> >>>> >>>C-bit negotiation >>> >>> >>>>in draft-ietf-pwe3-control-protocol-xx.txt. This >>>> >>>> >>>negotiation takes care to >>> >>> >>>>avoid Label Release messages in response to Label Withdraw >>>> >>>> >>>"Wrong C-bit". >>> >>> >>>>The protocol problem in RFC 3036 was suggested as one >>>> >>>> >>>reason for suppressing >>> >>> >>>>the Label Release, but there are probably other reasons too.) >>>> >>>> Nick. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: mpls-bounces@lists.ietf.org >>>>>[mailto:mpls-bounces@lists.ietf.org]On >>>>>Behalf Of Ina Minei >>>>>Sent: 27 September 2004 19:31 >>>>>To: mpls@ietf.org >>>>>Subject: [mpls] For your review - Issues/errors/clarifications in >>>>>RFC3036 >>>>> >>>>> >>>>> >>>>> As part of the effort to move RFC3036 to draft >>>>> >>>>> >>>standard, here is an >>> >>> >>>>>annotated version of RFC3036, with the changes enclosed by ###. >>>>>There is a separate section summarizing all changes towards >>>>>the end of the >>>>>document. >>>>> >>>>> Please review the changes and send comments to the >>>>> >>>>> >>>list by October >>> >>> >>>>>11th. >>>>> >>>>> At the end of this mail is a list of issues that were >>>>> >>>>> >>>raised but >>> >>> >>>>>were not included in the annotated RFC (with an explanation of >>>>>why). >>>>> >>>>> Please review both the RFC changes and the list of issues not >>>>>included. Also let me know if I forgot to include any other issues >>>>>that were raised on the list. >>>>> >>>>> Many thanks to all who contributed, and in particular >>>>> >>>>> >>>to Bob Thomas >>> >>> >>>>>for maintaining an extensive list of errors/issues over the years. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Ina >>>>> >>>>> >>>>>Issues that were raised but not included in the annotated RFC >>>>>============================================================= >>>>> >>>>>- Issue: discussion on the merits/drawbacks of >>>>> >>>>> >>>independent-control and >>> >>> >>>>>ordered-control >>>>>- Issue: discussion on which FECs should be advertised >>>>>Reason why not included: The above two issues are either for the >>>>>applicability doc or for the "experiences with the >>>>> >>>>> >>>protocol" document. >>> >>> >>>>>- Issue: minor optimization: if A is a stub node, i.e., >>>>> >>>>> >>>only one LDP >>> >>> >>>>>session, does it really have to send a label mapping for >>>>>every FEC that >>>>>it has, or can it do it lazily, e.g., when it has a second >>>>>LDP session? >>>>>Reason why not included : It is not clear what problem >>>>> >>>>> >>>this change in >>> >>> >>>>>behavior brings, and what would be the added benefit,the >>>>> >>>>> >>>issue must >>> >>> >>>>>be discussed on the list first. >>>>> >>>>>- Issue: the ldp loop detection mechanisms don't make sense in DU. >>>>>We should add something explicitly that >>>>>says that these TLVs should not be used in DU mode. ( This is the >>>>>current practice in all implementations that I know of ) >>>>>Why not included: RFC 3036 already states this in the section >>>>>describing these TLVs, when it talks about the usage of the TLVs. >>>>> >>>>>- Issue: the rfc should specifically say that a wildcard release >>>>>message should be sent only in response to a wildcard >>>>>withdraw message. >>>>>Reason not included: it is covered in the rules in the appendix. >>>>> >>>>>- There is a long list of issues that was added to the "for future >>>>>study" area of the RFC. The list is quite long, we could probably >>>>>remove some of the items. >>>>> >>>>> >>>>> >>>Nick Weeds >>>Software Developer >>>Network Protocols Group >>>Data Connection Ltd >>>Tel: +44 1244 305200 >>>Fax: +44 1244 312422 >>>Email: Nick.Weeds@dataconnection.com >>>Web: http://www.dataconnection.com >>> >>> >>> >> >>_______________________________________________ >>mpls mailing list >>mpls@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/mpls >> >> >> >> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 21:57:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25123; Thu, 7 Oct 2004 21:57:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkAQ-0006Mu-Td; Thu, 07 Oct 2004 22:07:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFjyT-0004Jo-MV; Thu, 07 Oct 2004 21:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFjy1-00049f-4i for mpls@megatron.ietf.org; Thu, 07 Oct 2004 21:54:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24918 for ; Thu, 7 Oct 2004 21:54:42 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFk7m-0006Bj-Ov for mpls@ietf.org; Thu, 07 Oct 2004 22:04:54 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i981sA939833; Thu, 7 Oct 2004 18:54:10 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i981s5e66640; Thu, 7 Oct 2004 18:54:05 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 7 Oct 2004 18:54:05 -0700 (PDT) From: Ina Minei To: ewgray@GraIyMage.com Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 In-Reply-To: <4165CFAA.2050300@netscape.net> Message-ID: <20041007184917.U52473@garnet.juniper.net> References: <16E71652255A3E4796A7AF3A9E5068F90304A9@blakey.datcon.co.uk> <4165CFAA.2050300@netscape.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Eric raises a very good point - the issue of the interaction of DU and loop-detection mechanisms should be discussed as part of an applicability document, not part of the protocol specification. Which means that in any case it should continue to stay in the "not included" list. Ina On Thu, 7 Oct 2004, Eric Gray wrote: > Nick, > > See in line. > > Nick Weeds wrote: > > >Ina, > > > >Just a couple of points on the update to RFC 3036... > > > >First, the list of issues not addressed says that RFC 3036 already says that > >loop detection should not be used in DU mode. I can't find this statement > >in RFC 3036. Which section is it in? > > > > > > I'm pretty sure discussed this on the list, and determined that it is more > appropriate to address when a feature should or should not be used in > an applicability document - such as RFC 3037. > > I don't know that there is universal agreement that loop detection is not > used in the DU mode, nor is it relevant from a specification perspective > whether or not it "should" be used - as long as there is agreement that it > either is or is not required to be supported. > > >Second, the LDP protocol can fail if a Label Mapping crosses with a Label > >Release. > >This was raised by Kishore Tiruveedhula [tiruveedhula@avici.com] on 25th > >August in connection with loop detection, but it is a more general problem > >with the protocol. > > > >The problem arises with the following sequence: > >(1) Router D sends a Label Mapping > >(2) Router U sends a Label Release > >(3) Independently router D sends an updated Label Mapping (same FEC and > >label, different details). > > > >If messages (2) and (3) cross in transit then the label mapping is > >programmed on U (on receipt of the updated Label Mapping) but released on D > >(on receipt of the Label Release). Any data sent using the label will be > >lost. > > > >The problem can occur whenever the downstream router sends a Label Mapping > >message to update an existing mapping. This is probably unusual in > >practice, but RFC 3036 allows it and indeed describes it for hop count > >changes when using independent control (see Kishore's email). From a quick > >check, the MTU signaling extension > >(draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to require Label > >Mapping updates. I am not aware of other examples, but the problem is a > >potential trap for any LDP protocol extension. > > > > > > > This is not a problem with any reasonably robust implementation. > A "reasonably robust" implementation does something intelligent > with the knowledge that it is getting packets with labels it does not > know how to handle. Something obvious, like sending a (possibly > redundant) label release to the router from which it receives them. > > This is not as simple, if the labels it is getting are the result of PHP. > But even this can be dealt with. > > >It is unclear how to proceed on this, as potential fixes are likely to > >require protocol changes. Perhaps it would be sufficient to explain the > >problem and suggest how to avoid it. > > > > > There is no "potential fix", and this has been discussed before. It is > not the task of the author(s) of an RFC to tell their competitors how > to build an implementation that works. > > No number of messages - where each message is intended to be > an acknowledgement of the one it is response to - can ever ensure > that two parties to an exchange are in possession of exactly the same > awareness of the state of a particular exchange token. This is known > variously as the "two generals" or "common knowledge" problem. > > >(This problem was drawn to my attention in discussions of C-bit negotiation > >in draft-ietf-pwe3-control-protocol-xx.txt. This negotiation takes care to > >avoid Label Release messages in response to Label Withdraw "Wrong C-bit". > >The protocol problem in RFC 3036 was suggested as one reason for suppressing > >the Label Release, but there are probably other reasons too.) > > > > Nick. > > > > > > > >>-----Original Message----- > >>From: mpls-bounces@lists.ietf.org > >>[mailto:mpls-bounces@lists.ietf.org]On > >>Behalf Of Ina Minei > >>Sent: 27 September 2004 19:31 > >>To: mpls@ietf.org > >>Subject: [mpls] For your review - Issues/errors/clarifications in > >>RFC3036 > >> > >> > >> > >> As part of the effort to move RFC3036 to draft standard, here is an > >>annotated version of RFC3036, with the changes enclosed by ###. > >>There is a separate section summarizing all changes towards > >>the end of the > >>document. > >> > >> Please review the changes and send comments to the list by October > >>11th. > >> > >> At the end of this mail is a list of issues that were raised but > >>were not included in the annotated RFC (with an explanation of > >>why). > >> > >> Please review both the RFC changes and the list of issues not > >>included. Also let me know if I forgot to include any other issues > >>that were raised on the list. > >> > >> Many thanks to all who contributed, and in particular to Bob Thomas > >>for maintaining an extensive list of errors/issues over the years. > >> > >> > >> Thank you, > >> > >> Ina > >> > >> > >>Issues that were raised but not included in the annotated RFC > >>============================================================= > >> > >>- Issue: discussion on the merits/drawbacks of independent-control and > >>ordered-control > >>- Issue: discussion on which FECs should be advertised > >>Reason why not included: The above two issues are either for the > >>applicability doc or for the "experiences with the protocol" document. > >> > >>- Issue: minor optimization: if A is a stub node, i.e., only one LDP > >>session, does it really have to send a label mapping for > >>every FEC that > >>it has, or can it do it lazily, e.g., when it has a second > >>LDP session? > >>Reason why not included : It is not clear what problem this change in > >>behavior brings, and what would be the added benefit,the issue must > >>be discussed on the list first. > >> > >>- Issue: the ldp loop detection mechanisms don't make sense in DU. > >>We should add something explicitly that > >>says that these TLVs should not be used in DU mode. ( This is the > >>current practice in all implementations that I know of ) > >>Why not included: RFC 3036 already states this in the section > >>describing these TLVs, when it talks about the usage of the TLVs. > >> > >>- Issue: the rfc should specifically say that a wildcard release > >>message should be sent only in response to a wildcard > >>withdraw message. > >>Reason not included: it is covered in the rules in the appendix. > >> > >>- There is a long list of issues that was added to the "for future > >>study" area of the RFC. The list is quite long, we could probably > >>remove some of the items. > >> > >> > >> > > > >Nick Weeds > >Software Developer > >Network Protocols Group > >Data Connection Ltd > >Tel: +44 1244 305200 > >Fax: +44 1244 312422 > >Email: Nick.Weeds@dataconnection.com > >Web: http://www.dataconnection.com > > > >_______________________________________________ > >mpls mailing list > >mpls@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 22:15:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27171; Thu, 7 Oct 2004 22:15:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkSP-0007cY-QJ; Thu, 07 Oct 2004 22:26:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFkDc-0007MM-At; Thu, 07 Oct 2004 22:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFk9T-0006ZY-O9 for mpls@megatron.ietf.org; Thu, 07 Oct 2004 22:06:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25697 for ; Thu, 7 Oct 2004 22:06:33 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkJI-0006tZ-9Y for mpls@ietf.org; Thu, 07 Oct 2004 22:16:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i98264939946; Thu, 7 Oct 2004 19:06:04 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9825xe69170; Thu, 7 Oct 2004 19:05:59 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 7 Oct 2004 19:05:58 -0700 (PDT) From: Ina Minei To: Kishore Tiruveedhula Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 In-Reply-To: <003001c4aca8$efc9a7b0$e514020a@avici.com> Message-ID: <20041007184419.L47078@garnet.juniper.net> References: <003001c4aca8$efc9a7b0$e514020a@avici.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Check out Venkata's pointer to the previous discussion, it refers to the note in the appendix. http://www.cell-relay.com/mhonarc/mpls/2002-Jan/msg00120.html Ina On Thu, 7 Oct 2004, Kishore Tiruveedhula wrote: > Yes. This problem happens if the the downstream router re-sends Label > Mapping to upstream router to update the parameters like hop count or path > vectors and if the receiving label release message is on the wire. > There is no one-to-one mapping between Label Mapping and Label Release > messages. > > And one more issue: > ****************** > Note 1 of A.1.4 says, When the label Release Message is received from > upstream peer, the router shouldn't send Label Mapping until the upstream > router requests it. > Is it make sense for not sending the Mapping until the MsgSource requests it > ?? > > ************************************************** > A.1.4. Receive Label Release > > Notes: > > 1. If LSR is using Downstream Unsolicited label distribution, it > should not re-advertise a label mapping for FEC to MsgSource > until MsgSource requests it. > ***************************************************** > > Thanks, > Kishore > > -----Original Message----- > From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]On > Behalf Of Nick Weeds > Sent: Thursday, October 07, 2004 12:38 PM > To: 'Ina Minei' > Cc: mpls@ietf.org (E-mail) > Subject: RE: [mpls] For your review - Issues/errors/clarifications in > RFC3 036 > > > Ina, > > Sorry I didn't explain this clearly. > > The problem arises in window cases where the upstream (U,B) and downstream > (D,A) routers happen to > send LDP messages at the same time. The likelihood of this is low, but it > is possible. > > ! ! > ! /---<----! Label Mapping > ! / ! > ! / ! > ! / ! > ! / ! > ! / ! > !<-------/ ! > ! ! > Label Release !---->---\ ! > ! \ ! > ! \ ! <-- ROUTE CHANGE > ! \ ! > ! \ /---<----! Label Mapping (update) > ! X ! > ! / \------->! > ! / ! > ! / ! > ! / ! > !<-------/ ! > ! ! > > > The Label Release is initiated by the upstream router. It is not a response > to a Label Withdraw. For example, the upstream router might send the Label > Release because it is using conservative retention. > > The downstream router sends the 2nd Label Mapping before receiving the Label > Release. For example, a route change might cause the downstream router to > signaling a change of hop count or a change of MTU. > > At the end of this sequence the downstream router has sent two Label > Mappings and received a Label Release, so it considers the label to be > released. The upstream router has sent a Label Release and received a > subsequent Label Mapping, so it considers the label to be valid. In most > cases the upstream router would send another Label Release, but if the route > has changed then the upstream router might install the label for > forwarding/switching use. If so then any data sent using the label will be > dropped by the downstream router. This isn't a transient condition, it can > continue indefinitely. > > As I said, the likelihood of this happening is low. I believe typical LDP > usage would avoid this problem by avoiding loop detection, MTU signaling > etc. Nevertheless, RFC 3036 allows such usage, describes hop count > behaviour that can lead to the problem, and fails to mention or prevent the > problem. > > Is that clearer? > > Nick. > > > -----Original Message----- > > From: Ina Minei [mailto:ina@juniper.net] > > Sent: 07 October 2004 16:31 > > To: Nick Weeds > > Cc: mpls@ietf.org (E-mail) > > Subject: RE: [mpls] For your review - Issues/errors/clarifications in > > RFC3 036 > > > > > > > > Nick, > > > > I think I am missing something... The label release is sent by > > router B in response to a label withdraw it received from router A. > > A should wait for the release before attempting to send a label map > > again. In the meantime, the label is considered dead on A, and > > if A wants to resurrect it, A should wait until receiving the release. > > > > Are you suggesting that A can resurrect the label it just killed > > before waiting for the release to come? > > > > Thank you, > > > > Ina > > > > On Thu, 7 Oct 2004, Nick Weeds wrote: > > > > > Ina, > > > > > > Just a couple of points on the update to RFC 3036... > > > > > > First, the list of issues not addressed says that RFC 3036 > > already says that > > > loop detection should not be used in DU mode. I can't find > > this statement > > > in RFC 3036. Which section is it in? > > > > > > Second, the LDP protocol can fail if a Label Mapping > > crosses with a Label > > > Release. > > > This was raised by Kishore Tiruveedhula > > [tiruveedhula@avici.com] on 25th > > > August in connection with loop detection, but it is a more > > general problem > > > with the protocol. > > > > > > The problem arises with the following sequence: > > > (1) Router D sends a Label Mapping > > > (2) Router U sends a Label Release > > > (3) Independently router D sends an updated Label Mapping > > (same FEC and > > > label, different details). > > > > > > If messages (2) and (3) cross in transit then the label mapping is > > > programmed on U (on receipt of the updated Label Mapping) > > but released on D > > > (on receipt of the Label Release). Any data sent using the > > label will be > > > lost. > > > > > > The problem can occur whenever the downstream router sends > > a Label Mapping > > > message to update an existing mapping. This is probably unusual in > > > practice, but RFC 3036 allows it and indeed describes it > > for hop count > > > changes when using independent control (see Kishore's > > email). From a quick > > > check, the MTU signaling extension > > > (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to > > require Label > > > Mapping updates. I am not aware of other examples, but the > > problem is a > > > potential trap for any LDP protocol extension. > > > > > > It is unclear how to proceed on this, as potential fixes > > are likely to > > > require protocol changes. Perhaps it would be sufficient > > to explain the > > > problem and suggest how to avoid it. > > > > > > (This problem was drawn to my attention in discussions of > > C-bit negotiation > > > in draft-ietf-pwe3-control-protocol-xx.txt. This > > negotiation takes care to > > > avoid Label Release messages in response to Label Withdraw > > "Wrong C-bit". > > > The protocol problem in RFC 3036 was suggested as one > > reason for suppressing > > > the Label Release, but there are probably other reasons too.) > > > > > > Nick. > > > > > > > -----Original Message----- > > > > From: mpls-bounces@lists.ietf.org > > > > [mailto:mpls-bounces@lists.ietf.org]On > > > > Behalf Of Ina Minei > > > > Sent: 27 September 2004 19:31 > > > > To: mpls@ietf.org > > > > Subject: [mpls] For your review - Issues/errors/clarifications in > > > > RFC3036 > > > > > > > > > > > > > > > > As part of the effort to move RFC3036 to draft > > standard, here is an > > > > annotated version of RFC3036, with the changes enclosed by ###. > > > > There is a separate section summarizing all changes towards > > > > the end of the > > > > document. > > > > > > > > Please review the changes and send comments to the > > list by October > > > > 11th. > > > > > > > > At the end of this mail is a list of issues that were > > raised but > > > > were not included in the annotated RFC (with an explanation of > > > > why). > > > > > > > > Please review both the RFC changes and the list of issues not > > > > included. Also let me know if I forgot to include any other issues > > > > that were raised on the list. > > > > > > > > Many thanks to all who contributed, and in particular > > to Bob Thomas > > > > for maintaining an extensive list of errors/issues over the years. > > > > > > > > > > > > Thank you, > > > > > > > > Ina > > > > > > > > > > > > Issues that were raised but not included in the annotated RFC > > > > ============================================================= > > > > > > > > - Issue: discussion on the merits/drawbacks of > > independent-control and > > > > ordered-control > > > > - Issue: discussion on which FECs should be advertised > > > > Reason why not included: The above two issues are either for the > > > > applicability doc or for the "experiences with the > > protocol" document. > > > > > > > > - Issue: minor optimization: if A is a stub node, i.e., > > only one LDP > > > > session, does it really have to send a label mapping for > > > > every FEC that > > > > it has, or can it do it lazily, e.g., when it has a second > > > > LDP session? > > > > Reason why not included : It is not clear what problem > > this change in > > > > behavior brings, and what would be the added benefit,the > > issue must > > > > be discussed on the list first. > > > > > > > > - Issue: the ldp loop detection mechanisms don't make sense in DU. > > > > We should add something explicitly that > > > > says that these TLVs should not be used in DU mode. ( This is the > > > > current practice in all implementations that I know of ) > > > > Why not included: RFC 3036 already states this in the section > > > > describing these TLVs, when it talks about the usage of the TLVs. > > > > > > > > - Issue: the rfc should specifically say that a wildcard release > > > > message should be sent only in response to a wildcard > > > > withdraw message. > > > > Reason not included: it is covered in the rules in the appendix. > > > > > > > > - There is a long list of issues that was added to the "for future > > > > study" area of the RFC. The list is quite long, we could probably > > > > remove some of the items. > > > > > > > > > > > Nick Weeds > > Software Developer > > Network Protocols Group > > Data Connection Ltd > > Tel: +44 1244 305200 > > Fax: +44 1244 312422 > > Email: Nick.Weeds@dataconnection.com > > Web: http://www.dataconnection.com > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 7 22:54:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29178; Thu, 7 Oct 2004 22:54:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFl47-0001Wr-8S; Thu, 07 Oct 2004 23:05:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFkpa-0005iV-QG; Thu, 07 Oct 2004 22:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFkl4-00053t-9Q for mpls@megatron.ietf.org; Thu, 07 Oct 2004 22:45:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28776 for ; Thu, 7 Oct 2004 22:45:23 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkus-0000zP-EF for mpls@ietf.org; Thu, 07 Oct 2004 22:55:35 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 07 Oct 2004 19:45:46 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i982imwp002083; Thu, 7 Oct 2004 19:44:48 -0700 (PDT) Received: from pmohapatw2k ([10.32.15.109]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id AXJ60693; Thu, 7 Oct 2004 19:47:11 -0700 (PDT) From: "Pradosh Mohapatra" To: Subject: RE: [mpls] Avoiding LDP graceful restart with planned node shutdown. Date: Thu, 7 Oct 2004 19:44:50 -0700 Message-ID: <005301c4ace0$c83b7c90$6d0f200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <000901c4ac74$58e76500$51d42ca1@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Andy, >While RFC3478 makes no specific comment on how to do so, a possible >approach would be that when a node detects the failure of a peer >through receipt of a Notification (shutdown), the receiving node >assumes this is a planned shutdown of the peer, and disables graceful >restart. > I think the shutdown notification has a wider meaning; anytime the LSR chooses to terminate a session, it sends the shutdown msg. e.g. during Software upgrades, manual process restarts etc. That still means that the forwarding state is intact. A better idea is probably to delete the label mappings from the peer explicitly during planned shutdown. Thanks/Pradosh >In all other cases (TCP socket error, keepalive timeout etc.), the node >assumes unplanned shutdown, and starts its graceful restart neighbour >reconnect / liveness timer for the session. > >I'd like to get clarification if this is in fact the intent in the >standard? > >Thanks, > >Andy. > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 00:09:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04129; Fri, 8 Oct 2004 00:09:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmE2-000554-2N; Fri, 08 Oct 2004 00:19:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFm0t-0004Xa-0m; Fri, 08 Oct 2004 00:05:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFijk-0006lm-3H for mpls@megatron.ietf.org; Thu, 07 Oct 2004 20:35:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19254; Thu, 7 Oct 2004 20:35:46 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFitQ-0001A9-9K; Thu, 07 Oct 2004 20:45:56 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i980ZB939402; Thu, 7 Oct 2004 17:35:11 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i980Z6e55477; Thu, 7 Oct 2004 17:35:06 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 7 Oct 2004 17:35:06 -0700 (PDT) From: Ina Minei To: Alexa Morris , "" , "" , "" , "" In-Reply-To: <200410071543.i97FhVOE013263@puddle.amsl.com> Message-ID: <20041007165429.R84440@garnet.juniper.net> References: <200410071543.i97FhVOE013263@puddle.amsl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Fri, 08 Oct 2004 00:05:46 -0400 Cc: statements@ietf.org, rcheruku@cisco.com, mpls@ietf.org Subject: [mpls] Re: Liaison from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Alexa, The request to remove the Host FEC was proposed because it didn't seem to be in use by any LDP implementation. Your input shows that this is not the case. Luca, Arashmid, Markus, Rama, As proponents of this change, your input on this issue would be appreciated. In particular, if the Host FEC is not deprecated, does it still make sense to relax the rules of mapping packets to LSPs and treat Host FECs and Address FECs equivalently when they are identical? Ina On Thu, 7 Oct 2004, Alexa Morris wrote: > This email is being sent on behalf of Rao Cherukuri, rcheruku@cisco.com. > > Dear George, Loa and Ina: > > A recent message on the MPLS WG mailing list > (http://www.cell-relay.com/mhonarc/mpls/2004-Sep/msg00043.html) has > suggested changes to RFC 3036 ("LDP Specification") and called for comments > on the proposed changes. One of the proposed changes is to deprecate the > use of the Host Address FEC TLV. Two Implementation Agreements published by > the MPLS & Frame Relay Alliance (MFA), "MPLS Proxy Admission Control > Definition" and "MPLS Proxy Admission Control Protocol", MFA.6.0.0 and > MFA.7.0.0 > (http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pd > f and > http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf) > make use of the Host Address FEC TLV. MPLS Proxy Admission Control provides > a bandwidth-based reservation/admission facility for MPLS networks. There > are implementations of this protocol in progress. > > While the proposed changes make a Prefix FEC TLV with a 32-bit mask > equivalent to a Host Address FEC TLV, adopting the Prefix FEC TLV would > require changes to approved and published MFA documents, and changes to the > implementations. Also, since MPLS Proxy Admission Control only uses host > addresses, using the Prefix FEC TLV would necessitate an additional check > that the prefix was always 32 bits. Therefore, the MFA kindly requests that > the Host Address FEC TLV not be deprecated, and that it continues to be > supported in future revisions of LDP. > > In RFC 3036, there is a semantic difference between a Host Address and a > prefix with length 32. The new version proposes to remove the semantic > difference. This is not a problem for the MPLS Proxy Admission Control; we > are just requesting that the Host Address codepoint not be deprecated. > > Please advise us as soon as possible about the decision on this issue. > > Cordially, > Rao Cherukuri > MPLS & Frame Relay Alliance > Technical Committee Chair > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 00:13:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04375; Fri, 8 Oct 2004 00:13:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmII-0005Bs-Ca; Fri, 08 Oct 2004 00:23:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFm1B-0004cv-6r; Fri, 08 Oct 2004 00:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFlzz-0004QN-NF for mpls@megatron.ietf.org; Fri, 08 Oct 2004 00:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03839 for ; Fri, 8 Oct 2004 00:04:52 -0400 (EDT) Received: from host19.ipowerweb.com ([66.235.218.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFm9o-000512-Ry for mpls@ietf.org; Fri, 08 Oct 2004 00:15:05 -0400 Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.61.197.198] helo=[127.0.0.1]) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 1CFlz9-0006G7-00; Thu, 07 Oct 2004 21:04:03 -0700 Message-ID: <416611AA.8020407@GraIyMage.com> Date: Fri, 08 Oct 2004 00:03:54 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Rama Ramakrishnan Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> <4165D0A3.2090101@netscape.net> <4165D629.1070406@riverstonenet.com> In-Reply-To: <4165D629.1070406@riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - GraIyMage.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org \(E-mail\)" , ewgray@GraIyMage.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Content-Transfer-Encoding: 7bit Rama, Yes, Bob Thomas and I talked about this problem _years_ ago (:-)) Bob seemed to feel that there are several way that an implementation can avoid re-issuing the same label too soon after it "becomes available". Since he and I were both working on separate LDP implementations at the time, I couldn't really find a hole in that argument. Therefore, this is a "race" condition where you can hobble the competition. One other comment in response - the protocol that issues a label should be irrelevant in the sense that you're addressing. Either the multiple signaling protocols are getting the labels from the same pool or they're not. If they're not, the problem does not exist. If they are, then a sensible implementation would benefit from using a common under-lying label allocation scheme. -- Eric Rama Ramakrishnan wrote: > > > Eric Gray wrote: > >> Nick, >> >> Thanks for filling in the details. Please see one comment below. >> >> Nick Weeds wrote: >> >>> Ina, >>> >>> Sorry I didn't explain this clearly. >>> >>> The problem arises in window cases where the upstream (U,B) and >>> downstream >>> (D,A) routers happen to send LDP messages at the same time. The >>> likelihood of this is low, but it >>> is possible. >>> >>> ! ! >>> ! /---<----! Label Mapping >>> ! / ! >>> ! / ! >>> ! / ! >>> ! / ! >>> ! / ! >>> !<-------/ ! >>> ! ! >>> Label Release !---->---\ ! >>> ! \ ! >>> ! \ ! <-- ROUTE CHANGE >>> ! \ ! >>> ! \ /---<----! Label Mapping (update) >>> ! X ! >>> ! / \------->! >>> ! / ! >>> ! / ! >>> ! / ! >>> !<-------/ ! >>> ! ! >>> >>> >>> The Label Release is initiated by the upstream router. It is not a >>> response >>> to a Label Withdraw. For example, the upstream router might send >>> the Label >>> Release because it is using conservative retention. >>> >>> The downstream router sends the 2nd Label Mapping before receiving >>> the Label >>> Release. For example, a route change might cause the downstream >>> router to >>> signaling a change of hop count or a change of MTU. >>> >>> At the end of this sequence the downstream router has sent two Label >>> Mappings and received a Label Release, so it considers the label to be >>> released. The upstream router has sent a Label Release and received a >>> subsequent Label Mapping, so it considers the label to be valid. In >>> most >>> cases the upstream router would send another Label Release, but if >>> the route >>> has changed then the upstream router might install the label for >>> forwarding/switching use. If so then any data sent using the label >>> will be >>> dropped by the downstream router. This isn't a transient condition, >>> it can >>> continue indefinitely. >>> >>> >>> > > >> Not if the downstream router sends a label withdraw as an appropriate >> recovery response to getting a packet with a label that is invalid. >> > But there may be a problem if the downstream router allocates the same > label > for a different FEC (may be for a different protocol like RSVP) > > Regards, > > Rama > >>> As I said, the likelihood of this happening is low. I believe >>> typical LDP >>> usage would avoid this problem by avoiding loop detection, MTU >>> signaling >>> etc. Nevertheless, RFC 3036 allows such usage, describes hop count >>> behaviour that can lead to the problem, and fails to mention or >>> prevent the >>> problem. >>> >>> Is that clearer? >>> >>> Nick. >>> >>> >>> >>>> -----Original Message----- >>>> From: Ina Minei [mailto:ina@juniper.net] >>>> Sent: 07 October 2004 16:31 >>>> To: Nick Weeds >>>> Cc: mpls@ietf.org (E-mail) >>>> Subject: RE: [mpls] For your review - Issues/errors/clarifications in >>>> RFC3 036 >>>> >>>> >>>> >>>> Nick, >>>> >>>> I think I am missing something... The label release is sent by >>>> router B in response to a label withdraw it received from router A. >>>> A should wait for the release before attempting to send a label map >>>> again. In the meantime, the label is considered dead on A, and >>>> if A wants to resurrect it, A should wait until receiving the release. >>>> >>>> Are you suggesting that A can resurrect the label it just killed >>>> before waiting for the release to come? >>>> >>>> Thank you, >>>> >>>> Ina >>>> >>>> On Thu, 7 Oct 2004, Nick Weeds wrote: >>>> >>>> >>>> >>>>> Ina, >>>>> >>>>> Just a couple of points on the update to RFC 3036... >>>>> >>>>> First, the list of issues not addressed says that RFC 3036 >>>> >>>> already says that >>>> >>>> >>>>> loop detection should not be used in DU mode. I can't find >>>> >>>> this statement >>>> >>>> >>>>> in RFC 3036. Which section is it in? >>>>> >>>>> Second, the LDP protocol can fail if a Label Mapping >>>> >>>> crosses with a Label >>>> >>>> >>>>> Release. >>>>> This was raised by Kishore Tiruveedhula >>>> >>>> [tiruveedhula@avici.com] on 25th >>>> >>>> >>>>> August in connection with loop detection, but it is a more >>>> >>>> general problem >>>> >>>> >>>>> with the protocol. >>>>> >>>>> The problem arises with the following sequence: >>>>> (1) Router D sends a Label Mapping >>>>> (2) Router U sends a Label Release >>>>> (3) Independently router D sends an updated Label Mapping >>>> >>>> (same FEC and >>>> >>>> >>>>> label, different details). >>>>> >>>>> If messages (2) and (3) cross in transit then the label mapping is >>>>> programmed on U (on receipt of the updated Label Mapping) >>>> >>>> but released on D >>>> >>>> >>>>> (on receipt of the Label Release). Any data sent using the >>>> >>>> label will be >>>> >>>> >>>>> lost. >>>>> >>>>> The problem can occur whenever the downstream router sends >>>> >>>> a Label Mapping >>>> >>>> >>>>> message to update an existing mapping. This is probably unusual in >>>>> practice, but RFC 3036 allows it and indeed describes it >>>> >>>> for hop count >>>> >>>> >>>>> changes when using independent control (see Kishore's >>>> >>>> email). From a quick >>>> >>>> >>>>> check, the MTU signaling extension >>>>> (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to >>>> >>>> require Label >>>> >>>> >>>>> Mapping updates. I am not aware of other examples, but the >>>> >>>> problem is a >>>> >>>> >>>>> potential trap for any LDP protocol extension. >>>>> >>>>> It is unclear how to proceed on this, as potential fixes >>>> >>>> are likely to >>>> >>>> >>>>> require protocol changes. Perhaps it would be sufficient >>>> >>>> to explain the >>>> >>>> >>>>> problem and suggest how to avoid it. >>>>> >>>>> (This problem was drawn to my attention in discussions of >>>> >>>> C-bit negotiation >>>> >>>> >>>>> in draft-ietf-pwe3-control-protocol-xx.txt. This >>>> >>>> negotiation takes care to >>>> >>>> >>>>> avoid Label Release messages in response to Label Withdraw >>>> >>>> "Wrong C-bit". >>>> >>>> >>>>> The protocol problem in RFC 3036 was suggested as one >>>> >>>> reason for suppressing >>>> >>>> >>>>> the Label Release, but there are probably other reasons too.) >>>>> >>>>> Nick. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@lists.ietf.org >>>>>> [mailto:mpls-bounces@lists.ietf.org]On >>>>>> Behalf Of Ina Minei >>>>>> Sent: 27 September 2004 19:31 >>>>>> To: mpls@ietf.org >>>>>> Subject: [mpls] For your review - Issues/errors/clarifications in >>>>>> RFC3036 >>>>>> >>>>>> >>>>>> >>>>>> As part of the effort to move RFC3036 to draft >>>>> >>>> standard, here is an >>>> >>>> >>>>>> annotated version of RFC3036, with the changes enclosed by ###. >>>>>> There is a separate section summarizing all changes towards >>>>>> the end of the >>>>>> document. >>>>>> >>>>>> Please review the changes and send comments to the >>>>> >>>> list by October >>>> >>>> >>>>>> 11th. >>>>>> >>>>>> At the end of this mail is a list of issues that were >>>>> >>>> raised but >>>> >>>> >>>>>> were not included in the annotated RFC (with an explanation of >>>>>> why). >>>>>> >>>>>> Please review both the RFC changes and the list of issues not >>>>>> included. Also let me know if I forgot to include any other issues >>>>>> that were raised on the list. >>>>>> >>>>>> Many thanks to all who contributed, and in particular >>>>> >>>> to Bob Thomas >>>> >>>> >>>>>> for maintaining an extensive list of errors/issues over the years. >>>>>> >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Ina >>>>>> >>>>>> >>>>>> Issues that were raised but not included in the annotated RFC >>>>>> ============================================================= >>>>>> >>>>>> - Issue: discussion on the merits/drawbacks of >>>>> >>>> independent-control and >>>> >>>> >>>>>> ordered-control >>>>>> - Issue: discussion on which FECs should be advertised >>>>>> Reason why not included: The above two issues are either for the >>>>>> applicability doc or for the "experiences with the >>>>> >>>> protocol" document. >>>> >>>> >>>>>> - Issue: minor optimization: if A is a stub node, i.e., >>>>> >>>> only one LDP >>>> >>>> >>>>>> session, does it really have to send a label mapping for >>>>>> every FEC that >>>>>> it has, or can it do it lazily, e.g., when it has a second >>>>>> LDP session? >>>>>> Reason why not included : It is not clear what problem >>>>> >>>> this change in >>>> >>>> >>>>>> behavior brings, and what would be the added benefit,the >>>>> >>>> issue must >>>> >>>> >>>>>> be discussed on the list first. >>>>>> >>>>>> - Issue: the ldp loop detection mechanisms don't make sense in DU. >>>>>> We should add something explicitly that >>>>>> says that these TLVs should not be used in DU mode. ( This is the >>>>>> current practice in all implementations that I know of ) >>>>>> Why not included: RFC 3036 already states this in the section >>>>>> describing these TLVs, when it talks about the usage of the TLVs. >>>>>> >>>>>> - Issue: the rfc should specifically say that a wildcard release >>>>>> message should be sent only in response to a wildcard >>>>>> withdraw message. >>>>>> Reason not included: it is covered in the rules in the appendix. >>>>>> >>>>>> - There is a long list of issues that was added to the "for future >>>>>> study" area of the RFC. The list is quite long, we could probably >>>>>> remove some of the items. >>>>>> >>>>>> >>>>> >>>> Nick Weeds >>>> Software Developer >>>> Network Protocols Group >>>> Data Connection Ltd >>>> Tel: +44 1244 305200 >>>> Fax: +44 1244 312422 >>>> Email: Nick.Weeds@dataconnection.com >>>> Web: http://www.dataconnection.com >>>> >>>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 01:09:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07946; Fri, 8 Oct 2004 01:09:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnAT-00067o-6W; Fri, 08 Oct 2004 01:19:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmyh-0008FB-5r; Fri, 08 Oct 2004 01:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmwF-0007qZ-FG for mpls@megatron.ietf.org; Fri, 08 Oct 2004 01:05:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07701 for ; Fri, 8 Oct 2004 01:05:06 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFn65-00062J-7l for mpls@ietf.org; Fri, 08 Oct 2004 01:15:17 -0400 Received: from default.mail.com (unknown[195.56.72.35]) by comcast.net (sccrmhc13) with SMTP id <2004100805043101600da2v3e> (Authid: agmalis@comcast.net); Fri, 8 Oct 2004 05:04:33 +0000 Message-Id: <6.1.2.0.2.20041008005659.06a19960@po1.vivacenetworks.com> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Oct 2004 01:04:26 -0400 To: mpls@ietf.org From: "Andrew G. Malis" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rcheruku@cisco.com Subject: [mpls] Liaison from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 This email was originally sent by a non-list member and is being held up pending approval. To get it out quickly to the list, I'm resending it on behalf of Rao Cherukuri, rcheruku@cisco.com. Dear George, Loa, and Ina: A recent message on the MPLS WG mailing list (http://www.cell-relay.com/mhonarc/mpls/2004-Sep/msg00043.html) has suggested changes to RFC 3036 ("LDP Specification") and called for comments on the proposed changes. One of the proposed changes is to deprecate the use of the Host Address FEC TLV. Two Implementation Agreements published by the MPLS & Frame Relay Alliance (MFA), "MPLS Proxy Admission Control Definition" and "MPLS Proxy Admission Control Protocol", MFA.6.0.0 and MFA.7.0.0 (http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pdf and http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf) make use of the Host Address FEC TLV. MPLS Proxy Admission Control provides a bandwidth-based reservation/admission facility for MPLS networks. There are implementations of this protocol in progress. While the proposed changes make a Prefix FEC TLV with a 32-bit mask equivalent to a Host Address FEC TLV, adopting the Prefix FEC TLV would require changes to approved and published MFA documents, and changes to the implementations. Also, since MPLS Proxy Admission Control only uses host addresses, using the Prefix FEC TLV would necessitate an additional check that the prefix was always 32 bits. Therefore, the MFA kindly requests that the Host Address FEC TLV not be deprecated, and that it continues to be supported in future revisions of LDP. In RFC 3036, there is a semantic difference between a Host Address and a prefix with length 32. The new version proposes to remove the semantic difference. This is not a problem for the MPLS Proxy Admission Control; we are just requesting that the Host Address codepoint not be deprecated. Please advise us as soon as possible about the decision on this issue. Cordially, Rao Cherukuri MPLS & Frame Relay Alliance Technical Committee Chair _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 01:34:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09716; Fri, 8 Oct 2004 01:34:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnYo-0006X2-9J; Fri, 08 Oct 2004 01:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnN7-0004HG-VV; Fri, 08 Oct 2004 01:32:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnL0-0003oy-B2 for mpls@megatron.ietf.org; Fri, 08 Oct 2004 01:30:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09530 for ; Fri, 8 Oct 2004 01:30:41 -0400 (EDT) Received: from host19.ipowerweb.com ([66.235.218.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnUr-0006Sd-6R for mpls@ietf.org; Fri, 08 Oct 2004 01:40:53 -0400 Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.61.197.198] helo=[127.0.0.1]) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 1CFnKQ-00055N-00; Thu, 07 Oct 2004 22:30:07 -0700 Message-ID: <416625D7.9090804@GraIyMage.com> Date: Fri, 08 Oct 2004 01:29:59 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Andrew G. Malis" Subject: Re: [mpls] Liaison from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions References: <6.1.2.0.2.20041008005659.06a19960@po1.vivacenetworks.com> In-Reply-To: <6.1.2.0.2.20041008005659.06a19960@po1.vivacenetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - GraIyMage.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, rcheruku@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Andy, This liaison makes it seem as if there are implementations out in the world that depend on the use of the Host Address FEC. Do you know if that is the case? If so, where were the vendors that implement it when the question was asked earlier? Or is this a case of a "paper-dependency" where the real implementations actually use the 32 bit prefix FEC? -- Eric Andrew G. Malis wrote: > This email was originally sent by a non-list member and is being held up > pending approval. To get it out quickly to the list, I'm resending it on > behalf of Rao Cherukuri, rcheruku@cisco.com. > > Dear George, Loa, and Ina: > > A recent message on the MPLS WG mailing list > (http://www.cell-relay.com/mhonarc/mpls/2004-Sep/msg00043.html) has > suggested changes to RFC 3036 ("LDP Specification") and called for > comments > on the proposed changes. One of the proposed changes is to deprecate the > use of the Host Address FEC TLV. Two Implementation Agreements > published by > the MPLS & Frame Relay Alliance (MFA), "MPLS Proxy Admission Control > Definition" and "MPLS Proxy Admission Control Protocol", MFA.6.0.0 and > MFA.7.0.0 > (http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pdf > and > http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf) > > make use of the Host Address FEC TLV. MPLS Proxy Admission Control > provides > a bandwidth-based reservation/admission facility for MPLS networks. > There > are implementations of this protocol in progress. > > While the proposed changes make a Prefix FEC TLV with a 32-bit mask > equivalent to a Host Address FEC TLV, adopting the Prefix FEC TLV would > require changes to approved and published MFA documents, and changes > to the > implementations. Also, since MPLS Proxy Admission Control only uses host > addresses, using the Prefix FEC TLV would necessitate an additional check > that the prefix was always 32 bits. Therefore, the MFA kindly > requests that > the Host Address FEC TLV not be deprecated, and that it continues to be > supported in future revisions of LDP. > > In RFC 3036, there is a semantic difference between a Host Address and a > prefix with length 32. The new version proposes to remove the semantic > difference. This is not a problem for the MPLS Proxy Admission > Control; we > are just requesting that the Host Address codepoint not be deprecated. > > Please advise us as soon as possible about the decision on this issue. > > Cordially, > Rao Cherukuri > MPLS & Frame Relay Alliance > Technical Committee Chair > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 01:51:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10694; Fri, 8 Oct 2004 01:51:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnpC-0006p5-Lr; Fri, 08 Oct 2004 02:01:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFndf-000785-Pq; Fri, 08 Oct 2004 01:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnaO-0006Wh-NI for mpls@megatron.ietf.org; Fri, 08 Oct 2004 01:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10338 for ; Fri, 8 Oct 2004 01:46:36 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnkF-0006gL-MG for mpls@ietf.org; Fri, 08 Oct 2004 01:56:48 -0400 Received: from default.mail.com (unknown[195.56.72.35]) by comcast.net (rwcrmhc11) with SMTP id <2004100805460301300d9rhge> (Authid: agmalis@comcast.net); Fri, 8 Oct 2004 05:46:04 +0000 Message-Id: <6.1.2.0.2.20041008014400.034d9520@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Oct 2004 01:46:00 -0400 To: ewgray@GraIyMage.com From: "Andrew G. Malis" Subject: Re: [mpls] Liaison from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions In-Reply-To: <416625D7.9090804@GraIyMage.com> References: <6.1.2.0.2.20041008005659.06a19960@po1.vivacenetworks.com> <416625D7.9090804@GraIyMage.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mpls@ietf.org, rcheruku@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Eric, We recently completed work on the spec, and implementations are in progress. So it's a timing thing mostly. If the question is asked again in a few months, there will be implementations to report on. It's not a paper dependency - the spec uses the Host Address FEC as currently specified. Cheers, Andy ----------- At 10/8/2004 01:29 AM -0400, Eric Gray wrote: >Andy, > > This liaison makes it seem as if there are implementations out in the > world >that depend on the use of the Host Address FEC. Do you know if that is the >case? If so, where were the vendors that implement it when the question was >asked earlier? > > Or is this a case of a "paper-dependency" where the real implementations >actually use the 32 bit prefix FEC? > >-- >Eric > >Andrew G. Malis wrote: > >>This email was originally sent by a non-list member and is being held up >>pending approval. To get it out quickly to the list, I'm resending it on >>behalf of Rao Cherukuri, rcheruku@cisco.com. >> >>Dear George, Loa, and Ina: >> >>A recent message on the MPLS WG mailing list >>(http://www.cell-relay.com/mhonarc/mpls/2004-Sep/msg00043.html) has >>suggested changes to RFC 3036 ("LDP Specification") and called for comments >>on the proposed changes. One of the proposed changes is to deprecate the >>use of the Host Address FEC TLV. Two Implementation Agreements published by >>the MPLS & Frame Relay Alliance (MFA), "MPLS Proxy Admission Control >>Definition" and "MPLS Proxy Admission Control Protocol", MFA.6.0.0 and >>MFA.7.0.0 >>(http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pdf >>and >> > >> http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf) >>make use of the Host Address FEC TLV. MPLS Proxy Admission Control provides >>a bandwidth-based reservation/admission facility for MPLS networks. >>There >>are implementations of this protocol in progress. >> >>While the proposed changes make a Prefix FEC TLV with a 32-bit mask >>equivalent to a Host Address FEC TLV, adopting the Prefix FEC TLV would >>require changes to approved and published MFA documents, and changes to the >>implementations. Also, since MPLS Proxy Admission Control only uses host >>addresses, using the Prefix FEC TLV would necessitate an additional check >>that the prefix was always 32 bits. Therefore, the MFA kindly requests that >>the Host Address FEC TLV not be deprecated, and that it continues to be >>supported in future revisions of LDP. >> >>In RFC 3036, there is a semantic difference between a Host Address and a >>prefix with length 32. The new version proposes to remove the semantic >>difference. This is not a problem for the MPLS Proxy Admission Control; we >>are just requesting that the Host Address codepoint not be deprecated. >> >>Please advise us as soon as possible about the decision on this issue. >> >>Cordially, >>Rao Cherukuri >>MPLS & Frame Relay Alliance >>Technical Committee Chair >> >> >>_______________________________________________ >>mpls mailing list >>mpls@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 06:07:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09398; Fri, 8 Oct 2004 06:07:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFroT-0002v5-P7; Fri, 08 Oct 2004 06:17:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFrcN-0001bg-VD; Fri, 08 Oct 2004 06:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFrcC-0001UJ-F7 for mpls@megatron.ietf.org; Fri, 08 Oct 2004 06:04:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09230 for ; Fri, 8 Oct 2004 06:04:42 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFrm5-0002rx-6D for mpls@ietf.org; Fri, 08 Oct 2004 06:14:58 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 8 Oct 2004 11:05:10 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 11:05:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Fri, 8 Oct 2004 11:05:09 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F12E8@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Thread-Index: AcSsx14s9gp7B99oTx+fssHyzqJ8kAAVVl1Q To: , X-OriginalArrivalTime: 08 Oct 2004 10:05:09.0642 (UTC) FILETIME=[4B416EA0:01C4AD1E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Eric, =20 > Not if the downstream router sends a label withdraw as an appropriate > recovery response to getting a packet with a label that is invalid. Is there not a possibility that packets might end up at the wrong destination for other (defect) reasons? And in such a case sending a label withdraw seems the wrong action...comments? regards, Neil _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 06:24:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10970; Fri, 8 Oct 2004 06:24:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFs5N-0003G0-6h; Fri, 08 Oct 2004 06:34:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFrtm-000620-Lt; Fri, 08 Oct 2004 06:22:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFrs3-0005nL-1e for mpls@megatron.ietf.org; Fri, 08 Oct 2004 06:21:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10722 for ; Fri, 8 Oct 2004 06:21:05 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFs1v-0003B3-Te for mpls@ietf.org; Fri, 08 Oct 2004 06:31:21 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i98AH2r17843 for ; Fri, 8 Oct 2004 12:17:02 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Fri, 08 Oct 2004 12:19:14 +0200 Message-ID: <41666995.80002@pi.se> Date: Fri, 08 Oct 2004 12:19:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: neil.2.harrison@bt.com Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <0536FC9B908BEC4597EE721BE6A353890A9F12E8@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F12E8@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ewgray@GraIyMage.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Neil, are you talking about packets exchange over the TCP connection between two LDP peers, or (labeled) packets in genral? /Loa neil.2.harrison@bt.com wrote: > Eric, > > > >>Not if the downstream router sends a label withdraw as an appropriate >>recovery response to getting a packet with a label that is invalid. > > > Is there not a possibility that packets might end up at the wrong > destination for other (defect) reasons? And in such a case sending a > label withdraw seems the wrong action...comments? > > regards, Neil > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 06:29:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11282; Fri, 8 Oct 2004 06:29:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsAV-0003KG-B7; Fri, 08 Oct 2004 06:40:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFryu-0006lZ-NS; Fri, 08 Oct 2004 06:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFrvz-0006J6-M7 for mpls@megatron.ietf.org; Fri, 08 Oct 2004 06:25:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10991 for ; Fri, 8 Oct 2004 06:25:09 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFs5t-0003G4-JE for mpls@ietf.org; Fri, 08 Oct 2004 06:35:26 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 8 Oct 2004 11:25:38 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 11:25:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Fri, 8 Oct 2004 11:25:37 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Thread-Index: AcStIKXWERRKdkGiTHK0fZIA7bfPvAAAHVvA To: X-OriginalArrivalTime: 08 Oct 2004 10:25:38.0190 (UTC) FILETIME=[2786FAE0:01C4AD21] X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, ewgray@GraIyMage.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Loa, I was meaning in general, ie labelled pkts. Just want to check nothing is being overlooked here. regards, Neil > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se]=20 > Sent: 08 October 2004 11:19 > To: Harrison,N,Neil,IKR2 R > Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com; mpls@ietf.org > Subject: Re: [mpls] For your review -=20 > Issues/errors/clarifications in RFC3 036 >=20 >=20 > Neil, >=20 > are you talking about packets exchange over the TCP=20 > connection between two LDP peers, or (labeled) packets in genral? >=20 > /Loa >=20 > neil.2.harrison@bt.com wrote: > > Eric, > > > > =20 > >=20 > >>Not if the downstream router sends a label withdraw as an=20 > appropriate=20 > >>recovery response to getting a packet with a label that is invalid. > >=20 > >=20 > > Is there not a possibility that packets might end up at the wrong=20 > > destination for other (defect) reasons? And in such a case=20 > sending a=20 > > label withdraw seems the wrong action...comments? > >=20 > > regards, Neil > >=20 > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > >=20 > >=20 >=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@acreo.se > loa@pi.se >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 06:41:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12165; Fri, 8 Oct 2004 06:41:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsLu-0003Th-TA; Fri, 08 Oct 2004 06:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFs7J-0008H2-Mg; Fri, 08 Oct 2004 06:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFs5u-000832-NV for mpls@megatron.ietf.org; Fri, 08 Oct 2004 06:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11911 for ; Fri, 8 Oct 2004 06:35:24 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsFn-0003P9-Jh for mpls@ietf.org; Fri, 08 Oct 2004 06:45:41 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i98AVSr18067 for ; Fri, 8 Oct 2004 12:31:28 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Fri, 08 Oct 2004 12:33:19 +0200 Message-ID: <41666CE2.8040309@pi.se> Date: Fri, 08 Oct 2004 12:33:06 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: neil.2.harrison@bt.com Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ewgray@GraIyMage.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Neil, guess that tht is a fair question, it should be looked into, but I guess that it is out of scope for an update of the LDP spec. (I didn't say "implemenation specific :) ). For communication between LDP peers it is my take that we can trust TCP, after all that was one of the reasons chosing TCP. Now, if the protocol exchange information in a correct manner, but one implementation creates a label mapping that is errornous, this is not something we can address in the protocol specification, is it? /Loa neil.2.harrison@bt.com wrote: > Loa, > > I was meaning in general, ie labelled pkts. Just want to check nothing > is being overlooked here. > > regards, Neil > > >>-----Original Message----- >>From: Loa Andersson [mailto:loa@pi.se] >>Sent: 08 October 2004 11:19 >>To: Harrison,N,Neil,IKR2 R >>Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com; mpls@ietf.org >>Subject: Re: [mpls] For your review - >>Issues/errors/clarifications in RFC3 036 >> >> >>Neil, >> >>are you talking about packets exchange over the TCP >>connection between two LDP peers, or (labeled) packets in genral? >> >>/Loa >> >>neil.2.harrison@bt.com wrote: >> >>>Eric, >>> >>> >>> >>> >>>>Not if the downstream router sends a label withdraw as an >> >>appropriate >> >>>>recovery response to getting a packet with a label that is invalid. >>> >>> >>>Is there not a possibility that packets might end up at the wrong >>>destination for other (defect) reasons? And in such a case >> >>sending a >> >>>label withdraw seems the wrong action...comments? >>> >>>regards, Neil >>> >>> >>>_______________________________________________ >>>mpls mailing list >>>mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >>> >>> >> >>-- >>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 >> > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 07:04:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14173; Fri, 8 Oct 2004 07:04:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFshU-0003xs-Lt; Fri, 08 Oct 2004 07:14:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsWN-0004bY-7H; Fri, 08 Oct 2004 07:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsQX-0003JJ-5a for mpls@megatron.ietf.org; Fri, 08 Oct 2004 06:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13448 for ; Fri, 8 Oct 2004 06:56:42 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsaP-0003mi-QQ for mpls@ietf.org; Fri, 08 Oct 2004 07:06:59 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 8 Oct 2004 11:57:04 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 11:57:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Date: Fri, 8 Oct 2004 11:57:03 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F12EC@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] For your review - Issues/errors/clarifications in RFC3 036 Thread-Index: AcStIqkMBM574I/VRLmNB8nuQnLI3wAAXyzw To: X-OriginalArrivalTime: 08 Oct 2004 10:57:04.0027 (UTC) FILETIME=[8B92DEB0:01C4AD25] X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, ewgray@GraIyMage.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Thanks Loa, I think there are 2 separate issues here: - whether the LDP signalling protocol has the right exception handling; - how *any* control-plane protocols should behave in the face of data-plane defects.....and in general it is not a good idea to take actions in the control-plane unless the nature of the defect is understood 1st in the data-plane. That is why I asked the question about issuing a withdraw on getting unexpected labelled pkts. Thanks.....regards, Neil > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se]=20 > Sent: 08 October 2004 11:33 > To: Harrison,N,Neil,IKR2 R > Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com; mpls@ietf.org > Subject: Re: [mpls] For your review -=20 > Issues/errors/clarifications in RFC3 036 >=20 >=20 > Neil, >=20 > guess that tht is a fair question, it should be looked into,=20 > but I guess that it is out of scope for an update of the LDP=20 > spec. (I didn't say "implemenation specific :) ). For=20 > communication between LDP peers it is my take that we can=20 > trust TCP, after all that was one of the reasons chosing TCP. >=20 > Now, if the protocol exchange information in a correct > manner, but one implementation creates a label mapping > that is errornous, this is not something we can address > in the protocol specification, is it? >=20 > /Loa >=20 > neil.2.harrison@bt.com wrote: >=20 > > Loa, > >=20 > > I was meaning in general, ie labelled pkts. Just want to check=20 > > nothing is being overlooked here. > >=20 > > regards, Neil > >=20 > >=20 > >>-----Original Message----- > >>From: Loa Andersson [mailto:loa@pi.se] > >>Sent: 08 October 2004 11:19 > >>To: Harrison,N,Neil,IKR2 R > >>Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com;=20 > mpls@ietf.org > >>Subject: Re: [mpls] For your review -=20 > >>Issues/errors/clarifications in RFC3 036 > >> > >> > >>Neil, > >> > >>are you talking about packets exchange over the TCP > >>connection between two LDP peers, or (labeled) packets in genral? > >> > >>/Loa > >> > >>neil.2.harrison@bt.com wrote: > >> > >>>Eric, > >>> > >>>=20 > >>> > >>> > >>>>Not if the downstream router sends a label withdraw as an > >> > >>appropriate > >> > >>>>recovery response to getting a packet with a label that=20 > is invalid. > >>> > >>> > >>>Is there not a possibility that packets might end up at the wrong > >>>destination for other (defect) reasons? And in such a case=20 > >> > >>sending a > >> > >>>label withdraw seems the wrong action...comments? > >>> > >>>regards, Neil > >>> > >>> > >>>_______________________________________________ > >>>mpls mailing list > >>>mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > >>> > >>> > >> > >>-- > >>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 > >> > >=20 > >=20 > >=20 >=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@acreo.se > loa@pi.se >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 09:20:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22138; Fri, 8 Oct 2004 09:20:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFupK-0006Qr-D9; Fri, 08 Oct 2004 09:30:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFuc8-0007Vg-Pm; Fri, 08 Oct 2004 09:16:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFuUR-0006ZN-F0 for mpls@megatron.ietf.org; Fri, 08 Oct 2004 09:08:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21481 for ; Fri, 8 Oct 2004 09:08:54 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFueM-0006Dl-J4 for mpls@ietf.org; Fri, 08 Oct 2004 09:19:10 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <4HNQPXWL>; Fri, 8 Oct 2004 14:08:20 +0100 Message-ID: <16E71652255A3E4796A7AF3A9E5068F90304B8@blakey.datcon.co.uk> From: Nick Weeds To: "'Luca Martini'" Date: Fri, 8 Oct 2004 14:07:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "mpls@ietf.org \(E-mail\)" Subject: [mpls] Generalized ID PW information length and interface parameters X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Luca, I spotted a glitch in draft-ietf-pwe3-control-protocol-11.txt... Section 5.2.2 includes the sentences: The PW information length field, contains the length of the SAII, TAII, AGI combined, and the interface parameters field in octets. This is misleading, as the Generalized ID FEC element no longer contains interface parameters. There is another erroneous reference to interface parameters later in the same paragraph. Sorry I didn't spot it earlier, Nick. > Nick Weeds > Software Developer > Network Protocols Group > Data Connection Ltd > Tel: +44 1244 305200 > Fax: +44 1244 312422 > Email: Nick.Weeds@dataconnection.com > Web: http://www.dataconnection.com > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 10:32:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29205; Fri, 8 Oct 2004 10:32:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvwq-00084o-GL; Fri, 08 Oct 2004 10:42:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvhc-0002YR-59; Fri, 08 Oct 2004 10:26:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvRN-0002w0-VI for mpls@megatron.ietf.org; Fri, 08 Oct 2004 10:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26073 for ; Fri, 8 Oct 2004 10:09:49 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvbC-0007MC-7U for mpls@ietf.org; Fri, 08 Oct 2004 10:20:06 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i98E9ccq026941 for ; Fri, 8 Oct 2004 07:09:38 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i98E9Kot026283 for ; Fri, 8 Oct 2004 09:09:21 -0500 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 8 Oct 2004 19:39:35 +0530 Message-ID: <653138C25D8AD6118292000347080A370B478DA2@zin05exm02.corp.mot.com> From: Dillikar Satyanarayana-G19471 To: "'LE ROUX Jean-Louis RD-CORE-LAN'" , mpls@ietf.org, mpls-ops@mplsrc.com Subject: RE: RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarifi cationneeded. Date: Fri, 8 Oct 2004 19:39:29 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ops.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Hi JL, Thanks for your explanation. As the hardware data-plane branch = capability is not known to CSPF Path-Computation-Engine(PCE). PCE only = has to rely on E-bit and B-bit of the nodes. PCE computing trees T1 and T2 based on given R3 bit status. Please = tell us which tree is valid and which tree is not valid and why? =20 Tree T1: Ingress =3D R1 Egresses =3D R2,R3 =20 R1 | R2--R3 =20 R3(E=3D1, B=3D0) Tree T2: Ingress =3D R1 Egresses =3D R2,R3 =20 R1 | R2--R3 =20 R3(E=3D1, B=3D1) TIA, Satya=20 > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of LE ROUX=20 > Jean-Louis RD-CORE-LAN > Sent: Friday, October 08, 2004 3:57 AM > To: Satyanarayana Dillikar; mpls@ietf.org; mpls-ops@mplsrc.com > Cc: ccamp@ops.ietf.org > Subject: RE : [mpls]=20 > draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. >=20 >=20 > Hi Dillikar, >=20 > Sorry for this delayed answer. > Thanks for these useful comments, that will help clarifying=20 > this spec. Please see inline. Regards, >=20 > JL >=20 > PS: I'm copying ccamp >=20 > >-----Message d'origine----- > >De : mpls-bounces@lists.ietf.org > >[mailto:mpls-bounces@lists.ietf.org] De la part de=20 > >Satyanarayana Dillikar > >Envoy=E9 : mercredi 6 octobre 2004 10:38 > >=C0 : mpls@ietf.org; mpls-ops@mplsrc.com > >Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20 > >clarificationneeded. > > > > > >Hi, > > We have some confusion in understanding the Data > >Plane Capability Flags (B-bit & E-bit) from > >draft-vasseur-ccamp-te-router-info-00.txt > > > >(a) Does E-bit ON implies B-bit ON always ? (assuming > >ON =3D set and OFF =3D unset). >=20 > Basically bud (transit + Egress) capability requires some=20 > branching in the data plane so in general E ON will imply B=20 > ON, but note that these capabilities does not necessarily=20 > reflect real hardware capabilities as they may be=20 > activated/deactivated by the operator for various reasons. We=20 > will clarify this point in next revision. >=20 >=20 > >(b) E-bit =3D ON & B-bit =3D OFF, is it a valid > >combination. >=20 > Yes see above, there may be cases where the operator want to=20 > deactivate branch capability on a node (He does't want that=20 > the node act as a branch LSR), even if its data plane is=20 > physically branch capable, but he allows the node to act as a=20 > bud-LSR (transit + egress). This gives more operational flexibility. >=20 > >(c) Please tell us the E-bit and B-bit status for a > >node which is a destination node but does not have > >branch capability. >=20 > If its data plane is not branch capable then it will also=20 > probably not be bud capable so=20 > E =3D 0 and B =3D 0 >=20 > In return, if its data plane is branch capable but branch LSR=20 > capability has been deactivated by configuration and bud-LSR=20 > capability is activated, then E =3D 1 and B =3D 0 >=20 > > > > > >We are also curious to know > >(1)The idea behind combing two things (egress status & > >transit status) in a single E-bit. rather than making > >use of B-bit(branch) and having E-bit just for egress > >status. >=20 > Remind that these capabilities are used for tree computation=20 > purpose, and the egress is an entry=20 > of the computation. So, IMHO it does't really make any sense=20 > to advertise egress capability only.=20 >=20 > >(2) Why the TE Node Capability Descriptor TLV should > >have E-bit & how it should be used in CSPF path > >computation. >=20 > This allows advertising if an LSR can be transit and egress.=20 > This is particulary useful for steiner tree topologies.=20 > See the following example:=20 > Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4 >=20 > R1 > | > R2--R3---R4 >=20 > Such tree can be setup only if R3 has Egress + Transit capability. >=20 >=20 > Regards, >=20 > JL >=20 >=20 >=20 > > > >Thanks > >Satya > > > > > > =09 > >_______________________________ > >Do you Yahoo!? > >Declare Yourself - Register online to vote today!=20 http://vote.yahoo.com > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 13:57:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16074; Fri, 8 Oct 2004 13:57:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzA1-0004U7-Ft; Fri, 08 Oct 2004 14:08:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFyuH-0002Fs-MS; Fri, 08 Oct 2004 13:51:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFytN-0001wx-Mc for mpls@megatron.ietf.org; Fri, 08 Oct 2004 13:50:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15404 for ; Fri, 8 Oct 2004 13:50:55 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFz3G-0004Hm-SR for mpls@ietf.org; Fri, 08 Oct 2004 14:01:14 -0400 Received: from elmo.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA22429; Fri, 8 Oct 2004 10:50:19 -0700 (PDT) Received: from riverstonenet.com (localhost [127.0.0.1]) by elmo.riverstonenet.com (8.11.6+Sun/8.11.6) with ESMTP id i98Hk8w05161; Fri, 8 Oct 2004 10:46:08 -0700 (PDT) Message-ID: <4166D25F.3040101@riverstonenet.com> Date: Fri, 08 Oct 2004 10:46:07 -0700 From: Rama Ramakrishnan User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ewgray@GraIyMage.com Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> <4165D0A3.2090101@netscape.net> <4165D629.1070406@riverstonenet.com> <416611AA.8020407@GraIyMage.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 876202f9cbc0933cffbc58102e40f8f2 Content-Transfer-Encoding: 7bit Eric Gray wrote: > Rama, > > Yes, Bob Thomas and I talked about this problem _years_ ago (:-)) > > Bob seemed to feel that there are several way that an implementation > can avoid re-issuing the same label too soon after it "becomes available". > Since he and I were both working on separate LDP implementations at > the time, I couldn't really find a hole in that argument. Therefore, > this is a > "race" condition where you can hobble the competition. > > One other comment in response - the protocol that issues a label should > be irrelevant in the sense that you're addressing. Either the multiple > signaling > protocols are getting the labels from the same pool or they're not. If > they're > not, the problem does not exist. If they are, then a sensible > implementation > would benefit from using a common under-lying label allocation scheme. One clarification. The reason I mentioned RSVP is just to stress the point that the old label is currently used for a different purpose. Regards, Rama > > -- > Eric > > Rama Ramakrishnan wrote: > >> >> >> Eric Gray wrote: >> >>> Nick, >>> >>> Thanks for filling in the details. Please see one comment below. >>> >>> Nick Weeds wrote: >>> >>>> Ina, >>>> >>>> Sorry I didn't explain this clearly. >>>> >>>> The problem arises in window cases where the upstream (U,B) and >>>> downstream >>>> (D,A) routers happen to send LDP messages at the same time. The >>>> likelihood of this is low, but it >>>> is possible. >>>> >>>> ! ! >>>> ! /---<----! Label Mapping >>>> ! / ! >>>> ! / ! >>>> ! / ! >>>> ! / ! >>>> ! / ! >>>> !<-------/ ! >>>> ! ! >>>> Label Release !---->---\ ! >>>> ! \ ! >>>> ! \ ! <-- ROUTE CHANGE >>>> ! \ ! >>>> ! \ /---<----! Label Mapping (update) >>>> ! X ! >>>> ! / \------->! >>>> ! / ! >>>> ! / ! >>>> ! / ! >>>> !<-------/ ! >>>> ! ! >>>> >>>> >>>> The Label Release is initiated by the upstream router. It is not a >>>> response >>>> to a Label Withdraw. For example, the upstream router might send >>>> the Label >>>> Release because it is using conservative retention. >>>> >>>> The downstream router sends the 2nd Label Mapping before receiving >>>> the Label >>>> Release. For example, a route change might cause the downstream >>>> router to >>>> signaling a change of hop count or a change of MTU. >>>> >>>> At the end of this sequence the downstream router has sent two Label >>>> Mappings and received a Label Release, so it considers the label to be >>>> released. The upstream router has sent a Label Release and received a >>>> subsequent Label Mapping, so it considers the label to be valid. In >>>> most >>>> cases the upstream router would send another Label Release, but if >>>> the route >>>> has changed then the upstream router might install the label for >>>> forwarding/switching use. If so then any data sent using the label >>>> will be >>>> dropped by the downstream router. This isn't a transient condition, >>>> it can >>>> continue indefinitely. >>>> >>>> >>>> >> >> >>> Not if the downstream router sends a label withdraw as an appropriate >>> recovery response to getting a packet with a label that is invalid. >>> >> But there may be a problem if the downstream router allocates the same >> label >> for a different FEC (may be for a different protocol like RSVP) >> >> Regards, >> >> Rama >> >>>> As I said, the likelihood of this happening is low. I believe >>>> typical LDP >>>> usage would avoid this problem by avoiding loop detection, MTU >>>> signaling >>>> etc. Nevertheless, RFC 3036 allows such usage, describes hop count >>>> behaviour that can lead to the problem, and fails to mention or >>>> prevent the >>>> problem. >>>> >>>> Is that clearer? >>>> >>>> Nick. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ina Minei [mailto:ina@juniper.net] >>>>> Sent: 07 October 2004 16:31 >>>>> To: Nick Weeds >>>>> Cc: mpls@ietf.org (E-mail) >>>>> Subject: RE: [mpls] For your review - Issues/errors/clarifications in >>>>> RFC3 036 >>>>> >>>>> >>>>> >>>>> Nick, >>>>> >>>>> I think I am missing something... The label release is sent by >>>>> router B in response to a label withdraw it received from router A. >>>>> A should wait for the release before attempting to send a label map >>>>> again. In the meantime, the label is considered dead on A, and >>>>> if A wants to resurrect it, A should wait until receiving the release. >>>>> >>>>> Are you suggesting that A can resurrect the label it just killed >>>>> before waiting for the release to come? >>>>> >>>>> Thank you, >>>>> >>>>> Ina >>>>> >>>>> On Thu, 7 Oct 2004, Nick Weeds wrote: >>>>> >>>>> >>>>> >>>>>> Ina, >>>>>> >>>>>> Just a couple of points on the update to RFC 3036... >>>>>> >>>>>> First, the list of issues not addressed says that RFC 3036 >>>>> >>>>> >>>>> already says that >>>>> >>>>> >>>>>> loop detection should not be used in DU mode. I can't find >>>>> >>>>> >>>>> this statement >>>>> >>>>> >>>>>> in RFC 3036. Which section is it in? >>>>>> >>>>>> Second, the LDP protocol can fail if a Label Mapping >>>>> >>>>> >>>>> crosses with a Label >>>>> >>>>> >>>>>> Release. >>>>>> This was raised by Kishore Tiruveedhula >>>>> >>>>> >>>>> [tiruveedhula@avici.com] on 25th >>>>> >>>>> >>>>>> August in connection with loop detection, but it is a more >>>>> >>>>> >>>>> general problem >>>>> >>>>> >>>>>> with the protocol. >>>>>> >>>>>> The problem arises with the following sequence: >>>>>> (1) Router D sends a Label Mapping >>>>>> (2) Router U sends a Label Release >>>>>> (3) Independently router D sends an updated Label Mapping >>>>> >>>>> >>>>> (same FEC and >>>>> >>>>> >>>>>> label, different details). >>>>>> >>>>>> If messages (2) and (3) cross in transit then the label mapping is >>>>>> programmed on U (on receipt of the updated Label Mapping) >>>>> >>>>> >>>>> but released on D >>>>> >>>>> >>>>>> (on receipt of the Label Release). Any data sent using the >>>>> >>>>> >>>>> label will be >>>>> >>>>> >>>>>> lost. >>>>>> >>>>>> The problem can occur whenever the downstream router sends >>>>> >>>>> >>>>> a Label Mapping >>>>> >>>>> >>>>>> message to update an existing mapping. This is probably unusual in >>>>>> practice, but RFC 3036 allows it and indeed describes it >>>>> >>>>> >>>>> for hop count >>>>> >>>>> >>>>>> changes when using independent control (see Kishore's >>>>> >>>>> >>>>> email). From a quick >>>>> >>>>> >>>>>> check, the MTU signaling extension >>>>>> (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to >>>>> >>>>> >>>>> require Label >>>>> >>>>> >>>>>> Mapping updates. I am not aware of other examples, but the >>>>> >>>>> >>>>> problem is a >>>>> >>>>> >>>>>> potential trap for any LDP protocol extension. >>>>>> >>>>>> It is unclear how to proceed on this, as potential fixes >>>>> >>>>> >>>>> are likely to >>>>> >>>>> >>>>>> require protocol changes. Perhaps it would be sufficient >>>>> >>>>> >>>>> to explain the >>>>> >>>>> >>>>>> problem and suggest how to avoid it. >>>>>> >>>>>> (This problem was drawn to my attention in discussions of >>>>> >>>>> >>>>> C-bit negotiation >>>>> >>>>> >>>>>> in draft-ietf-pwe3-control-protocol-xx.txt. This >>>>> >>>>> >>>>> negotiation takes care to >>>>> >>>>> >>>>>> avoid Label Release messages in response to Label Withdraw >>>>> >>>>> >>>>> "Wrong C-bit". >>>>> >>>>> >>>>>> The protocol problem in RFC 3036 was suggested as one >>>>> >>>>> >>>>> reason for suppressing >>>>> >>>>> >>>>>> the Label Release, but there are probably other reasons too.) >>>>>> >>>>>> Nick. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpls-bounces@lists.ietf.org >>>>>>> [mailto:mpls-bounces@lists.ietf.org]On >>>>>>> Behalf Of Ina Minei >>>>>>> Sent: 27 September 2004 19:31 >>>>>>> To: mpls@ietf.org >>>>>>> Subject: [mpls] For your review - Issues/errors/clarifications in >>>>>>> RFC3036 >>>>>>> >>>>>>> >>>>>>> >>>>>>> As part of the effort to move RFC3036 to draft >>>>>> >>>>>> >>>>> standard, here is an >>>>> >>>>> >>>>>>> annotated version of RFC3036, with the changes enclosed by ###. >>>>>>> There is a separate section summarizing all changes towards >>>>>>> the end of the >>>>>>> document. >>>>>>> >>>>>>> Please review the changes and send comments to the >>>>>> >>>>>> >>>>> list by October >>>>> >>>>> >>>>>>> 11th. >>>>>>> >>>>>>> At the end of this mail is a list of issues that were >>>>>> >>>>>> >>>>> raised but >>>>> >>>>> >>>>>>> were not included in the annotated RFC (with an explanation of >>>>>>> why). >>>>>>> >>>>>>> Please review both the RFC changes and the list of issues not >>>>>>> included. Also let me know if I forgot to include any other issues >>>>>>> that were raised on the list. >>>>>>> >>>>>>> Many thanks to all who contributed, and in particular >>>>>> >>>>>> >>>>> to Bob Thomas >>>>> >>>>> >>>>>>> for maintaining an extensive list of errors/issues over the years. >>>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Ina >>>>>>> >>>>>>> >>>>>>> Issues that were raised but not included in the annotated RFC >>>>>>> ============================================================= >>>>>>> >>>>>>> - Issue: discussion on the merits/drawbacks of >>>>>> >>>>>> >>>>> independent-control and >>>>> >>>>> >>>>>>> ordered-control >>>>>>> - Issue: discussion on which FECs should be advertised >>>>>>> Reason why not included: The above two issues are either for the >>>>>>> applicability doc or for the "experiences with the >>>>>> >>>>>> >>>>> protocol" document. >>>>> >>>>> >>>>>>> - Issue: minor optimization: if A is a stub node, i.e., >>>>>> >>>>>> >>>>> only one LDP >>>>> >>>>> >>>>>>> session, does it really have to send a label mapping for >>>>>>> every FEC that >>>>>>> it has, or can it do it lazily, e.g., when it has a second >>>>>>> LDP session? >>>>>>> Reason why not included : It is not clear what problem >>>>>> >>>>>> >>>>> this change in >>>>> >>>>> >>>>>>> behavior brings, and what would be the added benefit,the >>>>>> >>>>>> >>>>> issue must >>>>> >>>>> >>>>>>> be discussed on the list first. >>>>>>> >>>>>>> - Issue: the ldp loop detection mechanisms don't make sense in DU. >>>>>>> We should add something explicitly that >>>>>>> says that these TLVs should not be used in DU mode. ( This is the >>>>>>> current practice in all implementations that I know of ) >>>>>>> Why not included: RFC 3036 already states this in the section >>>>>>> describing these TLVs, when it talks about the usage of the TLVs. >>>>>>> >>>>>>> - Issue: the rfc should specifically say that a wildcard release >>>>>>> message should be sent only in response to a wildcard >>>>>>> withdraw message. >>>>>>> Reason not included: it is covered in the rules in the appendix. >>>>>>> >>>>>>> - There is a long list of issues that was added to the "for future >>>>>>> study" area of the RFC. The list is quite long, we could probably >>>>>>> remove some of the items. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> Nick Weeds >>>>> Software Developer >>>>> Network Protocols Group >>>>> Data Connection Ltd >>>>> Tel: +44 1244 305200 >>>>> Fax: +44 1244 312422 >>>>> Email: Nick.Weeds@dataconnection.com >>>>> Web: http://www.dataconnection.com >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/mpls >> >> >> >> >> >> >> >> > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 8 17:36:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19695; Fri, 8 Oct 2004 17:36:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2ZX-0005V7-EZ; Fri, 08 Oct 2004 17:46:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2Eq-0007q0-8r; Fri, 08 Oct 2004 17:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG1wJ-0007X0-An; Fri, 08 Oct 2004 17:06:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16100; Fri, 8 Oct 2004 17:06:09 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG26I-0004OV-AI; Fri, 08 Oct 2004 17:16:30 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Oct 2004 17:05:40 -0400 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i98L5aED015523; Fri, 8 Oct 2004 17:05:36 -0400 (EDT) From: "Zafar Ali" To: Date: Fri, 8 Oct 2004 17:05:35 -0400 Message-ID: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: ccamp@ops.ietf.org, mpls@ietf.org, jpv@cisco.com Subject: [mpls] Path Computation Element (PCE) Architecture and mailing list, X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1875866990==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c This is a multi-part message in MIME format. --===============1875866990== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4AD59.08795340" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4AD59.08795340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Jerry, JP, et al,=20 =20 Thanks for putting the PCE Architecture document (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), = I found it very useful in scoping PCE WG and applicability of PCE in MPLS/ GMPLS TE networks. In the following I have a few questions/ comments = about this ID.=20 =20 I would also like to request about what would be a tentative agenda for = PCE BOF Part II in DC? I think the discussion in SD went very well in favor = of PCE WG, pending this architecture ID. What is the present plan of = record?=20 =20 - What did you meant by "the level of robustness of the path resources", = in PCC-PCE communication? I am expecting that the client can also specify = an exclude list, include list (this is in addition of SRLG to include/ exclude). =20 =20 - Can you please elaborate more on advantages of Stateful PCE and what = are the pits fall of using Stateful PCE in a distributed PCE environment. = You have information about Out-of-band TED synchronization but I am thinking there is some complexity involved in such mechanism and stateful PCE in = a distributed PCE setup. More description on the applicability of Stateful = PCE & Out-of-band TED synchronization would be useful to better scope core = vs.. advanced features of PCE.=20 =20 - When PCE is distributed, are there any considerations in path = computation (minimum guidelines, like constraints based shortest path based on the specified optimization criteria, optimization criteria does not change = for the same setup when multiple PCE are involved in path computation, etc.) = to make Path Computations in a distributed PCE scheme, that you think we = need to add to the text of this document.=20 =20 - When a number of disjoint paths are required, we need a mechanism to specify if near disjoint Paths are acceptable (but this is need not to = be in architecture doc). =20 =20 The rest of the document look very good to me.=20 =20 Regards... Zafar =20 ------=_NextPart_000_0008_01C4AD59.08795340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi = Adrian, Jerry,=20 JP, et al,
 
Thanks for=20 putting the PCE Architecture document (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.t= xt),=20 I found it very useful in scoping PCE WG and applicability of PCE in = MPLS/ GMPLS=20 TE networks. In the following I have a few questions/ comments = about this=20 ID.
 
I = would also like to=20 request about what would be a tentative agenda for PCE BOF Part II in = DC? I=20 think the discussion in SD went very well in favor of PCE WG, pending = this=20 architecture ID. What is the present plan of record? =
 
- What = did you meant=20 by "the level of robustness of the path resources", in PCC-PCE = communication? I=20 am expecting that the client can also specify an exclude list, include = list=20 (this is in addition of SRLG to include/ exclude).=20  
 
- Can = you please=20 elaborate more on advantages of Stateful PCE and what are the pits fall = of using=20 Stateful PCE in a distributed PCE environment. You have information = about=20 Out-of-band TED synchronization but I am thinking there is some = complexity=20 involved in such mechanism and stateful PCE in a distributed PCE setup. = More=20 description on the applicability of Stateful PCE & Out-of-band TED=20 synchronization would be useful to better scope core vs.. advanced = features of=20 PCE.
 
- When = PCE is=20 distributed, are there any considerations in path computation (minimum=20 guidelines, like constraints based shortest path based on the specified=20 optimization criteria, optimization criteria does not change for the = same setup=20 when multiple PCE are involved in path computation, etc.) to make Path=20 Computations in a distributed PCE scheme, that you think we need to add = to the=20 text of this document.
 
- When = a number of=20 disjoint paths are required, we need a mechanism to specify if near = disjoint Paths are acceptable (but this is need not to be in = architecture=20 doc).  
 
The = rest of the=20 document look very good to me.
 
Regards... = Zafar
 
------=_NextPart_000_0008_01C4AD59.08795340-- --===============1875866990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1875866990==-- From mpls-bounces@ietf.org Fri Oct 8 18:16:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23964; Fri, 8 Oct 2004 18:16:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3CU-0006Sw-HO; Fri, 08 Oct 2004 18:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2vE-0001Nq-Vx; Fri, 08 Oct 2004 18:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2sX-0007Tm-Q4 for mpls@megatron.ietf.org; Fri, 08 Oct 2004 18:06:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22396 for ; Fri, 8 Oct 2004 18:06:19 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG32X-0006Co-1Q for mpls@ietf.org; Fri, 08 Oct 2004 18:16:41 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.8.) id p.1b7.c154ff4 (16240); Fri, 8 Oct 2004 18:05:36 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in03.mx.aol.com (v101_r1.4) with ESMTP id MAILININ34-3f7041670f2f8e; Fri, 08 Oct 2004 18:05:36 -0400 Message-ID: <41670F28.7020603@netscape.net> Date: Fri, 08 Oct 2004 18:05:28 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: neil.2.harrison@bt.com Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net> X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 1.0 (+) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@graiymage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1147855317==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac --===============1147855317== Content-Type: multipart/alternative; boundary="------------060508070803010000080102" --------------060508070803010000080102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Neil, What you ask should only be a concern if an implementation is either sloppy in allocating labels or not particularly careful about re-allocating them. There is a "window of opportunity" if an implementation re-issues labels on a time scale similar to expected packet inter-arrival time for traffic using that label (either before or after the re-issue). There is also a window of opportunity if the same label is somehow issued in two separate contexts and the LSR is not able to correctly recover context when it subsequently receives ambiguously labeled packets. The first window is avoidable by a robust implementation. The second window only exists for a broken implementation. This is the reason why I feel we are making a big deal out of nothing very much. :-) -- Eric neil.2.harrison@bt.com wrote: >Loa, > >I was meaning in general, ie labelled pkts. Just want to check nothing >is being overlooked here. > >regards, Neil > > > >>-----Original Message----- >>From: Loa Andersson [mailto:loa@pi.se] >>Sent: 08 October 2004 11:19 >>To: Harrison,N,Neil,IKR2 R >>Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com; mpls@ietf.org >>Subject: Re: [mpls] For your review - >>Issues/errors/clarifications in RFC3 036 >> >> >>Neil, >> >>are you talking about packets exchange over the TCP >>connection between two LDP peers, or (labeled) packets in genral? >> >>/Loa >> >>neil.2.harrison@bt.com wrote: >> >> >>>Eric, >>> >>> >>> >>> >>> >>>>Not if the downstream router sends a label withdraw as an >>>> >>>> >>appropriate >> >> >>>>recovery response to getting a packet with a label that is invalid. >>>> >>>> >>>Is there not a possibility that packets might end up at the wrong >>>destination for other (defect) reasons? And in such a case >>> >>> >>sending a >> >> >>>label withdraw seems the wrong action...comments? >>> >>>regards, Neil >>> >>> >>>_______________________________________________ >>>mpls mailing list >>>mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> >>-- >>Loa Andersson >> >>Principal Networking Architect >>Acreo AB phone: +46 8 632 77 14 >>Isafjordsgatan 22 mobile: +46 739 81 21 64 >>Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.se >> >> >> > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > --------------060508070803010000080102 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Neil,

    What you ask should only be a concern if an implementation is either
sloppy in allocating labels or not particularly careful about re-allocating
them.

    There is a "window of opportunity" if an implementation re-issues labels
on a time scale similar to expected packet inter-arrival time for traffic using
that label (either before or after the re-issue). There is also a window of
opportunity if the same label is somehow issued in two separate contexts
and the LSR is not able to correctly recover context when it subsequently
receives  ambiguously labeled packets.

    The first window is avoidable by a robust implementation. The second
window only exists for a broken implementation.

    This is the reason why I feel we are making a big deal out of nothing
very much.

    :-)

--
Eric

neil.2.harrison@bt.com wrote:
Loa,

I was meaning in general, ie labelled pkts.  Just want to check nothing
is being overlooked here.

regards, Neil

  
-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se] 
Sent: 08 October 2004 11:19
To: Harrison,N,Neil,IKR2 R
Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com; mpls@ietf.org
Subject: Re: [mpls] For your review - 
Issues/errors/clarifications in RFC3 036


Neil,

are you talking about packets exchange over the TCP 
connection between two LDP peers, or (labeled) packets in genral?

/Loa

neil.2.harrison@bt.com wrote:
    
Eric,
<Snipped>
 

      
Not if the downstream router sends a label withdraw as an 
        
appropriate 
    
recovery response to getting a packet with a label that is invalid.
        
Is there not a possibility that packets might end up at the wrong 
destination for other (defect) reasons?  And in such a case 
      
sending a 
    
label withdraw seems the wrong action...comments?

regards, Neil


_______________________________________________
mpls mailing list
mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls


      
-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                            loa@pi.se

    

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------060508070803010000080102-- --===============1147855317== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1147855317==-- From mpls-bounces@ietf.org Fri Oct 8 18:45:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26107; Fri, 8 Oct 2004 18:45:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3eP-0006xL-Uv; Fri, 08 Oct 2004 18:55:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3N1-0005wW-4q; Fri, 08 Oct 2004 18:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3Hz-0004he-8r for mpls@megatron.ietf.org; Fri, 08 Oct 2004 18:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25464 for ; Fri, 8 Oct 2004 18:32:36 -0400 (EDT) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3Rz-0006l7-7y for mpls@ietf.org; Fri, 08 Oct 2004 18:42:59 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r3.8.) id h.1b3.c22a9ae (16240); Fri, 8 Oct 2004 18:31:47 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in03.mx.aol.com (v101_r1.4) with ESMTP id MAILININ34-3f7041671552290; Fri, 08 Oct 2004 18:31:46 -0400 Message-ID: <4167154B.3050605@netscape.net> Date: Fri, 08 Oct 2004 18:31:39 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Rama Ramakrishnan Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036 References: <16E71652255A3E4796A7AF3A9E5068F90304AB@blakey.datcon.co.uk> <4165D0A3.2090101@netscape.net> <4165D629.1070406@riverstonenet.com> <416611AA.8020407@GraIyMage.com> <4166D25F.3040101@riverstonenet.com> In-Reply-To: <4166D25F.3040101@riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b21264b25b2584da3ddf2bd579ca48f Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org \(E-mail\)" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@graiymage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 Content-Transfer-Encoding: 7bit Rama, Actually, it is still used for the same purpose - to decide how to forward packets. It is just associated with a different decision. My point is that it is not impossible (or even hard) to avoid the problem we are blasting away at. -- Eric Rama Ramakrishnan wrote: > > > Eric Gray wrote: > >> Rama, >> >> Yes, Bob Thomas and I talked about this problem _years_ ago (:-)) >> >> Bob seemed to feel that there are several way that an implementation >> can avoid re-issuing the same label too soon after it "becomes >> available". >> Since he and I were both working on separate LDP implementations at >> the time, I couldn't really find a hole in that argument. Therefore, >> this is a >> "race" condition where you can hobble the competition. >> > > > > >> One other comment in response - the protocol that issues a label >> should >> be irrelevant in the sense that you're addressing. Either the >> multiple signaling >> protocols are getting the labels from the same pool or they're not. >> If they're >> not, the problem does not exist. If they are, then a sensible >> implementation >> would benefit from using a common under-lying label allocation scheme. > > > One clarification. The reason I mentioned RSVP is just to stress the > point > that the old label is currently used for a different purpose. > > Regards, > > Rama > >> >> -- >> Eric >> >> Rama Ramakrishnan wrote: >> >>> >>> >>> Eric Gray wrote: >>> >>>> Nick, >>>> >>>> Thanks for filling in the details. Please see one comment below. >>>> >>>> Nick Weeds wrote: >>>> >>>>> Ina, >>>>> >>>>> Sorry I didn't explain this clearly. >>>>> >>>>> The problem arises in window cases where the upstream (U,B) and >>>>> downstream >>>>> (D,A) routers happen to send LDP messages at the same time. The >>>>> likelihood of this is low, but it >>>>> is possible. >>>>> >>>>> ! ! >>>>> ! /---<----! Label Mapping >>>>> ! / ! >>>>> ! / ! >>>>> ! / ! >>>>> ! / ! >>>>> ! / ! >>>>> !<-------/ ! >>>>> ! ! >>>>> Label Release !---->---\ ! >>>>> ! \ ! >>>>> ! \ ! <-- ROUTE CHANGE >>>>> ! \ ! >>>>> ! \ /---<----! Label Mapping (update) >>>>> ! X ! >>>>> ! / \------->! >>>>> ! / ! >>>>> ! / ! >>>>> ! / ! >>>>> !<-------/ ! >>>>> ! ! >>>>> >>>>> >>>>> The Label Release is initiated by the upstream router. It is not >>>>> a response >>>>> to a Label Withdraw. For example, the upstream router might send >>>>> the Label >>>>> Release because it is using conservative retention. >>>>> >>>>> The downstream router sends the 2nd Label Mapping before receiving >>>>> the Label >>>>> Release. For example, a route change might cause the downstream >>>>> router to >>>>> signaling a change of hop count or a change of MTU. >>>>> >>>>> At the end of this sequence the downstream router has sent two Label >>>>> Mappings and received a Label Release, so it considers the label >>>>> to be >>>>> released. The upstream router has sent a Label Release and >>>>> received a >>>>> subsequent Label Mapping, so it considers the label to be valid. >>>>> In most >>>>> cases the upstream router would send another Label Release, but if >>>>> the route >>>>> has changed then the upstream router might install the label for >>>>> forwarding/switching use. If so then any data sent using the >>>>> label will be >>>>> dropped by the downstream router. This isn't a transient >>>>> condition, it can >>>>> continue indefinitely. >>>>> >>>>> >>>>> >>> >>> >>>> Not if the downstream router sends a label withdraw as an appropriate >>>> recovery response to getting a packet with a label that is invalid. >>>> >>> But there may be a problem if the downstream router allocates the >>> same label >>> for a different FEC (may be for a different protocol like RSVP) >>> >>> Regards, >>> >>> Rama >>> >>>>> As I said, the likelihood of this happening is low. I believe >>>>> typical LDP >>>>> usage would avoid this problem by avoiding loop detection, MTU >>>>> signaling >>>>> etc. Nevertheless, RFC 3036 allows such usage, describes hop count >>>>> behaviour that can lead to the problem, and fails to mention or >>>>> prevent the >>>>> problem. >>>>> >>>>> Is that clearer? >>>>> >>>>> Nick. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ina Minei [mailto:ina@juniper.net] >>>>>> Sent: 07 October 2004 16:31 >>>>>> To: Nick Weeds >>>>>> Cc: mpls@ietf.org (E-mail) >>>>>> Subject: RE: [mpls] For your review - >>>>>> Issues/errors/clarifications in >>>>>> RFC3 036 >>>>>> >>>>>> >>>>>> >>>>>> Nick, >>>>>> >>>>>> I think I am missing something... The label release is sent by >>>>>> router B in response to a label withdraw it received from router A. >>>>>> A should wait for the release before attempting to send a label map >>>>>> again. In the meantime, the label is considered dead on A, and >>>>>> if A wants to resurrect it, A should wait until receiving the >>>>>> release. >>>>>> >>>>>> Are you suggesting that A can resurrect the label it just killed >>>>>> before waiting for the release to come? >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Ina >>>>>> >>>>>> On Thu, 7 Oct 2004, Nick Weeds wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Ina, >>>>>>> >>>>>>> Just a couple of points on the update to RFC 3036... >>>>>>> >>>>>>> First, the list of issues not addressed says that RFC 3036 >>>>>> >>>>>> >>>>>> >>>>>> already says that >>>>>> >>>>>> >>>>>>> loop detection should not be used in DU mode. I can't find >>>>>> >>>>>> >>>>>> >>>>>> this statement >>>>>> >>>>>> >>>>>>> in RFC 3036. Which section is it in? >>>>>>> >>>>>>> Second, the LDP protocol can fail if a Label Mapping >>>>>> >>>>>> >>>>>> >>>>>> crosses with a Label >>>>>> >>>>>> >>>>>>> Release. >>>>>>> This was raised by Kishore Tiruveedhula >>>>>> >>>>>> >>>>>> >>>>>> [tiruveedhula@avici.com] on 25th >>>>>> >>>>>> >>>>>>> August in connection with loop detection, but it is a more >>>>>> >>>>>> >>>>>> >>>>>> general problem >>>>>> >>>>>> >>>>>>> with the protocol. >>>>>>> >>>>>>> The problem arises with the following sequence: >>>>>>> (1) Router D sends a Label Mapping >>>>>>> (2) Router U sends a Label Release >>>>>>> (3) Independently router D sends an updated Label Mapping >>>>>> >>>>>> >>>>>> >>>>>> (same FEC and >>>>>> >>>>>> >>>>>>> label, different details). >>>>>>> >>>>>>> If messages (2) and (3) cross in transit then the label mapping is >>>>>>> programmed on U (on receipt of the updated Label Mapping) >>>>>> >>>>>> >>>>>> >>>>>> but released on D >>>>>> >>>>>> >>>>>>> (on receipt of the Label Release). Any data sent using the >>>>>> >>>>>> >>>>>> >>>>>> label will be >>>>>> >>>>>> >>>>>>> lost. >>>>>>> >>>>>>> The problem can occur whenever the downstream router sends >>>>>> >>>>>> >>>>>> >>>>>> a Label Mapping >>>>>> >>>>>> >>>>>>> message to update an existing mapping. This is probably unusual in >>>>>>> practice, but RFC 3036 allows it and indeed describes it >>>>>> >>>>>> >>>>>> >>>>>> for hop count >>>>>> >>>>>> >>>>>>> changes when using independent control (see Kishore's >>>>>> >>>>>> >>>>>> >>>>>> email). From a quick >>>>>> >>>>>> >>>>>>> check, the MTU signaling extension >>>>>>> (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to >>>>>> >>>>>> >>>>>> >>>>>> require Label >>>>>> >>>>>> >>>>>>> Mapping updates. I am not aware of other examples, but the >>>>>> >>>>>> >>>>>> >>>>>> problem is a >>>>>> >>>>>> >>>>>>> potential trap for any LDP protocol extension. >>>>>>> >>>>>>> It is unclear how to proceed on this, as potential fixes >>>>>> >>>>>> >>>>>> >>>>>> are likely to >>>>>> >>>>>> >>>>>>> require protocol changes. Perhaps it would be sufficient >>>>>> >>>>>> >>>>>> >>>>>> to explain the >>>>>> >>>>>> >>>>>>> problem and suggest how to avoid it. >>>>>>> >>>>>>> (This problem was drawn to my attention in discussions of >>>>>> >>>>>> >>>>>> >>>>>> C-bit negotiation >>>>>> >>>>>> >>>>>>> in draft-ietf-pwe3-control-protocol-xx.txt. This >>>>>> >>>>>> >>>>>> >>>>>> negotiation takes care to >>>>>> >>>>>> >>>>>>> avoid Label Release messages in response to Label Withdraw >>>>>> >>>>>> >>>>>> >>>>>> "Wrong C-bit". >>>>>> >>>>>> >>>>>>> The protocol problem in RFC 3036 was suggested as one >>>>>> >>>>>> >>>>>> >>>>>> reason for suppressing >>>>>> >>>>>> >>>>>>> the Label Release, but there are probably other reasons too.) >>>>>>> >>>>>>> Nick. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mpls-bounces@lists.ietf.org >>>>>>>> [mailto:mpls-bounces@lists.ietf.org]On >>>>>>>> Behalf Of Ina Minei >>>>>>>> Sent: 27 September 2004 19:31 >>>>>>>> To: mpls@ietf.org >>>>>>>> Subject: [mpls] For your review - Issues/errors/clarifications in >>>>>>>> RFC3036 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As part of the effort to move RFC3036 to draft >>>>>>> >>>>>>> >>>>>>> >>>>>> standard, here is an >>>>>> >>>>>> >>>>>>>> annotated version of RFC3036, with the changes enclosed by ###. >>>>>>>> There is a separate section summarizing all changes towards >>>>>>>> the end of the >>>>>>>> document. >>>>>>>> >>>>>>>> Please review the changes and send comments to the >>>>>>> >>>>>>> >>>>>>> >>>>>> list by October >>>>>> >>>>>> >>>>>>>> 11th. >>>>>>>> >>>>>>>> At the end of this mail is a list of issues that were >>>>>>> >>>>>>> >>>>>>> >>>>>> raised but >>>>>> >>>>>> >>>>>>>> were not included in the annotated RFC (with an explanation of >>>>>>>> why). >>>>>>>> >>>>>>>> Please review both the RFC changes and the list of issues not >>>>>>>> included. Also let me know if I forgot to include any other issues >>>>>>>> that were raised on the list. >>>>>>>> >>>>>>>> Many thanks to all who contributed, and in particular >>>>>>> >>>>>>> >>>>>>> >>>>>> to Bob Thomas >>>>>> >>>>>> >>>>>>>> for maintaining an extensive list of errors/issues over the years. >>>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> Ina >>>>>>>> >>>>>>>> >>>>>>>> Issues that were raised but not included in the annotated RFC >>>>>>>> ============================================================= >>>>>>>> >>>>>>>> - Issue: discussion on the merits/drawbacks of >>>>>>> >>>>>>> >>>>>>> >>>>>> independent-control and >>>>>> >>>>>> >>>>>>>> ordered-control >>>>>>>> - Issue: discussion on which FECs should be advertised >>>>>>>> Reason why not included: The above two issues are either for the >>>>>>>> applicability doc or for the "experiences with the >>>>>>> >>>>>>> >>>>>>> >>>>>> protocol" document. >>>>>> >>>>>> >>>>>>>> - Issue: minor optimization: if A is a stub node, i.e., >>>>>>> >>>>>>> >>>>>>> >>>>>> only one LDP >>>>>> >>>>>> >>>>>>>> session, does it really have to send a label mapping for >>>>>>>> every FEC that >>>>>>>> it has, or can it do it lazily, e.g., when it has a second >>>>>>>> LDP session? >>>>>>>> Reason why not included : It is not clear what problem >>>>>>> >>>>>>> >>>>>>> >>>>>> this change in >>>>>> >>>>>> >>>>>>>> behavior brings, and what would be the added benefit,the >>>>>>> >>>>>>> >>>>>>> >>>>>> issue must >>>>>> >>>>>> >>>>>>>> be discussed on the list first. >>>>>>>> >>>>>>>> - Issue: the ldp loop detection mechanisms don't make sense in DU. >>>>>>>> We should add something explicitly that >>>>>>>> says that these TLVs should not be used in DU mode. ( This is the >>>>>>>> current practice in all implementations that I know of ) >>>>>>>> Why not included: RFC 3036 already states this in the section >>>>>>>> describing these TLVs, when it talks about the usage of the TLVs. >>>>>>>> >>>>>>>> - Issue: the rfc should specifically say that a wildcard release >>>>>>>> message should be sent only in response to a wildcard >>>>>>>> withdraw message. >>>>>>>> Reason not included: it is covered in the rules in the appendix. >>>>>>>> >>>>>>>> - There is a long list of issues that was added to the "for future >>>>>>>> study" area of the RFC. The list is quite long, we could probably >>>>>>>> remove some of the items. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Nick Weeds >>>>>> Software Developer >>>>>> Network Protocols Group >>>>>> Data Connection Ltd >>>>>> Tel: +44 1244 305200 >>>>>> Fax: +44 1244 312422 >>>>>> Email: Nick.Weeds@dataconnection.com >>>>>> Web: http://www.dataconnection.com >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Oct 9 07:44:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05640; Sat, 9 Oct 2004 07:44:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGFoX-0004EJ-I3; Sat, 09 Oct 2004 07:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGFcG-0000uP-Az; Sat, 09 Oct 2004 07:42:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGFYJ-0008UI-91 for mpls@megatron.ietf.org; Sat, 09 Oct 2004 07:38:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05362; Sat, 9 Oct 2004 07:38:18 -0400 (EDT) Received: from av1-2-sn1.fre.skanova.net ([81.228.11.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGFiQ-000473-0w; Sat, 09 Oct 2004 07:48:46 -0400 Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id 9B96837E92; Sat, 9 Oct 2004 13:37:41 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id 8CD0037E45; Sat, 9 Oct 2004 13:37:41 +0200 (CEST) Received: from [127.0.0.1] (h60n2fls307o1033.telia.com [81.226.61.60]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 055B637E48; Sat, 9 Oct 2004 13:37:40 +0200 (CEST) Message-ID: <4167CD0F.1040200@pi.se> Date: Sat, 09 Oct 2004 13:35:43 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexa Morris References: <200410071543.i97FhVOE013263@puddle.amsl.com> In-Reply-To: <200410071543.i97FhVOE013263@puddle.amsl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: statements@ietf.org, rcheruku@cisco.com, mpls@ietf.org Subject: [mpls] Re: Liaison from MPLS & Frame Relay Alliance on RFC 3036 Proposed Revisions - place holder response and call for discussion X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Alexa, we have received this liasion and plan to give a more formal response, after consulting the working group. Working group, based on the liasion from MPLS FR Alliance I've asked Ina to leave the Host FEC in an updated version (Internet Draft) of the LDP Specification tht we hope will be published beforre the cut off for the upcoming meeting in Washington. At the same time I would like to initiate a discussion on the proper actions for the LDP protocol. Especially since the previous discussion on removing the Host FEC was pretty much a show of consensus. /Loa Alexa Morris wrote: > This email is being sent on behalf of Rao Cherukuri, rcheruku@cisco.com. > > Dear George, Loa and Ina: > > A recent message on the MPLS WG mailing list > (http://www.cell-relay.com/mhonarc/mpls/2004-Sep/msg00043.html) has > suggested changes to RFC 3036 ("LDP Specification") and called for comments > on the proposed changes. One of the proposed changes is to deprecate the > use of the Host Address FEC TLV. Two Implementation Agreements published by > the MPLS & Frame Relay Alliance (MFA), "MPLS Proxy Admission Control > Definition" and "MPLS Proxy Admission Control Protocol", MFA.6.0.0 and > MFA.7.0.0 > (http://www.mplsforum.org/tech/mpls-proxy-admission-control-definition-ia.pd > f and > http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf) > make use of the Host Address FEC TLV. MPLS Proxy Admission Control provides > a bandwidth-based reservation/admission facility for MPLS networks. There > are implementations of this protocol in progress. > > While the proposed changes make a Prefix FEC TLV with a 32-bit mask > equivalent to a Host Address FEC TLV, adopting the Prefix FEC TLV would > require changes to approved and published MFA documents, and changes to the > implementations. Also, since MPLS Proxy Admission Control only uses host > addresses, using the Prefix FEC TLV would necessitate an additional check > that the prefix was always 32 bits. Therefore, the MFA kindly requests that > the Host Address FEC TLV not be deprecated, and that it continues to be > supported in future revisions of LDP. > > In RFC 3036, there is a semantic difference between a Host Address and a > prefix with length 32. The new version proposes to remove the semantic > difference. This is not a problem for the MPLS Proxy Admission Control; we > are just requesting that the Host Address codepoint not be deprecated. > > Please advise us as soon as possible about the decision on this issue. > > Cordially, > Rao Cherukuri > MPLS & Frame Relay Alliance > Technical Committee Chair > > > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Oct 9 11:04:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18920; Sat, 9 Oct 2004 11:04:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGIwM-0007z0-DV; Sat, 09 Oct 2004 11:15:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGIgL-00077j-EE; Sat, 09 Oct 2004 10:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGIUI-00048C-Gy; Sat, 09 Oct 2004 10:46:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18187; Sat, 9 Oct 2004 10:46:20 -0400 (EDT) From: ibryskin@movaz.com Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGIeO-0007eR-9f; Sat, 09 Oct 2004 10:56:51 -0400 Received: by jera.movaz.com (Postfix, from userid 30) id 487522E76B; Sat, 9 Oct 2004 10:45:47 -0400 (EDT) Received: from 70.177.176.176 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 9 Oct 2004 10:45:47 -0400 (EDT) Message-ID: <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> In-Reply-To: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT) To: "Zafar Ali" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 09 Oct 2004 10:58:48 -0400 Cc: ccamp@ops.ietf.org, pce@ietf.org, Gerald , mpls@ietf.org, jpv@cisco.com, 'Ash@movaz.com Subject: [mpls] Re: Path Computation Element (PCE) Architecture and mailing list, X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 8bit Hi guys, I think this is a vey sound document. I have a suggestion though. It would be extreamely useful if a PCE could advertise its capabilities such as: a) set of constraints that it can account for (diversity, SRLGs, optical impairements, wavelenght continuity, etc.) b) number of switching capability layers (and which); c) number of path selection criterias (and which); d) whether it is a stateless path calculator or can send updates about better paths that might be available in future; e) whether it can compute P2MP trees (and which types); f) whether it can ensure the resource sharing between backup tunnels; g) etc. This information would help a lot for a potential PCC that dynamically learns about PCEs available on the network to decide which of them to use. Igor > Hi Adrian, Jerry, JP, et al, > > Thanks for putting the PCE Architecture document > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I > found it very useful in scoping PCE WG and applicability of PCE in MPLS/ > GMPLS TE networks. In the following I have a few questions/ comments about > this ID. > > I would also like to request about what would be a tentative agenda for > PCE > BOF Part II in DC? I think the discussion in SD went very well in favor of > PCE WG, pending this architecture ID. What is the present plan of record? > > - What did you meant by "the level of robustness of the path resources", > in > PCC-PCE communication? I am expecting that the client can also specify an > exclude list, include list (this is in addition of SRLG to include/ > exclude). > > - Can you please elaborate more on advantages of Stateful PCE and what are > the pits fall of using Stateful PCE in a distributed PCE environment. You > have information about Out-of-band TED synchronization but I am thinking > there is some complexity involved in such mechanism and stateful PCE in a > distributed PCE setup. More description on the applicability of Stateful > PCE > & Out-of-band TED synchronization would be useful to better scope core > vs.. > advanced features of PCE. > > - When PCE is distributed, are there any considerations in path > computation > (minimum guidelines, like constraints based shortest path based on the > specified optimization criteria, optimization criteria does not change for > the same setup when multiple PCE are involved in path computation, etc.) > to > make Path Computations in a distributed PCE scheme, that you think we need > to add to the text of this document. > > - When a number of disjoint paths are required, we need a mechanism to > specify if near disjoint Paths are acceptable (but this is need not to be > in > architecture doc). > > The rest of the document look very good to me. > > Regards... Zafar > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sun Oct 10 06:12:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27985; Sun, 10 Oct 2004 06:12:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGaqz-0004RR-H2; Sun, 10 Oct 2004 06:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGaeQ-0005hc-Jm; Sun, 10 Oct 2004 06:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGad0-0005Sb-Dx for mpls@megatron.ietf.org; Sun, 10 Oct 2004 06:08:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27822 for ; Sun, 10 Oct 2004 06:08:31 -0400 (EDT) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGan9-0004Oc-DF for mpls@ietf.org; Sun, 10 Oct 2004 06:19:13 -0400 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3AE052AA0F; Sun, 10 Oct 2004 10:00:52 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <57B86B3A-1AA4-11D9-ABD4-0003934A79C2@sniff.de> Content-Transfer-Encoding: 7bit From: Marc Binderberger Subject: Re: [mpls] mpls vs IPv6 Date: Sun, 10 Oct 2004 12:08:33 +0200 To: Jung Janos X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hello, > With MPLS I can create MPLS VPNs, QoS can (really?) be > granted to packet flows, and routing is more faster. Forget about the "faster". Today the forwarding happens either in hardware and is wire-speed for IPv4/IPv6 as well. Or it's the same underlying mechanism in software, e.g. the "CEF" table in Cisco routers. QoS for MPLS is in first place the same as for IPv4/IPv6. You have 3 bits, like the (old) IPv4 Precedence. In theory more QoS information could be coded in the label, of course. > IPv6 has the "Flow label" field wich makes routing faster again, the "faster" doesn't matter with today's ASICs in place. > and has less header overhead than ipv4 (or mpls+ipv4) n*4+20 vs. 40 - less overhead? > And i think flow label could have the same use as > the mpls label value... > > How is MPLS to IPv6 related? as already answered: the same as MPLS to IPv4. Well, there is always a difference between theory and implementation. MPLS needs LDP (and RSVP depending on what you do), LDP uses IP UDP and TCP. Although informations within are "TLV" coded and thus expandable I haven't seen any IPv6-based LDP on my Cisco so far. Read: you may have IPv4 to run protocols like LDP to finally run MPLS carrying IPv6 packets. > Are they technologies that have nothing to do with each other? From a generic point of view: correct. > Or MPLS can bring new functionalities to IPv6 networks (like to IPv4), > and > so mpls+ipv6 would have a sense? exactly. Hope I don't start a religious war now but look upon IPv6 as an IPv4 with larger addresses, a more structured approach to "ip options", avoiding fragmentation (on transit routers) and such. In short: more addresses ;-) > And if so, what are the benefits? Same as for IPv4: TE capabilities, allows you to integrate ATM into your IP packet network, [...]. > IPv6 has all what mpls+ipv4 has (separeted flows to support qos > VPNs faster routing) and so mpls would have no further use? Don't see that IPv6 has any VPN support (other than IPSec which IPv4 supports as well). Regards, Marc -- Marc Binderberger Powered by *BSD ;-) _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Oct 11 06:51:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22646; Mon, 11 Oct 2004 06:51:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxwq-0004mA-Lx; Mon, 11 Oct 2004 07:02:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGxkS-0001b0-OQ; Mon, 11 Oct 2004 06:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGxiw-0001Pw-AQ for mpls@megatron.ietf.org; Mon, 11 Oct 2004 06:48:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22457 for ; Mon, 11 Oct 2004 06:48:12 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxtS-0004hm-Km for mpls@ietf.org; Mon, 11 Oct 2004 06:59:07 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 12:46:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Date: Mon, 11 Oct 2004 12:46:52 +0200 Message-ID: Thread-Topic: RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Thread-Index: AcStQHdLaRu4nznXRjqRKZlxAW7KpACPueUw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Dillikar Satyanarayana-G19471" , , X-OriginalArrivalTime: 11 Oct 2004 10:46:53.0626 (UTC) FILETIME=[9EFC51A0:01C4AF7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ops.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Hi Dillikar, E =3D 1, so both trees are valid. Regards, JL >-----Message d'origine----- >De : Dillikar Satyanarayana-G19471 [mailto:satya@motorola.com]=20 >Envoy=E9 : vendredi 8 octobre 2004 16:09 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; mpls@ietf.org; = mpls-ops@mplsrc.com >Cc : ccamp@ops.ietf.org >Objet : RE: RE : [mpls]=20 >draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. > > >Hi JL, > Thanks for your explanation. As the hardware data-plane=20 >branch capability is not known to CSPF=20 >Path-Computation-Engine(PCE). PCE only has to rely on E-bit=20 >and B-bit of the nodes. > PCE computing trees T1 and T2 based on given R3 bit status.=20 >Please tell us which tree is valid and which tree is not=20 >valid and why? >=20 >Tree T1: Ingress =3D R1 Egresses =3D R2,R3 >=20 > R1 > | > R2--R3 >=20 >R3(E=3D1, B=3D0) > > >Tree T2: Ingress =3D R1 Egresses =3D R2,R3 >=20 > R1 > | > R2--R3 >=20 >R3(E=3D1, B=3D1) > >TIA, >Satya=20 > >> -----Original Message----- >> From: mpls-bounces@lists.ietf.org >> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of LE ROUX=20 >> Jean-Louis RD-CORE-LAN >> Sent: Friday, October 08, 2004 3:57 AM >> To: Satyanarayana Dillikar; mpls@ietf.org; mpls-ops@mplsrc.com >> Cc: ccamp@ops.ietf.org >> Subject: RE : [mpls]=20 >> draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. >>=20 >>=20 >> Hi Dillikar, >>=20 >> Sorry for this delayed answer. >> Thanks for these useful comments, that will help clarifying >> this spec. Please see inline. Regards, >>=20 >> JL >>=20 >> PS: I'm copying ccamp >>=20 >> >-----Message d'origine----- >> >De : mpls-bounces@lists.ietf.org=20 >[mailto:mpls-bounces@lists.ietf.org]=20 >> >De la part de Satyanarayana Dillikar >> >Envoy=E9 : mercredi 6 octobre 2004 10:38 >> >=C0 : mpls@ietf.org; mpls-ops@mplsrc.com >> >Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20 >> >clarificationneeded. >> > >> > >> >Hi, >> > We have some confusion in understanding the Data >> >Plane Capability Flags (B-bit & E-bit) from=20 >> >draft-vasseur-ccamp-te-router-info-00.txt >> > >> >(a) Does E-bit ON implies B-bit ON always ? (assuming >> >ON =3D set and OFF =3D unset). >>=20 >> Basically bud (transit + Egress) capability requires some >> branching in the data plane so in general E ON will imply B=20 >> ON, but note that these capabilities does not necessarily=20 >> reflect real hardware capabilities as they may be=20 >> activated/deactivated by the operator for various reasons. We=20 >> will clarify this point in next revision. >>=20 >>=20 >> >(b) E-bit =3D ON & B-bit =3D OFF, is it a valid >> >combination. >>=20 >> Yes see above, there may be cases where the operator want to >> deactivate branch capability on a node (He does't want that=20 >> the node act as a branch LSR), even if its data plane is=20 >> physically branch capable, but he allows the node to act as a=20 >> bud-LSR (transit + egress). This gives more operational flexibility. >>=20 >> >(c) Please tell us the E-bit and B-bit status for a >> >node which is a destination node but does not have >> >branch capability. >>=20 >> If its data plane is not branch capable then it will also >> probably not be bud capable so=20 >> E =3D 0 and B =3D 0 >>=20 >> In return, if its data plane is branch capable but branch LSR >> capability has been deactivated by configuration and bud-LSR=20 >> capability is activated, then E =3D 1 and B =3D 0 >>=20 >> > >> > >> >We are also curious to know >> >(1)The idea behind combing two things (egress status & transit=20 >> >status) in a single E-bit. rather than making use of B-bit(branch)=20 >> >and having E-bit just for egress status. >>=20 >> Remind that these capabilities are used for tree computation >> purpose, and the egress is an entry=20 >> of the computation. So, IMHO it does't really make any sense=20 >> to advertise egress capability only.=20 >>=20 >> >(2) Why the TE Node Capability Descriptor TLV should >> >have E-bit & how it should be used in CSPF path >> >computation. >>=20 >> This allows advertising if an LSR can be transit and egress. >> This is particulary useful for steiner tree topologies.=20 >> See the following example:=20 >> Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4 >>=20 >> R1 >> | >> R2--R3---R4 >>=20 >> Such tree can be setup only if R3 has Egress + Transit capability. >>=20 >>=20 >> Regards, >>=20 >> JL >>=20 >>=20 >>=20 >> > >> >Thanks >> >Satya >> > >> > >> > =09 >> >_______________________________ >> >Do you Yahoo!? >> >Declare Yourself - Register online to vote today! >http://vote.yahoo.com >> >>_______________________________________________ >>mpls mailing list >>mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >> > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Oct 11 20:01:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11944; Mon, 11 Oct 2004 20:01:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAHh-0008SW-JR; Mon, 11 Oct 2004 20:12:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9xD-00024F-Ky; Mon, 11 Oct 2004 19:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9ph-00088N-RI; Mon, 11 Oct 2004 19:44:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11098; Mon, 11 Oct 2004 19:43:58 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHA0K-0008BU-K2; Mon, 11 Oct 2004 19:55:01 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2004 16:52:07 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9BNhQOE011814; Mon, 11 Oct 2004 16:43:27 -0700 (PDT) Received: from [68.184.43.50] (che-vpn-cluster-1-213.cisco.com [10.86.240.213]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA12666; Mon, 11 Oct 2004 16:43:24 -0700 (PDT) In-Reply-To: <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5822B2DE-1BDF-11D9-B106-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 11 Oct 2004 19:43:25 -0400 To: ibryskin@movaz.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org, Gerald , Zafar Ali , jpv@cisco.com, 'Ash@movaz.com Subject: [mpls] Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Hi Igor, On Oct 9, 2004, at 10:45 AM, ibryskin@movaz.com wrote: > Hi guys, > > I think this is a vey sound document. I have a suggestion though. > > It would be extreamely useful if a PCE could advertise its capabilities > such as: > > a) set of constraints that it can account for (diversity, SRLGs, > optical > impairements, wavelenght continuity, etc.) > > b) number of switching capability layers (and which); > > c) number of path selection criterias (and which); > > d) whether it is a stateless path calculator or can send updates about > better paths that might be available in future; > > e) whether it can compute P2MP trees (and which types); > > f) whether it can ensure the resource sharing between backup tunnels; > > g) etc. > > This information would help a lot for a potential PCC that dynamically > learns about PCEs available on the network to decide which of them to > use. > I cannot agree more ! See the two PCE cap related drafts: draft-vasseur-ospf--te-caps (and isis) Such draft would probably ends up being discussed here, should we end up creating a WG. JP. > Igor > > >> Hi Adrian, Jerry, JP, et al, >> >> Thanks for putting the PCE Architecture document >> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture >> -00.txt), I >> found it very useful in scoping PCE WG and applicability of PCE in >> MPLS/ >> GMPLS TE networks. In the following I have a few questions/ comments >> about >> this ID. >> >> I would also like to request about what would be a tentative agenda >> for >> PCE >> BOF Part II in DC? I think the discussion in SD went very well in >> favor of >> PCE WG, pending this architecture ID. What is the present plan of >> record? >> >> - What did you meant by "the level of robustness of the path >> resources", >> in >> PCC-PCE communication? I am expecting that the client can also >> specify an >> exclude list, include list (this is in addition of SRLG to include/ >> exclude). >> >> - Can you please elaborate more on advantages of Stateful PCE and >> what are >> the pits fall of using Stateful PCE in a distributed PCE environment. >> You >> have information about Out-of-band TED synchronization but I am >> thinking >> there is some complexity involved in such mechanism and stateful PCE >> in a >> distributed PCE setup. More description on the applicability of >> Stateful >> PCE >> & Out-of-band TED synchronization would be useful to better scope core >> vs.. >> advanced features of PCE. >> >> - When PCE is distributed, are there any considerations in path >> computation >> (minimum guidelines, like constraints based shortest path based on the >> specified optimization criteria, optimization criteria does not >> change for >> the same setup when multiple PCE are involved in path computation, >> etc.) >> to >> make Path Computations in a distributed PCE scheme, that you think we >> need >> to add to the text of this document. >> >> - When a number of disjoint paths are required, we need a mechanism to >> specify if near disjoint Paths are acceptable (but this is need not >> to be >> in >> architecture doc). >> >> The rest of the document look very good to me. >> >> Regards... Zafar >> >> > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 04:43:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29869; Tue, 12 Oct 2004 04:43:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHIQ6-00005D-5o; Tue, 12 Oct 2004 04:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHI6d-0001eT-Ta; Tue, 12 Oct 2004 04:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHHzc-0008Od-Kh for mpls@megatron.ietf.org; Tue, 12 Oct 2004 04:26:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28731 for ; Tue, 12 Oct 2004 04:26:46 -0400 (EDT) Received: from web60909.mail.yahoo.com ([216.155.196.85]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHIAF-0008FI-MD for mpls@ietf.org; Tue, 12 Oct 2004 04:37:52 -0400 Message-ID: <20041012082612.27006.qmail@web60909.mail.yahoo.com> Received: from [61.16.170.194] by web60909.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 09:26:12 BST Date: Tue, 12 Oct 2004 09:26:12 +0100 (BST) From: Spice Sylvia Subject: Re: [mpls] mpls vs IPv6 To: Marc Binderberger , Jung Janos In-Reply-To: <57B86B3A-1AA4-11D9-ABD4-0003934A79C2@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 8bit May I be bold enough to ask the reason MPLS was ever deployed? some more queries inline.> --- Marc Binderberger wrote: > Hello, > > > With MPLS I can create MPLS VPNs, QoS can > (really?) be > > granted to packet flows, and routing is more > faster. > > Forget about the "faster". Today the forwarding > happens either in > hardware and is wire-speed for IPv4/IPv6 as well. Or > it's the same > underlying mechanism in software, e.g. the "CEF" > table in Cisco > routers. > And how many such end addresses are there? Do we need to throw out the existing gear to move to IPv6? > QoS for MPLS is in first place the same as for > IPv4/IPv6. You have 3 > bits, like the (old) IPv4 Precedence. In theory more > QoS information > could be coded in the label, of course. > > > IPv6 has the "Flow label" field wich makes routing > faster > > again, the "faster" doesn't matter with today's > ASICs in place. > But then tomorrow's ASICs will be faster than today's so why not wait for tomorrow :)) till they are built ?? > > and has less header overhead than ipv4 (or > mpls+ipv4) > > n*4+20 vs. 40 - less overhead? > > > And i think flow label could have the same use as > > the mpls label value... > > > > How is MPLS to IPv6 related? > > as already answered: the same as MPLS to IPv4. > Well, there is always a difference between theory > and implementation. > MPLS needs LDP (and RSVP depending on what you do), > LDP uses IP UDP and > TCP. Although informations within are "TLV" coded > and thus expandable I > haven't seen any IPv6-based LDP on my Cisco so far. > Read: you may have > IPv4 to run protocols like LDP to finally run MPLS > carrying IPv6 > packets. > > > Are they technologies that have nothing to do with > each other? > > From a generic point of view: correct. > > > Or MPLS can bring new functionalities to IPv6 > networks (like to IPv4), > > and > > so mpls+ipv6 would have a sense? > > exactly. Hope I don't start a religious war now but > look upon IPv6 as > an IPv4 with larger addresses, a more structured > approach to "ip > options", avoiding fragmentation (on transit > routers) and such. In > short: more addresses ;-) > > Same as for IPv4: TE capabilities, allows you to > integrate ATM into > your IP packet network, [...]. > But why woould I need ATM then? _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 06:14:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05592; Tue, 12 Oct 2004 06:14:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHJqG-0001cS-Ja; Tue, 12 Oct 2004 06:25:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHJdB-00014I-3F; Tue, 12 Oct 2004 06:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHJYt-0008KT-FK for mpls@megatron.ietf.org; Tue, 12 Oct 2004 06:07:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05194 for ; Tue, 12 Oct 2004 06:07:17 -0400 (EDT) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHJja-0001Vb-HB for mpls@ietf.org; Tue, 12 Oct 2004 06:18:24 -0400 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CC1132AA0F; Tue, 12 Oct 2004 09:59:43 +0000 (GMT) In-Reply-To: <20041012082612.27006.qmail@web60909.mail.yahoo.com> References: <20041012082612.27006.qmail@web60909.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <94FE46FE-1C36-11D9-902D-0003934A79C2@sniff.de> Content-Transfer-Encoding: 7bit From: Marc Binderberger Subject: Re: [mpls] mpls vs IPv6 Date: Tue, 12 Oct 2004 12:07:53 +0200 To: Spice Sylvia X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, Jung Janos X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Hi Sylvia, > May I be bold enough to ask the reason MPLS was ever > deployed? good marketing opportunity? ;-) Serious: there are probably some folks on the list who invented MPLS, being able to give you all reasons. Here a few from my limited point of view: * the speed argument: MPLS is now 8 years old (I think. or even older?), at that time Silicon to swap labels had been available for ATM already while hardware-based routing was still expensive, less mature and so on. _Today_ the argument is not valid anymore - but that's 8 years later. * Larger ISPs in the US often had an ATM core with routers at the edge and any-any PVC meshing. What is called the overlay model. Doesn't scale well for your IGP, so making the ATM switches part of your IGP/MPLS (the "peer" model) scales better. For invest protection etc. you want to use the existing ATM boxes. Then we had the Internet bubble. Bandwidth for free (well, or not). Suddenly you had 10Gbit/s networks out there - and a need to use them. * Do you wanna build a separate ATM/FR network? No, you want similar capabilities on your router network, so you get TE. * Fast rerouting because these new networks often are DWDM, not SDH based anymore (read: unprotected wavelength). Additionally some bright minds realized how cool the routing protocols are in the IP world. Instead of SDH rings - somewhat limited - it would be more flexible and even cheaper (hmm) when you run meshed networks. So suddenly you have stuff like OSPF on your transmission equipment for circuit setup etc ... well, you need more than OSPF and (G)MPLS as the generic control plane comes into play here. As I said: just a few reasons. Many different motivations meanwhile. > And how many such end addresses are there? Do we need > to throw out the existing gear to move to IPv6? this problem is not related to MPLS, is it? In fact I know hardware where MPLS is the only way to run IPv6 at high speed - because the MPLS "hides" the IPv6 which some ASICs cannot deal with (and you don't wanna run STM16 on a 200MHz MIPS R5000 ;-) > But then tomorrow's ASICs will be faster than today's > so why not wait for tomorrow :)) till they are built > ?? faster than wire speed? ;-) > But why woould I need ATM then? See above: some _have_ ATM networks and want to integrate IP and ATM networks into one. Regards, Marc P.S.: is this "historical" discussion Off-Topic for the list? In this case I apologize and switch over to private comm channels :-) -- Marc Binderberger _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 08:23:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13747; Tue, 12 Oct 2004 08:23:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHLrt-0003uT-Hy; Tue, 12 Oct 2004 08:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHLZp-0005Xh-Gp; Tue, 12 Oct 2004 08:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHLQA-0003Jt-As for mpls@megatron.ietf.org; Tue, 12 Oct 2004 08:06:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12102 for ; Tue, 12 Oct 2004 08:06:24 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHLas-0003VE-9Q for mpls@ietf.org; Tue, 12 Oct 2004 08:17:30 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9CC5KG21929; Tue, 12 Oct 2004 08:05:20 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <4XAWLAVM>; Tue, 12 Oct 2004 08:05:21 -0400 Message-ID: From: "Peter Ashwood-Smith" To: "'Spice Sylvia'" , Marc Binderberger , Jung Janos Subject: RE: [mpls] mpls vs IPv6 Date: Tue, 12 Oct 2004 08:05:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1143502718==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 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. --===============1143502718== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B053.BD41B752" 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. ------_=_NextPart_001_01C4B053.BD41B752 Content-Type: text/plain You are correct that many of the original motivations for MPLS are no longer really valid. Forwarding speed as you point out is less relevant; Encapsulation can be done other ways such that MPLS would only be required at the service level; The one thing that you cannot easily do without label substitution forwarding is non shortest path forwarding. If you ever want a subset of your traffic to diverge from the routes IP would give, you either have to: A) use source routing (stateless). B) use label substitution (statefull). C) Create multiple instances of another hop-by-hop protocol i.e multiple forwarding tables and a way to figure out which one to use, i.e. DHCP/flow etc. could key which table .. This is of course true regardless of the address size or how QOS is implemented per hop. Right now B) seems the most practical option although with bandwidth getting cheaper by the nanosecond it can't be long before new forms of A) arrive. Peter -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] Sent: Tuesday, October 12, 2004 4:26 AM To: Marc Binderberger; Jung Janos Cc: mpls@ietf.org Subject: Re: [mpls] mpls vs IPv6 May I be bold enough to ask the reason MPLS was ever deployed? some more queries inline.> --- Marc Binderberger wrote: > Hello, > > > With MPLS I can create MPLS VPNs, QoS can > (really?) be > > granted to packet flows, and routing is more > faster. > > Forget about the "faster". Today the forwarding > happens either in > hardware and is wire-speed for IPv4/IPv6 as well. Or > it's the same > underlying mechanism in software, e.g. the "CEF" > table in Cisco > routers. > And how many such end addresses are there? Do we need to throw out the existing gear to move to IPv6? > QoS for MPLS is in first place the same as for > IPv4/IPv6. You have 3 > bits, like the (old) IPv4 Precedence. In theory more > QoS information > could be coded in the label, of course. > > > IPv6 has the "Flow label" field wich makes routing > faster > > again, the "faster" doesn't matter with today's > ASICs in place. > But then tomorrow's ASICs will be faster than today's so why not wait for tomorrow :)) till they are built ?? > > and has less header overhead than ipv4 (or > mpls+ipv4) > > n*4+20 vs. 40 - less overhead? > > > And i think flow label could have the same use as > > the mpls label value... > > > > How is MPLS to IPv6 related? > > as already answered: the same as MPLS to IPv4. > Well, there is always a difference between theory > and implementation. > MPLS needs LDP (and RSVP depending on what you do), > LDP uses IP UDP and > TCP. Although informations within are "TLV" coded > and thus expandable I > haven't seen any IPv6-based LDP on my Cisco so far. > Read: you may have > IPv4 to run protocols like LDP to finally run MPLS > carrying IPv6 > packets. > > > Are they technologies that have nothing to do with > each other? > > From a generic point of view: correct. > > > Or MPLS can bring new functionalities to IPv6 > networks (like to IPv4), > > and > > so mpls+ipv6 would have a sense? > > exactly. Hope I don't start a religious war now but > look upon IPv6 as > an IPv4 with larger addresses, a more structured > approach to "ip > options", avoiding fragmentation (on transit > routers) and such. In > short: more addresses ;-) > > Same as for IPv4: TE capabilities, allows you to > integrate ATM into > your IP packet network, [...]. > But why woould I need ATM then? _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01C4B053.BD41B752 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mpls] mpls vs IPv6

  You are correct that many of the original = motivations for MPLS are no longer really valid.
Forwarding speed as you point out is less relevant; = Encapsulation can be done other ways such that MPLS would only be = required at the service level;

  The one thing that you cannot easily do = without label substitution forwarding is non shortest path forwarding. = If you ever want a subset of your traffic to diverge from the routes IP = would give, you either have to:

   A) use source routing = (stateless).
   B) use label substitution = (statefull).
   C) Create multiple instances of another = hop-by-hop protocol i.e multiple forwarding tables and a way to figure = out which one to use, i.e. DHCP/flow etc. could key which table .. =

  This is of course true regardless of the = address size or how QOS is implemented per hop. Right now B) seems the = most practical option although with bandwidth getting cheaper by the = nanosecond it can't be long before new forms of A) arrive.

  Peter


-----Original Message-----
From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ie= tf.org]
Sent: Tuesday, October 12, 2004 4:26 AM
To: Marc Binderberger; Jung Janos
Cc: mpls@ietf.org
Subject: Re: [mpls] mpls vs IPv6


May I be bold enough to ask the reason MPLS was = ever
deployed?

some more queries inline.>

--- Marc Binderberger <marc@sniff.de> = wrote:

> Hello,
>
> > With MPLS I can create MPLS VPNs, QoS = can
> (really?) be
> > granted to packet flows, and routing is = more
> faster.
>
> Forget about the "faster". Today the = forwarding
> happens either in
> hardware and is wire-speed for IPv4/IPv6 as = well. Or
> it's the same
> underlying mechanism in software, e.g. the = "CEF"
> table in Cisco
> routers.
>

And how many such end addresses are there? Do we = need
to throw out the existing gear to move to = IPv6?

> QoS for MPLS is in first place the same as = for
> IPv4/IPv6. You have 3
> bits, like the (old) IPv4 Precedence. In theory = more
> QoS information
> could be coded in the label, of course.
>
> > IPv6 has the "Flow label" field = wich makes routing
> faster
>
> again, the "faster" doesn't matter = with today's
> ASICs in place.
>

But then tomorrow's ASICs will be faster than = today's
so why not wait for tomorrow :)) till they are = built
??


> > and has less header overhead than ipv4 = (or
> mpls+ipv4)
>
> n*4+20 vs. 40 - less overhead?
>
> > And i think flow label could have the same = use as
> > the mpls label value...
> >
> > How is MPLS to IPv6 related?
>
> as already answered: the same as MPLS to = IPv4.
> Well, there is always a difference between = theory
> and implementation.
> MPLS needs LDP (and RSVP depending on what you = do),
> LDP uses IP UDP and
> TCP. Although informations within are = "TLV" coded
> and thus expandable I
> haven't seen any IPv6-based LDP on my Cisco so = far.
> Read: you may have
> IPv4 to run protocols like LDP to finally run = MPLS
> carrying IPv6
> packets.
>
> > Are they technologies that have nothing to = do with
> each other?
>
>  From a generic point of view: = correct.
>
> > Or MPLS can bring new functionalities to = IPv6
> networks (like to IPv4),
> > and
> > so mpls+ipv6 would have a sense?
>
> exactly. Hope I don't start a religious war now = but
> look upon IPv6 as
> an IPv4 with larger addresses, a more = structured
> approach to "ip
> options", avoiding fragmentation (on = transit
> routers) and such. In
> short: more addresses ;-)
>

> Same as for IPv4: TE capabilities, allows you = to
> integrate ATM into
> your IP packet network, [...].
>
But why woould I need ATM then?


        =        =20
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote = today!
http://vote.yahoo.com

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls=

------_=_NextPart_001_01C4B053.BD41B752-- --===============1143502718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1143502718==-- From mpls-bounces@ietf.org Tue Oct 12 09:17:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18518; Tue, 12 Oct 2004 09:17:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMhS-0004x3-Rj; Tue, 12 Oct 2004 09:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMMm-00025t-V3; Tue, 12 Oct 2004 09:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMER-0007nr-IN for mpls@megatron.ietf.org; Tue, 12 Oct 2004 08:58:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16990 for ; Tue, 12 Oct 2004 08:58:22 -0400 (EDT) Received: from web60904.mail.yahoo.com ([216.155.196.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHMPA-0004b0-0p for mpls@ietf.org; Tue, 12 Oct 2004 09:09:29 -0400 Message-ID: <20041012125750.86836.qmail@web60904.mail.yahoo.com> Received: from [61.16.170.194] by web60904.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 13:57:50 BST Date: Tue, 12 Oct 2004 13:57:50 +0100 (BST) From: Spice Sylvia Subject: Re: [mpls] mpls vs IPv6 To: Marc Binderberger In-Reply-To: <94FE46FE-1C36-11D9-902D-0003934A79C2@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 8bit Hi Marc/list, I will take this offline, I just realised it is OT, Am sorry to have marked the list and my apologies on the same. -brgds Sylvia. --- Marc Binderberger wrote: > Hi Sylvia, > > > May I be bold enough to ask the reason MPLS was > ever > > deployed? > > good marketing opportunity? ;-) > > Serious: there are probably some folks on the list > who invented MPLS, > being able to give you all reasons. Here a few from > my limited point of > view: > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 10:21:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22933; Tue, 12 Oct 2004 10:21:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNhn-0006IF-LH; Tue, 12 Oct 2004 10:32:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMyf-0004Ht-6k; Tue, 12 Oct 2004 09:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMmC-0000c6-1b for mpls@megatron.ietf.org; Tue, 12 Oct 2004 09:33:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19741 for ; Tue, 12 Oct 2004 09:33:15 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMwv-0005EV-PF for mpls@ietf.org; Tue, 12 Oct 2004 09:44:23 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i9CDSvr23140 for ; Tue, 12 Oct 2004 15:28:58 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Tue, 12 Oct 2004 15:33:33 +0200 Message-ID: <416BDC7C.1050001@pi.se> Date: Tue, 12 Oct 2004 15:30:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Ashwood-Smith Subject: Re: [mpls] mpls vs IPv6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, Jung Janos X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit All, here we go again ;) It is one of the "popular" misconceptions that mpls ever was intended to improve node capacity. If you go back to the problem statement from IETF 38 (Memphis April -97) you will find that there were four items in the problem state node performance was not one of them. Network performance were, but that had nothing to do with the throughput of the routers (nodes) but with the ability to load more traffic on to the network. A couple of meetings later we extended the "performance" conceot and started to call it "internet traffic engineering". I remember people coming up to me in Memphis and Munich (and later) trying to explain that routers did forward at line speed and consequently mpls was not needed. They were rather surprised when I agreed on the line speed, but pointed out that mpls were not intended to solve that non-problem. /Loa Peter Ashwood-Smith wrote: > > You are correct that many of the original motivations for MPLS are no > longer really valid. > Forwarding speed as you point out is less relevant; Encapsulation can be > done other ways such that MPLS would only be required at the service level; > > The one thing that you cannot easily do without label substitution > forwarding is non shortest path forwarding. If you ever want a subset of > your traffic to diverge from the routes IP would give, you either have to: > > A) use source routing (stateless). > B) use label substitution (statefull). > C) Create multiple instances of another hop-by-hop protocol i.e > multiple forwarding tables and a way to figure out which one to use, > i.e. DHCP/flow etc. could key which table .. > > This is of course true regardless of the address size or how QOS is > implemented per hop. Right now B) seems the most practical option > although with bandwidth getting cheaper by the nanosecond it can't be > long before new forms of A) arrive. > > Peter > > > -----Original Message----- > From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] > Sent: Tuesday, October 12, 2004 4:26 AM > To: Marc Binderberger; Jung Janos > Cc: mpls@ietf.org > Subject: Re: [mpls] mpls vs IPv6 > > > May I be bold enough to ask the reason MPLS was ever > deployed? > > some more queries inline.> > > --- Marc Binderberger wrote: > > > Hello, > > > > > With MPLS I can create MPLS VPNs, QoS can > > (really?) be > > > granted to packet flows, and routing is more > > faster. > > > > Forget about the "faster". Today the forwarding > > happens either in > > hardware and is wire-speed for IPv4/IPv6 as well. Or > > it's the same > > underlying mechanism in software, e.g. the "CEF" > > table in Cisco > > routers. > > > > And how many such end addresses are there? Do we need > to throw out the existing gear to move to IPv6? > > > QoS for MPLS is in first place the same as for > > IPv4/IPv6. You have 3 > > bits, like the (old) IPv4 Precedence. In theory more > > QoS information > > could be coded in the label, of course. > > > > > IPv6 has the "Flow label" field wich makes routing > > faster > > > > again, the "faster" doesn't matter with today's > > ASICs in place. > > > > But then tomorrow's ASICs will be faster than today's > so why not wait for tomorrow :)) till they are built > ?? > > > > > and has less header overhead than ipv4 (or > > mpls+ipv4) > > > > n*4+20 vs. 40 - less overhead? > > > > > And i think flow label could have the same use as > > > the mpls label value... > > > > > > How is MPLS to IPv6 related? > > > > as already answered: the same as MPLS to IPv4. > > Well, there is always a difference between theory > > and implementation. > > MPLS needs LDP (and RSVP depending on what you do), > > LDP uses IP UDP and > > TCP. Although informations within are "TLV" coded > > and thus expandable I > > haven't seen any IPv6-based LDP on my Cisco so far. > > Read: you may have > > IPv4 to run protocols like LDP to finally run MPLS > > carrying IPv6 > > packets. > > > > > Are they technologies that have nothing to do with > > each other? > > > > From a generic point of view: correct. > > > > > Or MPLS can bring new functionalities to IPv6 > > networks (like to IPv4), > > > and > > > so mpls+ipv6 would have a sense? > > > > exactly. Hope I don't start a religious war now but > > look upon IPv6 as > > an IPv4 with larger addresses, a more structured > > approach to "ip > > options", avoiding fragmentation (on transit > > routers) and such. In > > short: more addresses ;-) > > > > > Same as for IPv4: TE capabilities, allows you to > > integrate ATM into > > your IP packet network, [...]. > > > But why woould I need ATM then? > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > ------------------------------------------------------------------------ > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 10:47:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26100; Tue, 12 Oct 2004 10:47:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHO6d-0006nO-LW; Tue, 12 Oct 2004 10:58:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNjI-0002jP-5Y; Tue, 12 Oct 2004 10:34:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNY5-00079h-A9 for mpls@megatron.ietf.org; Tue, 12 Oct 2004 10:22:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23120 for ; Tue, 12 Oct 2004 10:22:43 -0400 (EDT) Received: from web60910.mail.yahoo.com ([216.155.196.86]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHNio-0006J5-OT for mpls@ietf.org; Tue, 12 Oct 2004 10:33:52 -0400 Message-ID: <20041012135529.79621.qmail@web60910.mail.yahoo.com> Received: from [61.16.170.194] by web60910.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 14:55:29 BST Date: Tue, 12 Oct 2004 14:55:29 +0100 (BST) From: Spice Sylvia Subject: Re: [mpls] mpls vs IPv6 To: menth@informatik.uni-wuerzburg.de In-Reply-To: <416BDA0C.7060900@informatik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 8bit Mike, that "interesting bit" you refer to was unintentional. The message is automatically snipped by the mailer I use. Loa and all, thank you for the many posts that have come offline (including the "please unsubscribe from the list" emails) The intention was not to start a flame war. --- Michael Menth wrote: > Hi Sylvia, > > I found this quite interesting! > > Regards, > > Michael > > Spice Sylvia wrote: > > >Hi Marc/list, > > > >I will take this offline, I just realised it is OT, > > >Am sorry to have marked the list and my apologies > on > >the same. > > > >-brgds > >Sylvia. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 13:42:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12664; Tue, 12 Oct 2004 13:42:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQpo-00036S-42; Tue, 12 Oct 2004 13:53:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQQL-0006T5-5u; Tue, 12 Oct 2004 13:26:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQMR-0005IJ-Ag for mpls@megatron.ietf.org; Tue, 12 Oct 2004 13:22:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10591 for ; Tue, 12 Oct 2004 13:22:53 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQXD-0002fP-TY for mpls@ietf.org; Tue, 12 Oct 2004 13:34:04 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i9CHM8Bm072857; Tue, 12 Oct 2004 10:22:08 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9CHM8e92718; Tue, 12 Oct 2004 10:22:08 -0700 (PDT) (envelope-from ina@juniper.net) Date: Tue, 12 Oct 2004 10:22:08 -0700 (PDT) From: Ina Minei To: mpls@ietf.org Message-ID: <20041012101652.V87940@garnet.juniper.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-124918576-1097601728=:87940" X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Subject: [mpls] Operator survey on LDP deployments X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-124918576-1097601728=:87940 Content-Type: TEXT/PLAIN; charset=US-ASCII Operators, We need to produce a "description of operational experience" report to accompany the LDP spec to the IESG. Rajiv Papneja suggested to formalize this in a questionnaire. Rajiv and I put together a set of questions, with input from Halit Ustundag, Bob Thomas and Loa Andersson. Please take a few minutes to fill out the survey (at the end of this email and also attached). Partial responses are also useful, if you can't/don't_want_to answer any of the questions, just skip to the next one. If you would like to respond anonymously, please state so in the questionnaire. Confidential responses may be sent to Scott Bradner at sob@harvard.edu. Scott will strip away the info that would make it possible to trace the respondee before forwarding us the responses. Scott has acted in this role for other similar efforts. In addition, all confidential responses will be summarized in the final report, to further obscure the source. Many thanks to Scott for his help. Please send your responses by Oct 31st. Thank you for your cooperation, Ina & Rajiv Feedback on LDP deployments ============================ 1) Contact for the information provided Name: Title: E-mail: Organization/department: Postal address: Phone: 2) Confidentiality -- I would like the information to be confidential (confidential responses will be summarized) -- This information can be made publicly available 3) Reason for running LDP in the network (check all that apply) -- L3VPN -- L3VPN inter-AS scenario -- L2VPN -- VPLS -- pseudowires -- label-based forwarding -- other (please specify) 4) Sections of the deployed network where LDP is enabled -- edge -- core -- edge and core 5) How long have you run LDP in the network for (how long ago did you start using LDP). 6) Reason why LDP was selected -- ease of configuration -- no need for traffic engineering -- scalability concerns with other protocols -- use of a particular offline computation tool -- equipment vendor only supports LDP -- ease of management -- interoperability concerns -- better understanding by staff -- other 7) Are there targeted LDP sessions? If yes, for what purpose? -- traversing a traffic engineered core -- pseudo-wires -- other (please specify) -- don't use targeted sessions 8) Number of LSR running LDP in the network 9) Maximum number of sessions per LSR 10) Average number of sessions per LSR 11) Average number of targeted sessions per LSR 12) Number of LDP adjacencies per session (how many parallel interfaces connect two peers - one or more than one) 13) Number of incoming/outgoing bindings (average) 14) Number of LDP routes installed 15) Number of PEs in the network 16) Do you use LDP graceful restart? 17) LSP setup is accomplished with -- independent control -- ordered control -- both (if some routers support one and some support the other) -- don't know 18) Label distribution is -- downstream unsolicited mode -- downstream on demand mode -- don't know 19) If downstream on demand mode is used, is loop detection configured? 20) Label retention mode -- conservative -- liberal -- both -- don't know 21) Number of implementations in the network -- one -- more than one (please specify how many) -- optional - please specify the implementations used Operations ============ 22) What challenges did you encounter in deploying an LDP network? 23) What issues did you encounter in running an LDP network? 24) Did you encounter any security issues with LDP? Other ====== 25) Did you face any common interoperability issues if multiple vendors are used? If yes, please list. 26) Please comment on your experience with the protocol (e.g. resilience to failures, convergence times, silent failures, etc.) --0-124918576-1097601728=:87940 Content-Type: TEXT/plain; name="operator_survey.txt" Content-ID: <20041012102208.E87940@garnet.juniper.net> Content-Description: survey Content-Disposition: attachment; filename="operator_survey.txt" Content-Transfer-Encoding: BASE64 DQpGZWVkYmFjayBvbiBMRFAgZGVwbG95bWVudHMNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg0KMSkgQ29udGFjdCBmb3IgdGhlIGluZm9ybWF0 aW9uIHByb3ZpZGVkIA0KDQpOYW1lOiAgICAgICAgICAgICAgICAgICANClRp dGxlOiAgICAgICAgICAgICAgICAgIA0KRS1tYWlsOiAgICAgICAgICAgICAg ICAgDQpPcmdhbml6YXRpb24vZGVwYXJ0bWVudDogDQpQb3N0YWwgYWRkcmVz czogICAgICAgICAgDQpQaG9uZTogICAgICAgICAgICAgICAgICAgDQoNCjIp IENvbmZpZGVudGlhbGl0eSANCi0tIEkgd291bGQgbGlrZSB0aGUgaW5mb3Jt YXRpb24gdG8gYmUgY29uZmlkZW50aWFsIChjb25maWRlbnRpYWwNCnJlc3Bv bnNlcyB3aWxsIGJlIHN1bW1hcml6ZWQpDQotLSBUaGlzIGluZm9ybWF0aW9u IGNhbiBiZSBtYWRlIHB1YmxpY2x5IGF2YWlsYWJsZQ0KDQozKSBSZWFzb24g Zm9yIHJ1bm5pbmcgTERQIGluIHRoZSBuZXR3b3JrIChjaGVjayBhbGwgdGhh dCBhcHBseSkNCi0tIEwzVlBOICAgICANCi0tIEwzVlBOIGludGVyLUFTIHNj ZW5hcmlvDQotLSBMMlZQTg0KLS0gVlBMUw0KLS0gcHNldWRvd2lyZXMNCi0t IGxhYmVsLWJhc2VkIGZvcndhcmRpbmcNCi0tIG90aGVyIChwbGVhc2Ugc3Bl Y2lmeSkNCg0KNCkgU2VjdGlvbnMgb2YgdGhlIGRlcGxveWVkIG5ldHdvcmsg d2hlcmUgTERQIGlzIGVuYWJsZWQNCi0tIGVkZ2UNCi0tIGNvcmUNCi0tIGVk Z2UgYW5kIGNvcmUNCg0KNSkgSG93IGxvbmcgaGF2ZSB5b3UgcnVuIExEUCBp biB0aGUgbmV0d29yayBmb3IgKGhvdyBsb25nIGFnbyBkaWQgeW91DQpzdGFy dCB1c2luZyBMRFApLiANCg0KNikgUmVhc29uIHdoeSBMRFAgd2FzIHNlbGVj dGVkDQotLSBlYXNlIG9mIGNvbmZpZ3VyYXRpb24NCi0tIG5vIG5lZWQgZm9y IHRyYWZmaWMgZW5naW5lZXJpbmcNCi0tIHNjYWxhYmlsaXR5IGNvbmNlcm5z IHdpdGggb3RoZXIgcHJvdG9jb2xzDQotLSB1c2Ugb2YgYSBwYXJ0aWN1bGFy IG9mZmxpbmUgY29tcHV0YXRpb24gdG9vbA0KLS0gZXF1aXBtZW50IHZlbmRv ciBvbmx5IHN1cHBvcnRzIExEUA0KLS0gZWFzZSBvZiBtYW5hZ2VtZW50DQot LSBpbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm5zDQotLSBiZXR0ZXIgdW5kZXJz dGFuZGluZyBieSBzdGFmZg0KLS0gb3RoZXINCg0KNykgQXJlIHRoZXJlIHRh cmdldGVkIExEUCBzZXNzaW9ucz8gSWYgeWVzLCBmb3Igd2hhdCBwdXJwb3Nl Pw0KLS0gdHJhdmVyc2luZyBhIHRyYWZmaWMgZW5naW5lZXJlZCBjb3JlDQot LSBwc2V1ZG8td2lyZXMNCi0tIG90aGVyIChwbGVhc2Ugc3BlY2lmeSkNCi0t IGRvbid0IHVzZSB0YXJnZXRlZCBzZXNzaW9ucw0KDQo4KSBOdW1iZXIgb2Yg TFNSIHJ1bm5pbmcgTERQIGluIHRoZSBuZXR3b3JrDQoNCjkpIE1heGltdW0g bnVtYmVyIG9mIHNlc3Npb25zIHBlciBMU1IgDQoxMCkgQXZlcmFnZSBudW1i ZXIgb2Ygc2Vzc2lvbnMgcGVyIExTUg0KMTEpIEF2ZXJhZ2UgbnVtYmVyIG9m IHRhcmdldGVkIHNlc3Npb25zIHBlciBMU1INCg0KMTIpIE51bWJlciBvZiBM RFAgYWRqYWNlbmNpZXMgcGVyIHNlc3Npb24gKGhvdyBtYW55IHBhcmFsbGVs IGludGVyZmFjZXMNCmNvbm5lY3QgdHdvIHBlZXJzIC0gb25lIG9yIG1vcmUg dGhhbiBvbmUpDQoNCjEzKSBOdW1iZXIgb2YgaW5jb21pbmcvb3V0Z29pbmcg YmluZGluZ3MgKGF2ZXJhZ2UpDQoxNCkgTnVtYmVyIG9mIExEUCByb3V0ZXMg aW5zdGFsbGVkDQoxNSkgTnVtYmVyIG9mIFBFcyBpbiB0aGUgbmV0d29yayAN Cg0KMTYpIERvIHlvdSB1c2UgTERQIGdyYWNlZnVsIHJlc3RhcnQ/DQoNCjE3 KSBMU1Agc2V0dXAgaXMgYWNjb21wbGlzaGVkIHdpdGggDQotLSBpbmRlcGVu ZGVudCBjb250cm9sDQotLSBvcmRlcmVkIGNvbnRyb2wNCi0tIGJvdGggKGlm IHNvbWUgcm91dGVycyBzdXBwb3J0IG9uZSBhbmQgc29tZSBzdXBwb3J0IHRo ZSBvdGhlcikNCi0tIGRvbid0IGtub3cNCg0KMTgpIExhYmVsIGRpc3RyaWJ1 dGlvbiBpcyANCi0tIGRvd25zdHJlYW0gdW5zb2xpY2l0ZWQgbW9kZQ0KLS0g ZG93bnN0cmVhbSBvbiBkZW1hbmQgbW9kZQ0KLS0gZG9uJ3Qga25vdw0KDQox OSkgSWYgZG93bnN0cmVhbSBvbiBkZW1hbmQgbW9kZSBpcyB1c2VkLCBpcyBs b29wIGRldGVjdGlvbiBjb25maWd1cmVkPw0KDQoyMCkgTGFiZWwgcmV0ZW50 aW9uIG1vZGUNCi0tIGNvbnNlcnZhdGl2ZQ0KLS0gbGliZXJhbCANCi0tIGJv dGgNCi0tIGRvbid0IGtub3cNCg0KMjEpIE51bWJlciBvZiBpbXBsZW1lbnRh dGlvbnMgaW4gdGhlIG5ldHdvcmsNCi0tIG9uZSANCi0tIG1vcmUgdGhhbiBv bmUgKHBsZWFzZSBzcGVjaWZ5IGhvdyBtYW55KQ0KLS0gb3B0aW9uYWwgLSBw bGVhc2Ugc3BlY2lmeSB0aGUgaW1wbGVtZW50YXRpb25zIHVzZWQNCg0KT3Bl cmF0aW9ucw0KPT09PT09PT09PT09DQoyMikgV2hhdCBjaGFsbGVuZ2VzIGRp ZCB5b3UgZW5jb3VudGVyIGluIGRlcGxveWluZyBhbiBMRFAgbmV0d29yaz8N Cg0KMjMpIFdoYXQgaXNzdWVzIGRpZCB5b3UgZW5jb3VudGVyIGluIHJ1bm5p bmcgYW4gTERQIG5ldHdvcms/DQoNCjI0KSBEaWQgeW91IGVuY291bnRlciBh bnkgc2VjdXJpdHkgaXNzdWVzIHdpdGggTERQPw0KDQpPdGhlcg0KPT09PT09 DQoyNSkgRGlkIHlvdSBmYWNlIGFueSBjb21tb24gaW50ZXJvcGVyYWJpbGl0 eSBpc3N1ZXMgaWYgbXVsdGlwbGUgdmVuZG9ycw0KYXJlIHVzZWQ/IElmIHll cywgcGxlYXNlIGxpc3QuDQoNCjI2KSBQbGVhc2UgY29tbWVudCBvbiB5b3Vy IGV4cGVyaWVuY2Ugd2l0aCB0aGUgcHJvdG9jb2wgKGUuZy4gcmVzaWxpZW5j ZQ0KdG8gZmFpbHVyZXMsIGNvbnZlcmdlbmNlIHRpbWVzLCBzaWxlbnQgZmFp bHVyZXMsIGV0Yy4pDQoNCg0KDQo= --0-124918576-1097601728=:87940 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --0-124918576-1097601728=:87940-- From mpls-bounces@ietf.org Tue Oct 12 15:40:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAB24228; Tue, 12 Oct 2004 15:40:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSgk-0005nH-RI; Tue, 12 Oct 2004 15:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSPO-0001V6-U5; Tue, 12 Oct 2004 15:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSH4-0005OB-Kv for mpls@megatron.ietf.org; Tue, 12 Oct 2004 15:25:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22167 for ; Tue, 12 Oct 2004 15:25:29 -0400 (EDT) Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSRp-0005KF-6d for mpls@ietf.org; Tue, 12 Oct 2004 15:36:40 -0400 Received: from user-38ldt8s.dialup.mindspring.com ([209.86.245.28] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CHSFk-0006Zq-00; Tue, 12 Oct 2004 12:24:08 -0700 Message-ID: <416C2FB7.ED33760@earthlink.net> Date: Tue, 12 Oct 2004 12:25:43 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith Subject: Re: [mpls] mpls vs IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, Jung Janos X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Group, et al, I would like to remind people that MPLS can not be used without IP, however IP can be used without MPLS. IPvX is a end to end forwarding environment where MPLS is only a router to router forwarding environment. MPLS, is normally associated within a domain so that the edge routers need specialized features; i.e. translate IP headers into lables. Since routers within the MPLS doamin don't need the edge router capability, I would expect that this non feature could minimally reduce the cost. FYI, it may just be me, I haven't seen a non core router able to have a full window of echo size (ping) pkts/segs that could transit at 10Gb/sec over all of its interfaces at the same time at wire-speed. Yes, this is a worse case test. Now lets have multicast dsts. IMO, a still important item that has been overlooked is the convergence time of some of the larger link-state environments and/or the newer wireless paths. I think that the label distribution mechanisms within MPLS probably are more efficient and can set up the paths quicker. This relates to fewer delays and lost pkts while routing environments are somewhat chaotic. Also, the link state protocols (ISIS and OSPF) assume that ONE path is preferred, and this translates to adding single entries for a dst in the forwarding table. With MPLS, it is possible to have numerous paths to a dst where non-equal paths exist. This would allow a set of equal dst pkts (FEC) to traverse different paths based on different characteristics. These characteristics could be different ISP origination src addrs, bandwidth, delay, priority, SLAs, etc. Lastly, I am not sure that routing can NOT be "faster" in a MPLS environment. If I would be able to separate flows and label them, I should be able to know when a grouping of pkts is such that buffers in later routers would reach RED or tail-drop and later result in a congestion avoidance (CA) state if a transport protocol like TCP was involved. Yes, this presuposes that the bottleneck was within the MPLS domain and that I would prefer and capable to buffer up extended data flows vs allowing CA to occur. However, if the MPLS was sufficently faster in forwarding, I would expect that when a a sufficient number of in-flight pkts/segments occurs when exiting the MPLS domain that this would "back-up" and force CA in IP/TCP environments. Mitchell Erblich ------------------ > Peter Ashwood-Smith wrote: > > You are correct that many of the original motivations for MPLS are > no longer really valid. > Forwarding speed as you point out is less relevant; Encapsulation can > be done other ways such that MPLS would only be required at the > service level; > > The one thing that you cannot easily do without label substitution > forwarding is non shortest path forwarding. If you ever want a subset > of your traffic to diverge from the routes IP would give, you either > have to: > > A) use source routing (stateless). > B) use label substitution (statefull). > C) Create multiple instances of another hop-by-hop protocol i.e > multiple forwarding tables and a way to figure out which one to use, > i.e. DHCP/flow etc. could key which table .. > > This is of course true regardless of the address size or how QOS is > implemented per hop. Right now B) seems the most practical option > although with bandwidth getting cheaper by the nanosecond it can't be > long before new forms of A) arrive. > > Peter > > -----Original Message----- > From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] > > Sent: Tuesday, October 12, 2004 4:26 AM > To: Marc Binderberger; Jung Janos > Cc: mpls@ietf.org > Subject: Re: [mpls] mpls vs IPv6 > > May I be bold enough to ask the reason MPLS was ever > deployed? > > some more queries inline.> > > --- Marc Binderberger wrote: > > > Hello, > > > > > With MPLS I can create MPLS VPNs, QoS can > > (really?) be > > > granted to packet flows, and routing is more > > faster. > > > > Forget about the "faster". Today the forwarding > > happens either in > > hardware and is wire-speed for IPv4/IPv6 as well. Or > > it's the same > > underlying mechanism in software, e.g. the "CEF" > > table in Cisco > > routers. > > > > And how many such end addresses are there? Do we need > to throw out the existing gear to move to IPv6? > > > QoS for MPLS is in first place the same as for > > IPv4/IPv6. You have 3 > > bits, like the (old) IPv4 Precedence. In theory more > > QoS information > > could be coded in the label, of course. > > > > > IPv6 has the "Flow label" field wich makes routing > > faster > > > > again, the "faster" doesn't matter with today's > > ASICs in place. > > > > But then tomorrow's ASICs will be faster than today's > so why not wait for tomorrow :)) till they are built > ?? > > > > and has less header overhead than ipv4 (or > > mpls+ipv4) > > > > n*4+20 vs. 40 - less overhead? > > > > > And i think flow label could have the same use as > > > the mpls label value... > > > > > > How is MPLS to IPv6 related? > > > > as already answered: the same as MPLS to IPv4. > > Well, there is always a difference between theory > > and implementation. > > MPLS needs LDP (and RSVP depending on what you do), > > LDP uses IP UDP and > > TCP. Although informations within are "TLV" coded > > and thus expandable I > > haven't seen any IPv6-based LDP on my Cisco so far. > > Read: you may have > > IPv4 to run protocols like LDP to finally run MPLS > > carrying IPv6 > > packets. > > > > > Are they technologies that have nothing to do with > > each other? > > > > From a generic point of view: correct. > > > > > Or MPLS can bring new functionalities to IPv6 > > networks (like to IPv4), > > > and > > > so mpls+ipv6 would have a sense? > > > > exactly. Hope I don't start a religious war now but > > look upon IPv6 as > > an IPv4 with larger addresses, a more structured > > approach to "ip > > options", avoiding fragmentation (on transit > > routers) and such. In > > short: more addresses ;-) > > > > > Same as for IPv4: TE capabilities, allows you to > > integrate ATM into > > your IP packet network, [...]. > > > But why woould I need ATM then? > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > --------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 17:20:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12897; Tue, 12 Oct 2004 17:20:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUFD-000314-MY; Tue, 12 Oct 2004 17:31:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTQ1-0004eO-Ef; Tue, 12 Oct 2004 16:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSx3-0002ZI-9H; Tue, 12 Oct 2004 16:08:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27984; Tue, 12 Oct 2004 16:08:52 -0400 (EDT) Message-Id: <200410122008.QAA27984@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 16:08:51 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Specification Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-rfc3036bis-00.txt Pages : 162 Date : 2004-10-12 The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rfc3036bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rfc3036bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rfc3036bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-12160528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rfc3036bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rfc3036bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-12160528.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Tue Oct 12 17:32:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15836; Tue, 12 Oct 2004 17:32:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUQl-0003vm-0V; Tue, 12 Oct 2004 17:43:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTRz-00067A-Ua; Tue, 12 Oct 2004 16:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHT6H-0008SX-Uj for mpls@megatron.ietf.org; Tue, 12 Oct 2004 16:18:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29898 for ; Tue, 12 Oct 2004 16:18:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHTH6-0007Mj-7A for mpls@ietf.org; Tue, 12 Oct 2004 16:29:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i9CKHqr2024597 for ; Tue, 12 Oct 2004 16:17:52 -0400 (EDT) Received: from [169.144.136.107] (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05642 for ; Tue, 12 Oct 2004 16:17:51 -0400 (EDT) Message-ID: <416C3BEE.4070905@marconi.com> Date: Tue, 12 Oct 2004 16:17:50 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] mpls vs IPv6 References: <416C2FB7.ED33760@earthlink.net> In-Reply-To: <416C2FB7.ED33760@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Erblichs wrote: > > I would like to remind people that MPLS can not > be used without IP, however IP can be used without > MPLS. This is not entirely true. Although MPLS is almost always used in conjunction with IP, it doesn't have to be. For instance: - LSPs can be configured instead of signaled (much like how PVCs are configured on ATM switches.) - Routing/topology information may be distributed using a non-IP routing protocol, like IS-IS. (Although IS-IS is usually used to distribute IP topology information, it uses ISO addresses, not IP addresses.) - Although today's MPLS signaling protocols (LDP and RSVP-TE) are both tied to IP addressing, there is no reason why a non-IP signaling protocol couldn't be developed for setting up LSPs. (For that matter, RSVP-TE could even be extended to allow signaling over non-IP networks (it would only require new C-Types for the SESSION, SENDER_TEMPLATE and FILTER_SPEC objects and a few new subobjects for the EXPLICIT_ROUTE and RECORD_ROUTE classes.) - Non-IP traffic may be (and sometimes is already) carried in LSPs. In RSVP-TE, the layer-3 protocol is signaled in the SESSION_ATTRIBUTES object. For layer-2 LSPs, an extra label (Martini or PWE3) may be used to identify the traffic. > IPvX is a end to end forwarding environment where > MPLS is only a router to router forwarding > environment. Conventionally, yes. But there's no technical reason why a host couldn't drive LSP creation. It isn't done because there isn't any need for this, not because of any technical problems. > MPLS, is normally associated within a domain > so that the edge routers need specialized > features; i.e. translate IP headers into lables. Domain? What exactly do you mean by this? In the IP/internet world, a domain is a DNS term that has no applicability to routing/signaling. In the ATM world, it refers to a group of routers that share routing information together. The closest IP analog to an ATM domain would be an autonomous system (AS). Although MPLS networks typically do not span across ASs, they can, in theory. There is ongoing work to develop practical ways to make this a practical reality. You are correct, however, that LERs (LSP edge routers) need the capability to push/pop labels onto/from unlabeled packets. > Since routers within the MPLS doamin don't need the > edge router capability, I would expect that this > non feature could minimally reduce the cost. This was a concern in the not-too-recent past. Especially when using MPLS software to retrofit legacy ATM gear (interfaces on ATM switches typically don't have the capability to push/pop labels.) Today, however, this is less of a concern, since all the major MPLS players are making hardware with this capability. > IMO, a still important item that has been overlooked > is the convergence time of some of the larger link-state > environments and/or the newer wireless paths. I think > that the label distribution mechanisms within MPLS > probably are more efficient and can set up the > paths quicker. This relates to fewer delays and > lost pkts while routing environments are somewhat > chaotic. MPLS, in a signaled environment, relies on an IGP. LDP allocates and distributes labels as routes are learned. RSVP-TE can't set up an LSP until routing converges. Either the ingress node must compute a path to the destination or all the transit nodes must be able to forward the Path messages to the destination using local route tables. You can, of course, pre-configure LSPs to get around this, that undermines many of the benefits of MPLS. > Also, the link state protocols (ISIS and OSPF) > assume that ONE path is preferred, and this translates > to adding single entries for a dst in the forwarding > table. Not necessarily. Equal-cost multipath extensions are common in the non-MPLS world. Providing alternate routing paths where they're not all equal cost is uglier, of course. > With MPLS, it is possible to have numerous > paths to a dst where non-equal paths exist. This > would allow a set of equal dst pkts (FEC) to traverse > different paths based on different characteristics. > These characteristics could be different ISP > origination src addrs, bandwidth, delay, priority, > SLAs, etc. You can do this without MPLS, but it requires all your routers to classify all the packets and classify them according to the same set of rules. It's inefficient (and probably will limit your throughput) but it can be done. The big deal about MPLS isn't that you can do anything new, but that all of the work in classifying the packets is focussed entirely in the edge router (where bandwidths are probably lower) so that the core (where bandwidth is higher) doesn't have to do this work. -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 17:56:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19376; Tue, 12 Oct 2004 17:56:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUoK-0004nJ-Fl; Tue, 12 Oct 2004 18:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUNu-0004cC-Rd; Tue, 12 Oct 2004 17:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTvn-0007vi-Td; Tue, 12 Oct 2004 17:11:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11040; Tue, 12 Oct 2004 17:11:38 -0400 (EDT) Received: from sa.infonet.com ([192.157.130.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHU6M-0002NG-KI; Tue, 12 Oct 2004 17:22:50 -0400 Received: from zhangr2.sa.infonet.com (sfjl161.us.info.net [204.79.139.161] (may be forged)) by sa.infonet.com with ESMTP id i9CLBKOA023203; Tue, 12 Oct 2004 21:11:20 GMT Message-Id: <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 12 Oct 2004 14:10:02 -0700 To: Adrian Farrel , , From: raymond zhang Subject: Re: [mpls] Mailing List for Path Computation Element (PCE) In-Reply-To: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> References: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hi Adrian, JP, Jerry, I've gone through the I-D "draft-ash-pce-architecture-00.txt" and I think this document has very well stated the architectural objectives and need for a separate WG for this area. Also please find some minor comments below: - section 3. Definitions " Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. The PCE entity can be located within an application" (RZ: I'd suggest some rewording here: The PCE entity is an application process that can be located on a network node or component, on an out-of- network server, etc.) - Page 4, first paragraph: 1) Path computation is applicable in both intra-domain, inter-domain, and inter-layer contexts. Inter-domain path computation may involve the correlation of topology and routing information between domains. Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or multiple (RZ:"inter-layer contexts" is mentioned at the beginning of this paragraph so it would be good to explain this a bit as did for inter-domain) - Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")... - Page 6, 2nd paragraph: (RZ: From SP's perspective, it is not a difficult thing to migrate a legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane supporting TE ext. So I dont seem to see a strong case for this...) - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say on one hand this scenario does not relay on loose hops, yet on the other hand PCE based solution provides loose hops in the computed paths ?) - Page 7, section 5.1. 5.1. Composite PCE "Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests are received by the node and converted into signaling requests" (RZ:it would be good to clarify between service requests to the PCE or inter- PCE requests and service requests to signal a TE-LSP request) ... - Page 12, first paragraph (RZ: It would be probably more appropriate to rename to this section to "Service Request/Response Synchronization" vs. "TED Sync" in a subsequent section. It may be more productive here in describing service request/reponse sync of PCC-PCE and PCE-PCE as part of the architectural discussion, rather than illustrating more detailed procedures since these procedures could be discussed in a detailed spec document in which it may transform to something different.) - page 13, 2nd paragrah: "No assumption is made at this stage about whether the PCC-PCE and PCE-PCE communication protocols are identical." (RZ: but I think it would be architectrually more scalable if they are same, so are such comments are warranted here (same protocols for both PCC-PCE/PCE-PCE...) in an arch doc ? - Section 6.8: (RZ: since this is an arch doc, does it imply that implementation of either scheme would meet the arch framework established here ?) - A general comment: there are a lot of very good, analytical discussions in the document presenting different cases. It would be good I think if the authors could provide some guidance in drawing up some architecture recommendations after comparing/analyzing some of these cases or simply say all cases presented in some of these sections are considered valid architectural options ? Regards, Raymond _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 12 20:47:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03594; Tue, 12 Oct 2004 20:47:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHXTI-00080O-Fe; Tue, 12 Oct 2004 20:58:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHXGj-0007Ql-SO; Tue, 12 Oct 2004 20:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHXDl-0006i5-4C for mpls@megatron.ietf.org; Tue, 12 Oct 2004 20:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03303 for ; Tue, 12 Oct 2004 20:42:23 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHXOa-0007vV-Rf for mpls@ietf.org; Tue, 12 Oct 2004 20:53:37 -0400 Received: from user-38ldt8s.dialup.mindspring.com ([209.86.245.28] helo=earthlink.net) by pop-a065d01.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CHXDd-0005wt-00; Tue, 12 Oct 2004 17:42:18 -0700 Message-ID: <416C7A38.99372004@earthlink.net> Date: Tue, 12 Oct 2004 17:43:36 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Subject: Re: [mpls] mpls vs IPv6 References: <416C2FB7.ED33760@earthlink.net> <416C3BEE.4070905@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit David and group, Yes, basicly we are on track. I was trying to generalize about arch and implimentations within the equiv of a 1 pager and and not try to write a book on the diffs. People can read all the RFCs if they want book format! (Domain) MPLS domain is bounded by ingress / outgress label edge router (LER) where the LSP is not necessarily determined by the contents of the IP header. However... I don't see how a OSPF pkt could recv a different path (when only 1 best LS path exists) other than the best path chosen for it by the SPF algorithm. Same for IS-IS? Same for RIP? BGP probably could have unequal paths due to the different RIB, filters, etc.. Yes, LDP leans routes, however, the LDP keeps the same routes until explicitly torn down. In a chaotic IP forwarding env, if the routes constantly change and the in-flight pkts/segments are backed by TCP, their will be constant re-ordering of the segs. Most implimentations will respond with the re-ordering by seeing 3 duplicate acks and will do un-necessary fast re-transmits / spurious rexmits. In addition to consuming bandwidth, convergence time, etc, at the the time of the fast re-xmit, most implimentations will assume congestion and back-off to maybe slow-start. Also, If the routers that had the flapping routes were in the MPLS domain and not OSPF enabled, then the OSPF area would be less chaotic. The fewer routers participating in the OSPF area would tend to have faster initial database synchronizations, etc. Sorry, group, this is condensed book format. Bottom line, in my experience MPLS tends to be faster, more efficient, higher achieveable bandwidth, etc, in a number of different envs including chaotic ones. And i'm a little confused: * Are you saying that that a strict MPLS LSP path can be duplicated with OSPF? * Are you saying that the forwarding decisions / advantages the 3rd bullet of MPLS in RFC 3031 is not true? "This can not be done with converntional forwarding, since the the identify of a packet's ingress router does not travel with the packet". Mitchell Erblich ---------------- David Charlap wrote: > > Erblichs wrote: > > > > I would like to remind people that MPLS can not > > be used without IP, however IP can be used without > > MPLS. > > This is not entirely true. Although MPLS is almost always used in > conjunction with IP, it doesn't have to be. For instance: > > - LSPs can be configured instead of signaled (much like how PVCs are > configured on ATM switches.) > > - Routing/topology information may be distributed using a non-IP routing > protocol, like IS-IS. (Although IS-IS is usually used to distribute > IP topology information, it uses ISO addresses, not IP addresses.) > > - Although today's MPLS signaling protocols (LDP and RSVP-TE) are both > tied to IP addressing, there is no reason why a non-IP signaling > protocol couldn't be developed for setting up LSPs. (For that matter, > RSVP-TE could even be extended to allow signaling over non-IP networks > (it would only require new C-Types for the SESSION, SENDER_TEMPLATE > and FILTER_SPEC objects and a few new subobjects for the > EXPLICIT_ROUTE and RECORD_ROUTE classes.) > > - Non-IP traffic may be (and sometimes is already) carried in LSPs. In > RSVP-TE, the layer-3 protocol is signaled in the SESSION_ATTRIBUTES > object. For layer-2 LSPs, an extra label (Martini or PWE3) may be > used to identify the traffic. > > > IPvX is a end to end forwarding environment where > > MPLS is only a router to router forwarding > > environment. > > Conventionally, yes. But there's no technical reason why a host > couldn't drive LSP creation. It isn't done because there isn't any need > for this, not because of any technical problems. > > > MPLS, is normally associated within a domain > > so that the edge routers need specialized > > features; i.e. translate IP headers into lables. > > Domain? What exactly do you mean by this? In the IP/internet world, a > domain is a DNS term that has no applicability to routing/signaling. > > In the ATM world, it refers to a group of routers that share routing > information together. The closest IP analog to an ATM domain would be > an autonomous system (AS). > > Although MPLS networks typically do not span across ASs, they can, in > theory. There is ongoing work to develop practical ways to make this a > practical reality. > > You are correct, however, that LERs (LSP edge routers) need the > capability to push/pop labels onto/from unlabeled packets. > > > Since routers within the MPLS doamin don't need the > > edge router capability, I would expect that this > > non feature could minimally reduce the cost. > > This was a concern in the not-too-recent past. Especially when using > MPLS software to retrofit legacy ATM gear (interfaces on ATM switches > typically don't have the capability to push/pop labels.) Today, > however, this is less of a concern, since all the major MPLS players are > making hardware with this capability. > > > IMO, a still important item that has been overlooked > > is the convergence time of some of the larger link-state > > environments and/or the newer wireless paths. I think > > that the label distribution mechanisms within MPLS > > probably are more efficient and can set up the > > paths quicker. This relates to fewer delays and > > lost pkts while routing environments are somewhat > > chaotic. > > MPLS, in a signaled environment, relies on an IGP. > > LDP allocates and distributes labels as routes are learned. > > RSVP-TE can't set up an LSP until routing converges. Either the ingress > node must compute a path to the destination or all the transit nodes > must be able to forward the Path messages to the destination using local > route tables. > > You can, of course, pre-configure LSPs to get around this, that > undermines many of the benefits of MPLS. > > > Also, the link state protocols (ISIS and OSPF) > > assume that ONE path is preferred, and this translates > > to adding single entries for a dst in the forwarding > > table. > > Not necessarily. Equal-cost multipath extensions are common in the > non-MPLS world. Providing alternate routing paths where they're not all > equal cost is uglier, of course. > > > With MPLS, it is possible to have numerous > > paths to a dst where non-equal paths exist. This > > would allow a set of equal dst pkts (FEC) to traverse > > different paths based on different characteristics. > > These characteristics could be different ISP > > origination src addrs, bandwidth, delay, priority, > > SLAs, etc. > > You can do this without MPLS, but it requires all your routers to > classify all the packets and classify them according to the same set of > rules. It's inefficient (and probably will limit your throughput) but > it can be done. > > The big deal about MPLS isn't that you can do anything new, but that all > of the work in classifying the packets is focussed entirely in the edge > router (where bandwidths are probably lower) so that the core (where > bandwidth is higher) doesn't have to do this work. > > -- David > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 13 05:35:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06178; Wed, 13 Oct 2004 05:35:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHfil-0000JZ-Mn; Wed, 13 Oct 2004 05:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfPe-0001qN-HD; Wed, 13 Oct 2004 05:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfKv-0006I3-9c for mpls@megatron.ietf.org; Wed, 13 Oct 2004 05:22:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05341 for ; Wed, 13 Oct 2004 05:22:17 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHfVm-000059-4R for mpls@ietf.org; Wed, 13 Oct 2004 05:33:34 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 13 Oct 2004 10:22:43 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Oct 2004 10:22:42 +0100 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] mpls vs IPv6 Date: Wed, 13 Oct 2004 10:22:42 +0100 Message-ID: Thread-Topic: [mpls] mpls vs IPv6 Thread-Index: AcSwvn+lEkPtFXBXSlK57AIP8S965AAOholg To: , X-OriginalArrivalTime: 13 Oct 2004 09:22:42.0782 (UTC) FILETIME=[31462FE0:01C4B106] X-Spam-Score: 0.3 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable Mitchell, > I was trying to generalize about arch and > implimentations within the equiv of a 1 pager > and and not try to write a book on the diffs. > People can read all the RFCs if they want book=20 > format! This doesn't help anyone if your generalisations are incorrect. > Yes, LDP leans routes, however, the LDP keeps > the same routes until explicitly torn down. LDP is a signalling protocol used to signal MPLS labels associated with = FECs, it does not learn routes. Routes are learned via a dynamic routing = protocol, e.g. OSPF, or may be statically configured. LDP keeps labels = (not routes) until a next hop changes, e.g. following link loss, routing = protocol session loss, router failure, or if a better next-hop becomes = available, etc. =09 > In a chaotic IP forwarding env, if the routes > constantly change and the in-flight pkts/segments > are backed by TCP, their will be constant=20 > re-ordering of the segs. Most implimentations > will respond with the re-ordering by seeing > 3 duplicate acks and will do un-necessary > fast re-transmits / spurious rexmits. In addition > to consuming bandwidth, convergence time, etc, > at the the time of the fast re-xmit, most > implimentations will assume congestion and back-off > to maybe slow-start.=20 I don't understand the relevance of this statement. Are you suggesting = that if the routing protocol is unstable then LDP somehow improves = things? If so how? Bearing in mind that LDP tracks the IGP, i.e. if the = IGP next hop changes then so does the LDP LSP. > Also, If the routers that had the flapping routes > were in the MPLS domain and not OSPF enabled, then the > OSPF area would be less chaotic. The fewer routers > participating in the OSPF area would tend to have > faster initial database synchronizations, etc. > Sorry, group, this is condensed book format. I don't understand this statement at all. If the routers are in the MPLS = domain and not OSPF enabled then are they running another routing = protocol or are they statically configured? Obviously if there are less = routers in an OSPF domain then it is likely to converge faster, but what = has this got to do with MPLS or LDP? > Bottom line, in my experience MPLS tends to be > faster, more efficient, higher achieveable bandwidth, > etc, in a number of different envs including chaotic > ones. Faster in what respect? What is it that is more efficient? What does higher achievable bandwidth mean? This statement has no value unless qualified with the specific MPLS = techniques/protocols used. For example, fast failover is dependant on = the protocols used and how they are deployed, just because an network = uses MPLS does not automatically mean that it is recovers from failure = faster than an IP network.=20 =09 > And i'm a little confused: >=20 > * Are you saying that that a strict MPLS LSP > path can be duplicated with OSPF?=20 OSPF is a dynamic routing protocol where paths/routes change following = topology changes so obviously paths/routes are not strict, they are = dynamic. However, the story doesn't end there, if you are configuring = strict LSPs for TE purposes then IGP metric tuning can be used to = engineer the network to use bandwidth efficiently, as can ECMP. The = primary reasons for using TE tunnels is to support per tunnel CAC and to = support FRR. > * Are you saying that the forwarding decisions > / advantages the 3rd bullet of MPLS in RFC 3031 > is not true? > "This can not be done with converntional forwarding, > since the the identify of a packet's ingress router > does not travel with the packet". No, I do not believe David said that. He simply said that you don't have = to use MPLS to do this, reading the sentence before the one you quote = tells you this, i.e. "In conventional forwarding, this requires the = packet to carry an encoding of its route along with it ("source = routing").=20 Regards, Richard > Mitchell Erblich > ---------------- >=20 > David Charlap wrote: > >=20 > > Erblichs wrote: > > > > > > I would like to remind people that MPLS can not > > > be used without IP, however IP can be used without > > > MPLS. > >=20 > > This is not entirely true. Although MPLS is almost always used in > > conjunction with IP, it doesn't have to be. For instance: > >=20 > > - LSPs can be configured instead of signaled (much like how PVCs are > > configured on ATM switches.) > >=20 > > - Routing/topology information may be distributed using a=20 > non-IP routing > > protocol, like IS-IS. (Although IS-IS is usually used=20 > to distribute > > IP topology information, it uses ISO addresses, not IP=20 > addresses.) > >=20 > > - Although today's MPLS signaling protocols (LDP and=20 > RSVP-TE) are both > > tied to IP addressing, there is no reason why a non-IP signaling > > protocol couldn't be developed for setting up LSPs. =20 > (For that matter, > > RSVP-TE could even be extended to allow signaling over=20 > non-IP networks > > (it would only require new C-Types for the SESSION,=20 > SENDER_TEMPLATE > > and FILTER_SPEC objects and a few new subobjects for the > > EXPLICIT_ROUTE and RECORD_ROUTE classes.) > >=20 > > - Non-IP traffic may be (and sometimes is already) carried=20 > in LSPs. In > > RSVP-TE, the layer-3 protocol is signaled in the=20 > SESSION_ATTRIBUTES > > object. For layer-2 LSPs, an extra label (Martini or=20 > PWE3) may be > > used to identify the traffic. > >=20 > > > IPvX is a end to end forwarding environment where > > > MPLS is only a router to router forwarding > > > environment. > >=20 > > Conventionally, yes. But there's no technical reason why a host > > couldn't drive LSP creation. It isn't done because there=20 > isn't any need > > for this, not because of any technical problems. > >=20 > > > MPLS, is normally associated within a domain > > > so that the edge routers need specialized > > > features; i.e. translate IP headers into lables. > >=20 > > Domain? What exactly do you mean by this? In the=20 > IP/internet world, a > > domain is a DNS term that has no applicability to routing/signaling. > >=20 > > In the ATM world, it refers to a group of routers that share routing > > information together. The closest IP analog to an ATM=20 > domain would be > > an autonomous system (AS). > >=20 > > Although MPLS networks typically do not span across ASs,=20 > they can, in > > theory. There is ongoing work to develop practical ways to=20 > make this a > > practical reality. > >=20 > > You are correct, however, that LERs (LSP edge routers) need the > > capability to push/pop labels onto/from unlabeled packets. > >=20 > > > Since routers within the MPLS doamin don't need the > > > edge router capability, I would expect that this > > > non feature could minimally reduce the cost. > >=20 > > This was a concern in the not-too-recent past. Especially=20 > when using > > MPLS software to retrofit legacy ATM gear (interfaces on=20 > ATM switches > > typically don't have the capability to push/pop labels.) Today, > > however, this is less of a concern, since all the major=20 > MPLS players are > > making hardware with this capability. > >=20 > > > IMO, a still important item that has been overlooked > > > is the convergence time of some of the larger link-state > > > environments and/or the newer wireless paths. I think > > > that the label distribution mechanisms within MPLS > > > probably are more efficient and can set up the > > > paths quicker. This relates to fewer delays and > > > lost pkts while routing environments are somewhat > > > chaotic. > >=20 > > MPLS, in a signaled environment, relies on an IGP. > >=20 > > LDP allocates and distributes labels as routes are learned. > >=20 > > RSVP-TE can't set up an LSP until routing converges. =20 > Either the ingress > > node must compute a path to the destination or all the transit nodes > > must be able to forward the Path messages to the=20 > destination using local > > route tables. > >=20 > > You can, of course, pre-configure LSPs to get around this, that > > undermines many of the benefits of MPLS. > >=20 > > > Also, the link state protocols (ISIS and OSPF) > > > assume that ONE path is preferred, and this translates > > > to adding single entries for a dst in the forwarding > > > table. > >=20 > > Not necessarily. Equal-cost multipath extensions are common in the > > non-MPLS world. Providing alternate routing paths where=20 > they're not all > > equal cost is uglier, of course. > >=20 > > > With MPLS, it is possible to have numerous > > > paths to a dst where non-equal paths exist. This > > > would allow a set of equal dst pkts (FEC) to traverse > > > different paths based on different characteristics. > > > These characteristics could be different ISP > > > origination src addrs, bandwidth, delay, priority, > > > SLAs, etc. > >=20 > > You can do this without MPLS, but it requires all your routers to > > classify all the packets and classify them according to the=20 > same set of > > rules. It's inefficient (and probably will limit your=20 > throughput) but > > it can be done. > >=20 > > The big deal about MPLS isn't that you can do anything new,=20 > but that all > > of the work in classifying the packets is focussed entirely=20 > in the edge > > router (where bandwidths are probably lower) so that the core (where > > bandwidth is higher) doesn't have to do this work. > >=20 > > -- David > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 13 10:32:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02387; Wed, 13 Oct 2004 10:32:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkLb-0006Jd-PY; Wed, 13 Oct 2004 10:43:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHk1F-0002Zp-KE; Wed, 13 Oct 2004 10:22:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjvz-0000aZ-SY for mpls@megatron.ietf.org; Wed, 13 Oct 2004 10:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00060 for ; Wed, 13 Oct 2004 10:16:50 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHk6r-0005yG-Gd for mpls@ietf.org; Wed, 13 Oct 2004 10:28:09 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i9DEGIr2011250 for ; Wed, 13 Oct 2004 10:16:18 -0400 (EDT) Received: from [169.144.136.107] (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24942 for ; Wed, 13 Oct 2004 10:16:17 -0400 (EDT) Message-ID: <416D38AF.4060106@marconi.com> Date: Wed, 13 Oct 2004 10:16:15 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] mpls vs IPv6 References: <416C2FB7.ED33760@earthlink.net> <416C3BEE.4070905@marconi.com> <416C7A38.99372004@earthlink.net> In-Reply-To: <416C7A38.99372004@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Richard Spencer wrote many good comments which I won't duplicate in my reply. Following are my comments. Erblichs wrote: > > I don't see how a OSPF pkt could recv a > different path (when only 1 best LS path exists) > other than the best path chosen for it by the > SPF algorithm. SPF may select more than one path. That's the whole point of ECMP - you use the topology learned by routing and select all of the shortest paths. The forwarding system can choose to use this information to do load balancing. > Same for IS-IS? Yes. > Same for RIP? Yes, but for obvious reasons, the concept of a "path" (best or otherwise) isn't meaningful in a RIP network. > Yes, LDP leans routes, however, the LDP keeps > the same routes until explicitly torn down. Read it again. It installs labels onto FECs. It learns FECs from an independant routing protocol. > And i'm a little confused: > > * Are you saying that that a strict MPLS LSP > path can be duplicated with OSPF? Not with OSPF alone, but it can be done without MPLS. That's the point of source routing. (Admittedly, source routing is inefficient. I don't think any forwarding chips today process this IP option.) > * Are you saying that the forwarding decisions > / advantages the 3rd bullet of MPLS in RFC 3031 > is not true? > "This can not be done with converntional forwarding, > since the the identify of a packet's ingress router > does not travel with the packet". Please read my statements in context. I was referring to this staement of yours: >>> With MPLS, it is possible to have numerous >>> paths to a dst where non-equal paths exist. This >>> would allow a set of equal dst pkts (FEC) to traverse >>> different paths based on different characteristics. >>> These characteristics could be different ISP >>> origination src addrs, bandwidth, delay, priority, >>> SLAs, etc. Without MPLS, you can also have numerous paths to a destination with non-equal paths. You use the same topology learned by routing (OSPF or ISIS - RIP doesn't learn any topologies) and run the SPF calculations on subsets of that topology, based on whatever packet classification filters you like. This is the definition of CSPF. As long as all of the routers have the same sets of filters/criteria configured, you'll get consistent routing, with different categories of packets going in different directions. MPLS makes this job much easier (by eliminating the need for all your core routers to do all this clarrification), but it isn't the only way to get the job done. -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 13 10:44:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04032; Wed, 13 Oct 2004 10:44:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkXa-0006Yo-JX; Wed, 13 Oct 2004 10:55:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkE3-0007Hg-VE; Wed, 13 Oct 2004 10:35:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkAl-0005m8-KV for mpls@megatron.ietf.org; Wed, 13 Oct 2004 10:32:11 -0400 Received: from huawei.com (mta2.huawei.com [61.144.161.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02229 for ; Wed, 13 Oct 2004 10:31:15 -0400 (EDT) Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5I00156XZC8M@mta2.huawei.com> for mpls@lists.ietf.org; Wed, 13 Oct 2004 21:11:37 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 82003)) with ESMTP id <0I5I007MVXZCLL@mta2.huawei.com> for mpls@lists.ietf.org; Wed, 13 Oct 2004 21:11:36 +0800 (CST) Received: from harishm ([10.18.4.198]) by mailin.huawei.com (Netscape Messaging Server 4.15)with ESMTP id I5IY6C00.O0I for ; Wed, 13 Oct 2004 21:15:48 +0800 Date: Wed, 13 Oct 2004 18:46:12 +0530 From: Harish M To: mpls@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Content-Transfer-Encoding: 7BIT Subject: [mpls] LMP - GMPLS X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: harishm@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT Hi, Referring to the draft-ietf_ccamp-lmp-10.txt "LinkSummary Message can have multiple DATA_LINK objects and each DATA_LINK object can have more than one variable length sub-object (for including multiple capabilities of a data link)." Since a LinkSummary Message can contain multiple DATA_LINK Objects (Class = 12) and as there is no field/mechanism to indicate the number of sub-objects under a DATA_LINK object, how can we know where the next DATA_LINK object starts ? ::= [...] --------------------------------------------------------------------------- | IP Header | UDP Header | LMP Header | LMP Object-1 | ... | LMP Object-n | --------------------------------------------------------------------------- Thanks, Harish M. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 13 16:03:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00913; Wed, 13 Oct 2004 16:03:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpWQ-00054l-EH; Wed, 13 Oct 2004 16:14:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpEJ-0007sM-DF; Wed, 13 Oct 2004 15:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHp5K-0002oE-VG for mpls@megatron.ietf.org; Wed, 13 Oct 2004 15:46:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28954 for ; Wed, 13 Oct 2004 15:46:55 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpGK-0004Wb-OX for mpls@ietf.org; Wed, 13 Oct 2004 15:58:18 -0400 Received: from du-069-0500.access.clara.net ([217.158.145.246] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.34) id 1CHp55-0004DC-B7; Wed, 13 Oct 2004 20:46:39 +0100 Message-ID: <067501c4b15d$67386300$21849ed9@Puppy> From: "Adrian Farrel" To: References: Subject: Re: [mpls] LMP - GMPLS Date: Wed, 13 Oct 2004 20:46:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Hi Harish, You might like to ask your question again on the CCAMP mailing list. (See http://www.ietf.org/html.charters/ccamp-charter.html) Thanks, Adrian > Referring to the draft-ietf_ccamp-lmp-10.txt > > "LinkSummary Message can have multiple DATA_LINK objects and each DATA_LINK > object can have more than one variable length sub-object (for including > multiple capabilities of a data link)." > > Since a LinkSummary Message can contain multiple DATA_LINK Objects (Class = > 12) and as there is no field/mechanism to indicate the number of sub-objects > under a DATA_LINK object, how can we know where the next DATA_LINK object > starts ? > > ::= > [...] > > --------------------------------------------------------------------------- > | IP Header | UDP Header | LMP Header | LMP Object-1 | ... | LMP Object-n | > --------------------------------------------------------------------------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 13 17:25:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12416; Wed, 13 Oct 2004 17:25:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHqny-0008BS-GD; Wed, 13 Oct 2004 17:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpx8-0002Te-7f; Wed, 13 Oct 2004 16:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpr4-0001Wh-LM for mpls@megatron.ietf.org; Wed, 13 Oct 2004 16:36:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04057 for ; Wed, 13 Oct 2004 16:36:14 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHq25-0005gk-8B for mpls@ietf.org; Wed, 13 Oct 2004 16:47:38 -0400 Received: from user-2ivfjc5.dialup.mindspring.com ([165.247.205.133] helo=earthlink.net) by pop-a065d23.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CHpqw-0003BT-00; Wed, 13 Oct 2004 13:36:07 -0700 Message-ID: <416D920E.44A96D6C@earthlink.net> Date: Wed, 13 Oct 2004 13:37:34 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: richard.spencer@bt.com Subject: Re: [mpls] mpls vs IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, David.Charlap@marconi.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit richard.spencer@bt.com wrote: > > Mitchell, > > > I was trying to generalize about arch and > > implimentations within the equiv of a 1 pager > > and and not try to write a book on the diffs. > > People can read all the RFCs if they want book > > format! > > This doesn't help anyone if your generalisations are incorrect. > > > >This is not entirely true. Although MPLS is almost always used in > > > conjunction with IP, it doesn't have to be. Sorry, I live in the real-world. How many implimentations ignore IP? What is the percentage of non-IP networks? And yes, their are always exceptions to the rule and we should be aware of them. > > > Conventionally, yes. We are discussing real world implimentations against the archs, not possible implimentations that don't exist... However, yes I do think it somewhat beneficial to specify the CURRENT implimentations are not necessarily limited by the archs and that a future implimentaions ?MAY? remove these limitiations.. Enough said by me on this thread, MPLS is here and their are pros and cons to using it.... Mitchell Erblich ------------------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 14 02:03:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27202; Thu, 14 Oct 2004 02:03:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHysg-0001p1-2o; Thu, 14 Oct 2004 02:14:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHygC-0003oL-0w; Thu, 14 Oct 2004 02:01:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHyf7-00039B-7e for mpls@megatron.ietf.org; Thu, 14 Oct 2004 02:00:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24565 for ; Thu, 14 Oct 2004 02:00:27 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHyqC-0001lq-96 for mpls@ietf.org; Thu, 14 Oct 2004 02:11:57 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9E5xrxZ005443 for ; Thu, 14 Oct 2004 00:59:55 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id <4M31A3CA>; Thu, 14 Oct 2004 11:29:53 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D20B4917B2@ii0015exch002u.iprc.lucent.com> From: "Kulkarni, Hrishikesh (Hrishikesh)" To: mpls@ietf.org Date: Thu, 14 Oct 2004 11:29:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [mpls] Label Space Query X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi all, Does LDP or RSVP provide a method to signal a label as a per-interface or per-platform label? PWE3 signaling assumes that a PSN tunnel is available before setting up a PWE3. But is there way to signal an inner label as per-interface or per-platform between two peers, already connected by PSN tunnel. thanks rishi. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 14 07:21:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01959; Thu, 14 Oct 2004 07:21:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI3rF-0007Yx-P7; Thu, 14 Oct 2004 07:33:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3cB-0000fe-EV; Thu, 14 Oct 2004 07:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3Y5-0008Gs-3q for mpls@megatron.ietf.org; Thu, 14 Oct 2004 07:13:33 -0400 Received: from web25202.mail.ukl.yahoo.com (web25202.mail.ukl.yahoo.com [217.12.10.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01449 for ; Thu, 14 Oct 2004 07:13:29 -0400 (EDT) Message-ID: <20041014111301.88211.qmail@web25202.mail.ukl.yahoo.com> Received: from [194.237.142.7] by web25202.mail.ukl.yahoo.com via HTTP; Thu, 14 Oct 2004 13:13:01 CEST Date: Thu, 14 Oct 2004 13:13:01 +0200 (CEST) From: giu sep To: mpls@ietf.org MIME-Version: 1.0 Subject: [mpls] resilience and survivable X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0676170967==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe --===============0676170967== Content-Type: multipart/alternative; boundary="0-874977056-1097752381=:86726" --0-874977056-1097752381=:86726 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA01449 Content-Transfer-Encoding: quoted-printable Hi all, =20 can someone give me some indication where is it possible found links (or papers) about RESILIENCE and SURVIVABLE NETWORKING ? I'd like know what is the state of art about this topics. =20 I'm interested both network and transport features. =20 thank you in adavance Sal =09 --------------------------------- Nuovo Yahoo! Messenger E' molto pi=F9 divertente: Audibles, Avatar, Webca= m, Giochi, Rubrica=85 Scaricalo ora!=20 --0-874977056-1097752381=:86726 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA01449 Content-Transfer-Encoding: quoted-printable
Hi all,
 
can someone give me some indication where is it possible
found links (or papers) about RESILIENCE and SURVIVABLE NE= TWORKING ?
I'd like know what is the state of art about this topics.
 
I'm interested  both network and transport features.
 
thank you in adavance
Sal

=09 =09

Nuovo Yahoo! Mes= senger E' molto pi=F9 divertente: Audibles, Avatar, Webcam, Gioch= i, Rubrica=85 Scaricalo ora!=20 --0-874977056-1097752381=:86726-- --===============0676170967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0676170967==-- From mpls-bounces@ietf.org Thu Oct 14 10:48:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26262; Thu, 14 Oct 2004 10:48:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI75O-0003tJ-TK; Thu, 14 Oct 2004 11:00:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6rN-0002TB-Lv; Thu, 14 Oct 2004 10:45:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6j5-0008HN-6r for mpls@megatron.ietf.org; Thu, 14 Oct 2004 10:37:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24810 for ; Thu, 14 Oct 2004 10:37:04 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI6uC-0003bz-UB for mpls@ietf.org; Thu, 14 Oct 2004 10:48:40 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9EEaUG8003323 for ; Thu, 14 Oct 2004 09:36:31 -0500 (CDT) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M3HNV9K>; Thu, 14 Oct 2004 10:36:30 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "Kulkarni, Hrishikesh (Hrishikesh)" , mpls@ietf.org Subject: RE: [mpls] Label Space Query Date: Thu, 14 Oct 2004 10:36:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Rishi, I have a comment on your statements regarding PWE. Please see below. Peter > -----Original Message----- > From: Kulkarni, Hrishikesh (Hrishikesh) [mailto:hkulkarni@lucent.com] > Sent: Thursday, October 14, 2004 2:00 AM > To: mpls@ietf.org > Subject: [mpls] Label Space Query > > > Hi all, > > Does LDP or RSVP provide a method to signal a label as a > per-interface or > per-platform label? > > PWE3 signaling assumes that a PSN tunnel is available before > setting up a > PWE3. I don't think that is true. The PWE3 drafts are not very clear on this subject, but you could read section 2 of draft-ietf-pwe3-control-protocol-11.txt as a reference. It mentions that a PSN tunnel is not required if a PW is setup between adjacent nodes. Furthermore, it does not say that a PSN tunnel must be available when a PW is set up. It merely mentions that a PSN Tunnel must be available when packets are forwarded from one PW end-point to another. In other words, two PEs could establish a PW before they establish a PSN Tunnel, as long as they don't transmit packets. In general, in MPLS networks, the notion of binding inner labels to outer labels is meaningless, because Pen-ultimate Hop Popping will lead to removal of the outer label before the packet reaches the tunnel endpoint. > But is there way > to signal an inner label as per-interface or per-platform > between two peers, > already connected by PSN tunnel. > > > thanks > rishi. > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 14 11:27:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29910; Thu, 14 Oct 2004 11:27:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7gs-0004fv-4t; Thu, 14 Oct 2004 11:38:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7SY-0005rv-SG; Thu, 14 Oct 2004 11:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7Rz-0005cf-DN for mpls@megatron.ietf.org; Thu, 14 Oct 2004 11:23:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29687 for ; Thu, 14 Oct 2004 11:23:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7dA-0004bl-Sw for mpls@ietf.org; Thu, 14 Oct 2004 11:35:05 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i9EFMur2010449 for ; Thu, 14 Oct 2004 11:22:57 -0400 (EDT) Received: from [169.144.136.107] (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22896 for ; Thu, 14 Oct 2004 11:22:56 -0400 (EDT) Message-ID: <416E99CF.2010505@marconi.com> Date: Thu, 14 Oct 2004 11:22:55 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 0.8 (Windows/20041011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] Label Space Query References: <6733C768256DEC42A72BAFEFA9CF06D20B4917B2@ii0015exch002u.iprc.lucent.com> In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D20B4917B2@ii0015exch002u.iprc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Kulkarni, Hrishikesh (Hrishikesh) wrote: > > Does LDP or RSVP provide a method to signal a label as a per-interface or > per-platform label? RSVP-TE (as defined in RFC 3209) does not provide a means to request a per-interface or per-platform label. Using label recording (the label subobject of RECORD_ROUTE) you can know if an allocated label is global (per-platform) or not on a given node along the path. There may be RSVP-TE extension drafts/RFCs that I'm unaware of that change this, however. -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 14 17:06:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03725; Thu, 14 Oct 2004 17:06:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICze-000550-61; Thu, 14 Oct 2004 17:18:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICNx-0006sJ-Uy; Thu, 14 Oct 2004 16:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC5S-0000Qh-MI; Thu, 14 Oct 2004 16:20:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25635; Thu, 14 Oct 2004 16:20:32 -0400 (EDT) Message-Id: <200410142020.QAA25635@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 14 Oct 2004 16:20:32 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lc-if-mib-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition Author(s) : T. Nadeau, S. Hegde Filename : draft-ietf-mpls-lc-if-mib-04.txt Pages : 19 Date : 2004-10-14 This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label switching controlled Frame-Relay and ATM interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lc-if-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-14164553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lc-if-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lc-if-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-14164553.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Fri Oct 15 11:41:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14372; Fri, 15 Oct 2004 11:41:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUOQ-0002XD-Cw; Fri, 15 Oct 2004 11:53:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIU3N-00052K-FR; Fri, 15 Oct 2004 11:31:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITw2-00049U-BX for mpls@megatron.ietf.org; Fri, 15 Oct 2004 11:24:02 -0400 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12527 for ; Fri, 15 Oct 2004 11:23:59 -0400 (EDT) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CITnv-0002aA-4n; Fri, 15 Oct 2004 11:15:39 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 15 Oct 2004 11:15:39 -0400 Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Fast Reroute Extensions to RSVP-TE for LSP Tunnels' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 The IESG has approved the following document: - 'Fast Reroute Extensions to RSVP-TE for LSP Tunnels ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This document defines extensions to and describes the use of RSVP to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either or both methods and to interoperate in a mixed network. Working Group Summary Several years before work began on this draft, operational networks had deployed two independent methods of doing fast reroute, called herein one-to-one backup and facility backup. Vendors trying to support both methods were experiencing incompatiblity problems in attempting to produce a single implementation capable of interoperating with both. There are technical tradeoffs between the methods. However these tradeoffs are so topologically dependent, that the community has not converged on a single approach. Both methods are considered necessary to cover different topological scenarios. Protocol Quality The specification has been reviewed for the IESG by Alex Zinin. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 15 12:44:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18959; Fri, 15 Oct 2004 12:44:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVNY-0003tW-Sh; Fri, 15 Oct 2004 12:56:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIV6F-0003wI-Oh; Fri, 15 Oct 2004 12:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUz7-0002QP-Tw for mpls@megatron.ietf.org; Fri, 15 Oct 2004 12:31:17 -0400 Received: from apollo.serverbox.net (apollo.serverbox.net [207.58.128.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17884 for ; Fri, 15 Oct 2004 12:31:14 -0400 (EDT) Received: (qmail 30333 invoked from network); 15 Oct 2004 16:31:12 -0000 Received: from unknown (HELO PC.opalsoft.net) (201.243.149.192) by apollo.serverbox.net with SMTP; 15 Oct 2004 16:31:12 -0000 Message-Id: <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 15 Oct 2004 10:33:51 -0400 To: mpls@ietf.org From: Leonardo Balliache Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [mpls] Some question about LDP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Hi, all, Hoping Loa can help me with these questions. I'm trying to implement LDP in the ns-2 simulator. It has already an implementation but I want something closer to the specification. I tell this to take for granted that I'm not working in any commercial implementation. My questions refer to the specification, and are: ** Q1.- Here Propagating is set in independent control but not in ordered control; but it is used as parameter in ordered control below. A.1.1. Receive Label Request ........... LRq.9 Perform LSR Label Distribution procedure: For Downstream Unsolicited Independent Control OR For Downstream On Demand Independent Control 1. Has LSR previously received and retained a label map- ping for FEC from Next Hop?. Is so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating. 2. Execute procedure Prepare_Label_Map- ping_Attributes(MsgSource, FEC, RAttributes, SAt- tributes, Propagating, StoredHopCount). 3. Execute procedure Send_Label (MsgSource, FEC, SAt- tributes). 4. Is LSR egress for FEC? OR Has LSR previously received and retained a label map- ping for FEC from Next Hop? If so, goto LRq.11. If not, goto LRq.10. For Downstream Unsolicited Ordered Control OR For Downstream On Demand Ordered Control 1. Is LSR egress for FEC? OR Has LSR previously received and retained a label map- ping for FEC from Next Hop? (See Note 3.) If not, goto LRq.10. 2. Execute procedure Prepare_Label_Map- ping_Attributes(MsgSource, FEC, RAttributes, SAt- tributes, IsPropagating, StoredHopCount) 3. Execute procedure Send_Label (MsgSource, FEC, SAt- tributes). Goto LRq.11. ** Q2.- Here, in PMpA.7, Hop Count in RAttribute is incremented but it is used then in PMpA.14. In this (14), Hop Count to be used is the original Hop Count in RAttribute or the incremented value in PMpA.7? A.2.8. Prepare_Label_Mapping_Attributes ......... PMpA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. See Note 2. Goto PMpA.9. PMpA.8 Include Hop Count of unknown (0) in SAttributes. PMpA.9 Is Loop Detection configured on LSR? If not, goto PMpA.21. PMpA.10 Do RAttributes have a Path Vector? If so, goto PMpA.19. PMpA.11 Is LSR propagating a received Label Mapping? If not, goto PMpA.20. PMpA.12 Does LSR support merging? If not, goto PMpA.14. PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer? If not, goto PMpA.20. PMpA.14 Do RAttributes include a Hop Count? If not, goto PMpA.21. PMpA.15 Is Hop Count in Rattributes unknown(0)? If so, goto PMpA.20. ** Q3.- I've got some problem interpreting the sentences "Install label" as below: ....... LRq.12 Perform LSR Label Use procedure. For Use Immediate OR For Use If Loop Not Detected 1. Install label sent to MsgSource and label from Next Hop (if LSR is not egress) for forwarding/switching use. ....... LMp.15 Install Label for forwarding/switching use. ....... 2. Install label received and label sent to Peer for forwarding/switching use. SL.3 Install Label for forwarding/switching use. ....... As I understand MPLS we should have three tables: NHLFE, FTN and ILM. FTN contains fecs and points to NHLFE. Then, it should have the information about the incoming interface to have the tuple ; Wed, 13 Oct 2004 07:06:18 -0400 (EDT) Received: from muenchner-kreis.de ([129.187.9.137] helo=atlantis.lkn.ei.tum.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHh8S-0001nL-Gk for mpls@ietf.org; Wed, 13 Oct 2004 07:17:37 -0400 Received: from lkn.e-technik.tu-muenchen.de (aperol.lkn.ei.tum.de [10.152.4.5]) by atlantis.lkn.ei.tum.de (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i9DB61g5009356 for ; Wed, 13 Oct 2004 13:06:01 +0200 Received: from [10.152.4.62] (mojito [10.152.4.62]) by lkn.e-technik.tu-muenchen.de (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i9DB61gQ030371 for ; Wed, 13 Oct 2004 13:06:01 +0200 Message-ID: <416D0C14.9000607@tum.de> Date: Wed, 13 Oct 2004 13:05:56 +0200 From: Claus Gruber User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [mpls] mpls vs IPv6 References: <416C2FB7.ED33760@earthlink.net> <416C3BEE.4070905@marconi.com> <416C7A38.99372004@earthlink.net> In-Reply-To: <416C7A38.99372004@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 16 Oct 2004 08:16:09 -0400 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Hello group, > * Are you saying that that a strict MPLS LSP > path can be duplicated with OSPF? > > In OSPF and its extension ECMP (Equal Cost Multi Path) multiple paths towards one destination IP address are possible. The traffic is distributed equally. I.e. if there are three shortest paths (equal length) traffic is distributed 33%/33%/33% on outgoing interfaces. The traffic is distributed using a flow-based hash function ('per destination') to keep the ordering of packets of one flow (TCP problem) or in a round robin manner ('per packet'). Using the configurable OSPF link weights many MPLS paths can be duplicated with OSPF. However, MPLS has the advantage to distinguish packets (treat differently) towards the same destination IP address that are entering the network at different edge routers. Additionally an unequal traffic distribution on multiple (not shortest) paths is possible. (Note: A different routing for packets belonging to differnt type of service classes was included in OSPF v1 but is no longer included in OSPF v2 RFC) With this, MPLS has an advantage considering traffic engineering. However, if a network operator optimizes the OSPF link metrics the difference is not that big for working traffic (without a failure). I did some optimizations both for ECMP and MPLS indicating this. However, I think the main advantage of MPLS is the possibility for resilience. OSPF as well as IS-IS or RIB, ... are distributed protocols. In case of a network element failure it takes some time until failure notifications (LSAs) are broadcast and all routers have updated their forwarding table (with transient effects: loops). When tuning timers it is however possible to reduce the convergence time of OSPF or IS-IS to some hundred milliseconds even for larger networks. I did simulations and I think SPRINT reported sub-second convergence times with patched Cisco routers already. With MPLS one is able to prepare for a failure and establish backup paths in advance of possible failure patterns (e.g. Fast Reroute configuration). This is - at least to my knowledge - not possible with OSPF since it is a distributed protocol and there is only one valid forwarding table in a router. MPLS thus, is able to react locally and prepared (backup path already defined - "protection') upon failures which is of course faster (some tens of ms) than a distributed restoration approach. The main advantage is the distribution of the backup traffic. After failure detection and rerouting new paths are calculated according to the old link metrics in OSPF. These metrics however were adapted for working traffic and might not be well fitted for the new (reduced) topology. MPLS backup paths can be chosen independently of the working paths (without a failure). Optimization results showed that MPLS has advantages considering required capacity. And: A (good) optimization of link metrics and MPLS paths takes its time. In MPLS this can be performed offline for probable failure patterns. If one might change an MPLS path this path is affected only. When changing OSPF link metrics routes towards different destinations are changed and cannot be changed only for one destination or for one ingress-egress relation. This makes optimization and TE more complex. As a summary: - MPLS has potentially shorter convergence times (allows local protection). - Not much difference in TE for working traffic results (at least as far as I calculated and know) - MPLS allows an independent traffic engineering for resilience issues (including failure patterns) - Adaptive traffic engineering is possible without potentially changing a lot of routes towards multiple destinations. - Forwarding is 'wire speed' both for IP and MPLS today. - Virtual Private Networks (VPNs) are easy to deploy with MPLS. - MPLS paths traversing multiple ASs are in development. - MPLS Multicast is in development. As a drawback: MPLS is an add-on technology and if not configured static a kind of IGP to detect topology is required. Paths have to be refreshed and additional switching tables are required in each router. Sprint has some very nice white papers (to be found on their homepage): Summary: MPLS is good and has advantages - currently we can do what we need and want with tuned OSPF. It depends on the requirements... but MPLS has many advantages. Regards, Claus -- ______________________________________________________________________ Claus Gruber Institute of Communication Networks Phone: +49 89 289 23508 Munich University of Technology Fax: +49 89 289 23523 Building 9, Room 1932 mailto:claus.gruber@tum.de Arcisstr. 21, D-80290 Muenchen http://www.lkn.ei.tum.de/~claus ______________________________________________________________________ _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Oct 16 09:10:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19252; Sat, 16 Oct 2004 09:10:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIoVo-0006O9-4w; Sat, 16 Oct 2004 09:22:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIoGV-0002bi-5t; Sat, 16 Oct 2004 09:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIoF4-0002Ep-Tj for mpls@megatron.ietf.org; Sat, 16 Oct 2004 09:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18830 for ; Sat, 16 Oct 2004 09:05:00 -0400 (EDT) Received: from host19.ipowerweb.com ([66.235.218.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIoQe-0006Gu-0d for mpls@ietf.org; Sat, 16 Oct 2004 09:17:01 -0400 Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.61.197.198] helo=[127.0.0.1]) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 1CIoES-0005nF-00; Sat, 16 Oct 2004 06:04:24 -0700 Message-ID: <41711C42.6070103@GraIyMage.com> Date: Sat, 16 Oct 2004 09:04:02 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Leonardo Balliache Subject: Re: [mpls] Some question about LDP References: <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> In-Reply-To: <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - GraIyMage.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Leonardo, See below... Leonardo Balliache wrote: > [.. SNIP ..] > > My questions refer to the specification, and are: > > ** Q1.- Here Propagating is set in independent control but not in > ordered control; but it is used as parameter in ordered control below. > > [.. SNIP ..] I am not sure what the question related to in all the steps included, but the setting of control mode is a "local" phenom and the fact that the local LSR is operating in independent control does not prevent it from getting label requests from upstream LSRs, or label mappings from downstream LSRs that _are_ operating in ordered control mode. > > > ** Q2.- Here, in PMpA.7, Hop Count in RAttribute is incremented but it > is used then in PMpA.14. In this (14), Hop Count to be used is the > original Hop Count in RAttribute or the incremented value in PMpA.7? > > [ .. SNIP ..] Hop count is incremented and then copied in PMpA.7. That means the value left in RAttribute is the incremented value. The wording is quite clear, given a number of other ways it could have been put. The value is next used in PMpA.18 (not 14) and it should be clear from context, that we are trying to determine if the value we would send (which is stored in SAttribute) is different than the value we have previously sent. Consequently, we are comparing RAttribute->hopCount with prevHopCount, _because_ we know from step PMpA.7 that the values RAttibute->hopCount=SAttribute->hopCount. Bear in mind that it is not the intention that this appendix is supposed to be treated as "pseudo-code". It may - in fact - include operations which are more or less intentionally not exactly the same as might appear in a specific implementation. > > ** Q3.- I've got some problem interpreting the sentences "Install > label" as below: > > [.. SNIP ..] > > As I understand MPLS we should have three tables: NHLFE, FTN and ILM. > > FTN contains fecs and points to NHLFE. Then, it should have the > information about the incoming interface to have the tuple incoming_itfc). > > ILM contains labels and points to NHLFE too. Then it should have the > information about the incoming interface to have the tuple incoming_itfc). > > NHLFE should have the information about the outgoing label (if it is > required or the null (0) label to indicate that the last label must be > popped to expose the L3-header), the outgoing interface and the > operation to be done (push, swap, pop) to have the tuple outgoing_itfc, operation). > > Then, I'm not very sure how to interpret the sentences above ordering > to "install label". Could you be a little bit more explicit about this > information? Understand that FTN, ILM, NHLFE, etc. are terms used in various MPLS specifications to describe the internal logical operations as they must appear externally. There are any number of ways that the actual implementation may be done so that it looks - from outside the box - as if it is done this way. I believe that "installing the label" is fairly clear, but to make it even clearer, it means the following: 1) if this LSR is an intermediate LSR with respect to the LSP for which this label is defined, do whatever it is in your implementation that corresponds to adding a new (or modifying an existing) ILM to point to an NHLFE that includes the corresponding downstream next hop, label, encaps, etc. 2) if this LSR is an ingress LSR with respect to the LSP for which a label is being defined, do whatever it is in your implementation that corresponds to adding a new (or modifying an existing) FTN to point to an NHLFE that includes the corresponding downstream next hop, label, encaps, etc. 3) if this LSR is an (effective) egress LSR with respect to the LSP for which a label is being defined, do whatever it is in your implementation that corresponds to either adding a new (or modifying an existing) ILM to point to an NHLFE that includes the corresponding downstream next hop, encaps, etc. - and no label - or an ILM that instructs the receiving hardware to strip the label and present the remaining packet for further processing (depending on whether the label stripped was the bottom of the label stack). In essense, instead of saying "do whatever it is ...", the specification says "install the label". I believe this is reasonable license. -- Eric > > Best regards, > > Leonardo Balliache > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Oct 18 18:05:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28681; Mon, 18 Oct 2004 18:05:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfp6-0002v6-Ou; Mon, 18 Oct 2004 18:17:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJewE-0006Ej-M0; Mon, 18 Oct 2004 17:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJec4-0002HY-S1 for mpls@megatron.ietf.org; Mon, 18 Oct 2004 17:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22882 for ; Mon, 18 Oct 2004 17:00:08 -0400 (EDT) Received: from evita2.cs.fredonia.edu ([141.238.30.15] helo=evita3.cs.fredonia.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeo1-0001Pd-Lq for mpls@ietf.org; Mon, 18 Oct 2004 17:12:39 -0400 Received: from zubairi (zubairi.cs.fredonia.edu [141.238.30.211]) by evita3.cs.fredonia.edu (8.10.2/8.10.2) with SMTP id i9IKxWc27221 for ; Mon, 18 Oct 2004 16:59:32 -0400 Message-ID: <001901c4b555$61fd62e0$d31eee8d@zubairi> From: "Junaid Ahmed Zubairi" To: Date: Mon, 18 Oct 2004 16:59:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Subject: [mpls] Telecom Symposium Paper Due Nov 1 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junaid Ahmed Zubairi List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Call for Papers 2005 Applied Telecommunication Symposium (ATS'05) +---------------------------------------------------------------------+ |"Modeling and Simulation Challenges in Telecommunication Systems" | +---------------------------------------------------------------------+ Part of the 2005 Spring Simulation Multiconference (SpringSim'05) Sponsored by: The Society for Modeling and Simulation International (SCS) April 2 - 8, 2005 Hilton Mission Valley Hotel San Diego, CA The Applied Telecommunication Symposium (ATS) is an international forum for exchange of technical knowledge and presentation of original papers on the analysis of telecommunication systems and technologies. It is intended for professionals, engineers, software developers, managers, and others interested in cellular and packet traffic characteristics, analysis of telecommunication networks, and practitioners operating telecommunication networks. We are looking for innovative technical papers describing projects, applications, and research and development work pertinent to telecommunication. This year's Symposium is particularly seeking papers in the following tracks: Wireless Chairs: Hassan Rajaei, Bowling Green State University, USA Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany Topics: UMTS GSM / CDMA 2.5G/3G Wireless Mobile Internet and Wireless Multimedia Cell Traffic Network Performance and Engineering Measurements SPECIAL SESSION: WLAN research with particular emphasis on QoS, routing, reliability, overload/congestion control, and interworking with 2.5/3G systems. Telecommunications Business and Regulation Chair: George Kraft, Stuart School of Business, Illinois Institute of Technology, USA Topics: Cost modeling Call center operations Billing models E-commerce Network Security and Management Chairs: Susan Lincke-Salecker, University of Wisconsin-Parkside, USA John Laskar, Mitretek Systems, USA Topics: Innovative Network Security methods WLAN Security Influence of security measures on network performance Operations, Administration, Maintenance Overload/congestion control Load balancing Networks and Multimedia Chairs: Aftab Ahmad, Norfolk State University, USA Wolfang Haidegger, Siemens, Austria Topics: Internet QoS Architectures Network performance - analysis and simulation Traffic characterization Packet switch architecture evaluation Modeling Techniques and V&V Chairs: Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany Shakil Akhtar, UAE University, Al-Ain, United Arab Emirates Topics: Simulation techniques Acceleration methods Distributed Simulation Simulation Tools for Modeling and V & V traffic measurements, analysis and synthesis Combined simulation/analytic procedures Metro area design and modeling Traffic Engineering with Protocols and Devices Chairs: Junaid Zubairi, SUNY at Fredonia, USA Co-chair: Chia J. Liu, AT&T Labs, USA Topics: Traffic Management and control Traffic engineering architectures Bandwidth management GMPLS VPN (Virtual Private Network) Performance Issues General Chair: Bohdan Bodnar Motorola, Inc. Co-Chair: Hassan Rajaei Bowling Green State University, USA Program Chair: George Kraft Stuart School of Business, Illinois Institute of Technology, USA Draft Paper / Extended Abstract Submission Deadline: November 1, 2004. Please indicate in the abstract for which track(s) you wish to have your paper considered; note that the final track selection will be at the discretion of the ATS organizers. The abstract must include the author(s), e-mail address(es), and affiliation. Sponsored by The Society for Modeling and Simulation International P.O. Box 17900 San Diego, California 92177 Phone 858-277-3888 Fax 858-277-3930 E-mail scs@scs.org *********************************************************** Dr. Junaid Ahmed Zubairi Department of Computer Science SUNY at Fredonia, Fredonia, NY 14063, USA. Tel: (716)673-4694 WWW: http://www.cs.fredonia.edu/~zubairi Email: zubairi@fredonia.edu *********************************************************** *********************************************************** Dr. Junaid Ahmed Zubairi Department of Computer Science SUNY at Fredonia, Fredonia, NY 14063, USA. Tel: (716)673-4694 WWW: http://www.cs.fredonia.edu/~zubairi Email: zubairi@fredonia.edu *********************************************************** _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 19 21:58:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14881; Tue, 19 Oct 2004 21:58:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5wN-0002xq-RH; Tue, 19 Oct 2004 22:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK40E-00078G-86; Tue, 19 Oct 2004 20:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJuca-0004s6-A6 for mpls@megatron.ietf.org; Tue, 19 Oct 2004 10:05:52 -0400 Received: from apollo.serverbox.net (apollo.serverbox.net [207.58.128.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27072 for ; Tue, 19 Oct 2004 10:05:44 -0400 (EDT) Received: (qmail 24901 invoked from network); 19 Oct 2004 14:04:22 -0000 Received: from unknown (HELO PC.opalsoft.net) (201.243.149.192) by apollo.serverbox.net with SMTP; 19 Oct 2004 14:04:22 -0000 Message-Id: <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 19 Oct 2004 10:10:08 -0400 To: ewgray@GraIyMage.com From: Leonardo Balliache Subject: Re: [mpls] Some question about LDP In-Reply-To: <41711C42.6070103@GraIyMage.com> References: <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Eric, Thanks a lot for your answer. But let me the right to insist: >I am not sure what the question related to in all the steps included, but >the setting of control mode is a "local" phenom and the fact that the local >LSR is operating in independent control does not prevent it from getting >label requests from upstream LSRs, or label mappings from downstream >LSRs that _are_ operating in ordered control mode. I think I didn't explain well. Here I copy again the spec and my code. I understand that the spec is not a pseudo-code but it is so specific that I'm not sure (I'm trying yet to understand well the logic) if this observation is important: The spec: A.1.1. Receive Label Request ........... LRq.9 Perform LSR Label Distribution procedure: For Downstream Unsolicited Independent Control OR For Downstream On Demand Independent Control 1. Has LSR previously received and retained a label map- ping for FEC from Next Hop?. Is so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating. 2. Execute procedure Prepare_Label_Map- ping_Attributes(MsgSource, FEC, RAttributes, SAt- tributes, Propagating, StoredHopCount). 3. Execute procedure Send_Label (MsgSource, FEC, SAt- tributes). 4. Is LSR egress for FEC? OR Has LSR previously received and retained a label map- ping for FEC from Next Hop? If so, goto LRq.11. If not, goto LRq.10. For Downstream Unsolicited Ordered Control OR For Downstream On Demand Ordered Control 1. Is LSR egress for FEC? OR Has LSR previously received and retained a label map- ping for FEC from Next Hop? (See Note 3.) If not, goto LRq.10. 2. Execute procedure Prepare_Label_Map- ping_Attributes(MsgSource, FEC, RAttributes, SAt- tributes, IsPropagating, StoredHopCount) 3. Execute procedure Send_Label (MsgSource, FEC, SAt- tributes). Goto LRq.11. The code: // FEC.1 LSR label distribution procedure if ( labeldiscipline() == 0 ) { // unsolicited if ( labelcontrol() == 0 ) { // independendent control for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = nextsource() ) { // iterate for each peer peer = itfc->daddr(); propagating_ = find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 0, nhop, fec, -1); prepare_label_mapping_attributes(peer, fec, initatt, satt, propagating_, 0); send_label(peer, fec, satt); } } else { // ordeder control for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = nextsource() ) { // iterate for each peer peer = itfc->daddr(); if ( lsr_isegress(fec) || find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 0, nhop, fec, -1) ) { recatt = getatt_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, nhop, fec, -1); recatt == 0 ? storedhcount = 0 : storedhcount = recatt->hopcount(); // ### we have here propagating_ not being initialized above prepare_label_mapping_attributes(peer, fec, initatt, satt, propagating_, storedhcount); send_label(peer, fec, satt); } } } } As you see, propagating_ is set in the upper side and used in prepare_label_mapping_attributes but this function is used too in the lower side not being previously set as in the upper side. >Hop count is incremented and then copied in PMpA.7. That means the value >left in RAttribute is the incremented value. The wording is quite clear, >given a >number of other ways it could have been put. > >The value is next used in PMpA.18 (not 14) and it should be clear from >context, >that we are trying to determine if the value we would send (which is stored in >SAttribute) is different than the value we have previously sent. >Consequently, we >are comparing RAttribute->hopCount with prevHopCount, _because_ we know >from step PMpA.7 that the values RAttibute->hopCount=SAttribute->hopCount. > >Bear in mind that it is not the intention that this appendix is supposed >to be treated >as "pseudo-code". It may - in fact - include operations which are more or less >intentionally not exactly the same as might appear in a specific >implementation. RAttribute->Hop count is used also in 14 (see below). In here (14) is it the modified hop count too? A.2.8. Prepare_Label_Mapping_Attributes ......... PMpA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. See Note 2. Goto PMpA.9. PMpA.8 Include Hop Count of unknown (0) in SAttributes. PMpA.9 Is Loop Detection configured on LSR? If not, goto PMpA.21. PMpA.10 Do RAttributes have a Path Vector? If so, goto PMpA.19. PMpA.11 Is LSR propagating a received Label Mapping? If not, goto PMpA.20. PMpA.12 Does LSR support merging? If not, goto PMpA.14. PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer? If not, goto PMpA.20. PMpA.14 Do RAttributes include a Hop Count? <<<---- original hop count?? If not, goto PMpA.21. PMpA.15 Is Hop Count in Rattributes unknown(0)? If so, goto PMpA.20. >Understand that FTN, ILM, NHLFE, etc. are terms used in various MPLS >specifications to describe the internal logical operations as they must appear >externally. There are any number of ways that the actual implementation may >be done so that it looks - from outside the box - as if it is done this way. > >I believe that "installing the label" is fairly clear, but to make it even >clearer, >it means the following: > >1) if this LSR is an intermediate LSR with respect to the LSP for which >this > label is defined, do whatever it is in your implementation that > corresponds > to adding a new (or modifying an existing) ILM to point to an NHLFE that > includes the corresponding downstream next hop, label, encaps, etc. >2) if this LSR is an ingress LSR with respect to the LSP for which a >label is > being defined, do whatever it is in your implementation that corresponds > to adding a new (or modifying an existing) FTN to point to an NHLFE that > includes the corresponding downstream next hop, label, encaps, etc. >3) if this LSR is an (effective) egress LSR with respect to the LSP for >which a > label is being defined, do whatever it is in your implementation that > corresponds > to either adding a new (or modifying an existing) ILM to point to an NHLFE > that includes the corresponding downstream next hop, encaps, etc. - and no > label - or an ILM that instructs the receiving hardware to strip the > label and > present the remaining packet for further processing (depending on whether > the label stripped was the bottom of the label stack). > >In essense, instead of saying "do whatever it is ...", the specification >says "install >the label". I believe this is reasonable license. Ok, very clear. I think I have to advance a little bit more with my code to understand this better. >-- >Eric Best regards, Leonardo Balliache _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 20 05:24:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13651; Wed, 20 Oct 2004 05:24:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCuM-0003eS-6M; Wed, 20 Oct 2004 05:37:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9Iy-0003T5-R2; Wed, 20 Oct 2004 01:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK6FV-0005zv-VO for mpls@megatron.ietf.org; Tue, 19 Oct 2004 22:30:50 -0400 Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17709 for ; Tue, 19 Oct 2004 22:30:42 -0400 (EDT) Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r3.8.) id 6.1af.c3e7a2e (16237); Tue, 19 Oct 2004 22:30:01 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in03.mx.aol.com (v101_r1.6) with ESMTP id MAILININ31-3f6d4175cda822e; Tue, 19 Oct 2004 22:30:01 -0400 Message-ID: <4175CDA5.5060001@netscape.net> Date: Tue, 19 Oct 2004 22:29:57 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Leonardo Balliache Subject: Re: [mpls] Some question about LDP References: <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> In-Reply-To: <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@graiymage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: 7bit Leonardo, Let me see if I understand you. You're asking me to review your code? :-) (-: :-) (-: :-) Try breaking this into steps and ask about the steps that aren't clear. So far, you've copied a section out of the appendix (twice) and said that you don't understand it. Please be specific as to what it is you don't understand. Trying to make sense out of your code fragment - which is clearly not 100% exactly congruent with the procedural steps and is out of context as well - just gives me a huge headache. The reason why the procedure is not meant to be pseudo code is that it describes what it is that the implementation is supposed to do. There is no strict ordering or contextual mapping of the things your implementation has to do to the way in which your implementation does them. If you take a broad look at how many ways there are to do the rest of the things that any label switching implementation might do, you will quickly realize how pointless it would be to try to cover all the ways in which this particular set of "steps" might be done. As for PMpA.14 - it asks if there _is_ a hop count. For that purpose, it is irrelevant whether it is the incremented or unincremented value. In any case, I believe you understand the gist of that section. -- Eric Leonardo Balliache wrote: > Eric, > > Thanks a lot for your answer. But let me the right to insist: > >> I am not sure what the question related to in all the steps included, >> but >> the setting of control mode is a "local" phenom and the fact that the >> local >> LSR is operating in independent control does not prevent it from getting >> label requests from upstream LSRs, or label mappings from downstream >> LSRs that _are_ operating in ordered control mode. > > > I think I didn't explain well. Here I copy again the spec and my code. > I understand that the spec is not a pseudo-code but it is so specific > that I'm not sure (I'm trying yet to understand well the logic) if > this observation is important: > > The spec: > > A.1.1. Receive Label Request > > ........... > > LRq.9 Perform LSR Label Distribution procedure: > > For Downstream Unsolicited Independent Control OR > For Downstream On Demand Independent Control > > 1. Has LSR previously received and retained a label map- > ping for FEC from Next Hop?. > Is so, set Propagating to IsPropagating. > If not, set Propagating to NotPropagating. > > 2. Execute procedure Prepare_Label_Map- > ping_Attributes(MsgSource, FEC, RAttributes, SAt- > tributes, Propagating, StoredHopCount). > > 3. Execute procedure Send_Label (MsgSource, FEC, SAt- > tributes). > > 4. Is LSR egress for FEC? OR > Has LSR previously received and retained a label map- > ping for FEC from Next Hop? > If so, goto LRq.11. > If not, goto LRq.10. > > For Downstream Unsolicited Ordered Control OR > For Downstream On Demand Ordered Control > > 1. Is LSR egress for FEC? OR > Has LSR previously received and retained a label map- > ping for FEC from Next Hop? (See Note 3.) > If not, goto LRq.10. > > 2. Execute procedure Prepare_Label_Map- > ping_Attributes(MsgSource, FEC, RAttributes, SAt- > tributes, IsPropagating, StoredHopCount) > > 3. Execute procedure Send_Label (MsgSource, FEC, SAt- > tributes). > Goto LRq.11. > > > The code: > > // FEC.1 LSR label distribution procedure > if ( labeldiscipline() == 0 ) { // unsolicited > if ( labelcontrol() == 0 ) { // independendent control > for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = > nextsource() ) { // iterate for each peer peer = > itfc->daddr(); > propagating_ = find_ldp2rec(LDP2_LabelMappingMSG, > LDP2_RECEIVED, 0, nhop, fec, -1); > prepare_label_mapping_attributes(peer, fec, initatt, satt, > propagating_, 0); > send_label(peer, fec, satt); > } > } > else { // ordeder control > for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = > nextsource() ) { // iterate for each peer > peer = itfc->daddr(); > if ( lsr_isegress(fec) || > find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 0, > nhop, fec, -1) ) { > recatt = getatt_ldp2rec(LDP2_LabelMappingMSG, > LDP2_RECEIVED, nhop, fec, -1); > recatt == 0 ? storedhcount = 0 : storedhcount = > recatt->hopcount(); > // ### we have here propagating_ not being initialized above > prepare_label_mapping_attributes(peer, fec, initatt, satt, > propagating_, storedhcount); > send_label(peer, fec, satt); > } > } > } > } > > As you see, propagating_ is set in the upper side and used in > prepare_label_mapping_attributes but this function is used too in the > lower side not being previously set as in the upper side. > >> Hop count is incremented and then copied in PMpA.7. That means the value >> left in RAttribute is the incremented value. The wording is quite >> clear, given a >> number of other ways it could have been put. >> >> The value is next used in PMpA.18 (not 14) and it should be clear >> from context, >> that we are trying to determine if the value we would send (which is >> stored in >> SAttribute) is different than the value we have previously sent. >> Consequently, we >> are comparing RAttribute->hopCount with prevHopCount, _because_ we know >> from step PMpA.7 that the values >> RAttibute->hopCount=SAttribute->hopCount. >> >> Bear in mind that it is not the intention that this appendix is >> supposed to be treated >> as "pseudo-code". It may - in fact - include operations which are >> more or less >> intentionally not exactly the same as might appear in a specific >> implementation. > > > RAttribute->Hop count is used also in 14 (see below). In here (14) is > it the modified hop count too? > > A.2.8. Prepare_Label_Mapping_Attributes > > ......... > > PMpA.7 Increment RAttributes Hop Count and copy the resulting > Hop Count to SAttributes. See Note 2. Goto PMpA.9. > > PMpA.8 Include Hop Count of unknown (0) in SAttributes. > > PMpA.9 Is Loop Detection configured on LSR? > If not, goto PMpA.21. > > PMpA.10 Do RAttributes have a Path Vector? > If so, goto PMpA.19. > > PMpA.11 Is LSR propagating a received Label Mapping? > If not, goto PMpA.20. > > PMpA.12 Does LSR support merging? > If not, goto PMpA.14. > > PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer? > If not, goto PMpA.20. > > PMpA.14 Do RAttributes include a Hop Count? <<<---- original > hop count?? > If not, goto PMpA.21. > > PMpA.15 Is Hop Count in Rattributes unknown(0)? > If so, goto PMpA.20. > >> Understand that FTN, ILM, NHLFE, etc. are terms used in various MPLS >> specifications to describe the internal logical operations as they >> must appear >> externally. There are any number of ways that the actual >> implementation may >> be done so that it looks - from outside the box - as if it is done >> this way. >> >> I believe that "installing the label" is fairly clear, but to make it >> even clearer, >> it means the following: >> >> 1) if this LSR is an intermediate LSR with respect to the LSP for >> which this >> label is defined, do whatever it is in your implementation that >> corresponds >> to adding a new (or modifying an existing) ILM to point to an >> NHLFE that >> includes the corresponding downstream next hop, label, encaps, etc. >> 2) if this LSR is an ingress LSR with respect to the LSP for which >> a label is >> being defined, do whatever it is in your implementation that >> corresponds >> to adding a new (or modifying an existing) FTN to point to an >> NHLFE that >> includes the corresponding downstream next hop, label, encaps, etc. >> 3) if this LSR is an (effective) egress LSR with respect to the LSP >> for which a >> label is being defined, do whatever it is in your implementation >> that corresponds >> to either adding a new (or modifying an existing) ILM to point to >> an NHLFE >> that includes the corresponding downstream next hop, encaps, etc. >> - and no >> label - or an ILM that instructs the receiving hardware to strip >> the label and >> present the remaining packet for further processing (depending on >> whether >> the label stripped was the bottom of the label stack). >> >> In essense, instead of saying "do whatever it is ...", the >> specification says "install >> the label". I believe this is reasonable license. > > > Ok, very clear. I think I have to advance a little bit more with my > code to understand this better. > >> -- >> Eric > > > Best regards, > > Leonardo Balliache > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Oct 20 21:56:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08158; Wed, 20 Oct 2004 21:56:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKSNy-00011W-Jv; Wed, 20 Oct 2004 22:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIR3-0007En-1a; Wed, 20 Oct 2004 11:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHlV-0001ud-Kt; Wed, 20 Oct 2004 10:48:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11372; Wed, 20 Oct 2004 10:48:35 -0400 (EDT) Message-Id: <200410201448.KAA11372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:48:35 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ecmp-bcp-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Avoiding Equal Cost Multipath Treatment in MPLS Networks Author(s) : G. Swallow, et al. Filename : draft-ietf-mpls-ecmp-bcp-00.txt Pages : 0 Date : 2004-10-19 This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks and makes best practice recommendations for anyone defining an application to run over an MPLS network and wishes to avoid such treatment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ecmp-bcp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ecmp-bcp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ecmp-bcp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20105426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ecmp-bcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ecmp-bcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20105426.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Thu Oct 21 08:53:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20673; Thu, 21 Oct 2004 08:53:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcei-0000vh-A4; Thu, 21 Oct 2004 09:07:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbNs-0004j4-4X; Thu, 21 Oct 2004 07:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKYKg-0005X7-Si for mpls@megatron.ietf.org; Thu, 21 Oct 2004 04:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21302 for ; Thu, 21 Oct 2004 04:29:55 -0400 (EDT) Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly17a.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKYXA-0001AC-Kr for mpls@ietf.org; Thu, 21 Oct 2004 04:42:58 -0400 Received: from lon-sweeper.flagtelecom.com (mail.flagtelecom.com [62.216.151.5]) by rly17a.srv.mailcontrol.com (MailControl) with ESMTP id i9L8TNjn001248 for ; Thu, 21 Oct 2004 09:29:23 +0100 Received: from lon-email.flagtelecom.com (unverified) by lon-sweeper.flagtelecom.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 21 Oct 2004 09:26:44 +0100 Received: by lon-email.flagtelecom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Oct 2004 09:28:47 +0100 Message-ID: <2382535DE837D41186E100508BC75C11DC9392@dub-email.flagtelecom.com> From: "Khan, Amjad" To: "'mpls@ietf.org'" Date: Thu, 21 Oct 2004 09:12:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MailControl A-05-00-00 (www.mailcontrol.com) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [mpls] Authentication to validate MPLS ping request X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, Is there any mechanism to protect the MPLS ping requests? Any authentication mechanism on the udp port 3503. Thanks, Amjad ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster@flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 21 11:30:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13264; Thu, 21 Oct 2004 11:30:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKf5x-00062z-Un; Thu, 21 Oct 2004 11:43:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeka-0003yR-Ex; Thu, 21 Oct 2004 11:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeaB-0007l0-0z for mpls@megatron.ietf.org; Thu, 21 Oct 2004 11:10:27 -0400 Received: from apollo.serverbox.net (apollo.serverbox.net [207.58.128.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11333 for ; Thu, 21 Oct 2004 11:10:24 -0400 (EDT) Received: (qmail 24480 invoked from network); 21 Oct 2004 15:10:22 -0000 Received: from unknown (HELO PC.opalsoft.net) (201.243.149.192) by apollo.serverbox.net with SMTP; 21 Oct 2004 15:10:22 -0000 Message-Id: <5.2.1.1.0.20041021103121.00a12d00@opalsoft.net> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 21 Oct 2004 11:16:13 -0400 To: ewgray@graiymage.com From: Leonardo Balliache Subject: Re: [mpls] Some question about LDP In-Reply-To: <4175CDA5.5060001@netscape.net> References: <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Eric, At 10:29 p.m. 19-10-2004 -0400, you wrote: >Leonardo, > > Let me see if I understand you. You're asking me to review your code? > > :-) (-: :-) (-: :-) No, absolutely not. I thought the code could help to clear my question, but it is evident that it was a very bad idea. > Try breaking this into steps and ask about the steps that aren't clear. So >far, you've copied a section out of the appendix (twice) and said that you >don't understand it. Please be specific as to what it is you don't >understand. Trying to make sense out of your code fragment - which is >clearly not 100% >exactly congruent with the procedural steps and is out of context as well - >just gives me a huge headache. Sorry if I've bother you some way. > The reason why the procedure is not meant to be pseudo code is that >it describes what it is that the implementation is supposed to do. There is >no strict ordering or contextual mapping of the things your implementation >has to do to the way in which your implementation does them. If you take >a broad look at how many ways there are to do the rest of the things that >any label switching implementation might do, you will quickly realize how >pointless it would be to try to cover all the ways in which this particular >set of "steps" might be done. I agree, but perhaps the specification shouldn't be so specific. Working and revising the spec and coding it I have realized that you are right. Many questions are answered when one understand better the LDP logic. Talking about "Recognize New FECs", I insist that: 1.- In "unsolicited independent control" function "prepare_label_mapping_attribute" is called. This function requires the argument "propagating_" which is set (before calling the function) to true if the LSR has received previously a label mapping for fec from nexthop. It is set to false otherwise. 2.- In "unsolicited ordered control" the function "prepare_label_mapping" is also called. But this time the argument it needs (propagating_) is not previously set. Can I suppose that it should be false if the LSR is the egress for that fec and true if the LSR has received previously a label mapping for fec from nexthop? > As for PMpA.14 - it asks if there _is_ a hop count. For that purpose, >it is irrelevant whether it is the incremented or unincremented value. In any >case, I believe you understand the gist of that section. You are right, this is clear. >-- >Eric Best regards, Leonardo Balliache _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 21 15:42:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11942; Thu, 21 Oct 2004 15:42:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj2U-0004YF-Gn; Thu, 21 Oct 2004 15:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKidj-0004zR-Ub; Thu, 21 Oct 2004 15:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiYg-0000jS-UG for mpls@megatron.ietf.org; Thu, 21 Oct 2004 15:25:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10116 for ; Thu, 21 Oct 2004 15:25:08 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKilL-000486-Vg for mpls@ietf.org; Thu, 21 Oct 2004 15:38:17 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2004 15:24:39 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LJObxT020386; Thu, 21 Oct 2004 15:24:37 -0400 (EDT) Message-Id: <200410211924.i9LJObxT020386@rtp-core-1.cisco.com> To: mpls@ietf.org User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Oct 2004 15:24:37 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [mpls] Host Address FEC X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 We had originally agreed to remove the Host Address FEC on grounds of disuse, but this decision was deferred due to a liaison statement received from some forum which claims to have written specifications which depend on it. However, I find that liaison statement very confusing. In particular, the liaison states: "In RFC 3036, there is a semantic difference between a Host Address and a prefix with length 32. The new version proposes to remove the semantic difference. This is not a problem for the MPLS Proxy Admission Control; we are just requesting that the Host Address codepoint not be deprecated." This seems to be saying that they want the Host Address FEC to remain, but they don't care if its semantics are changed. That is somewhat peculiar. To me, it suggests that they are not actually using the Host Address FEC as it is specified in RFC 3036, but rather are overloading it to be used for another purpose entirely; in effect stealing the codepoint for a different use. One might think that the very fact that this codepoint is stealable is itself an indication of its lack of use. It seems to me then that we should just go ahead and remove the Host Address FEC from rfc2026bis. If some other organization needs a TLV whose usage has not been specified in any IETF document, they should follow the usual procedures and write an internet draft requesting a code point assignment. If they want to reuse an existing codepoint in the "IETF consensus" range, they should obtain IETF consensus. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 21 20:56:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17540; Thu, 21 Oct 2004 20:56:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnw2-0007t6-Ue; Thu, 21 Oct 2004 21:09:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl8s-0007hY-VK; Thu, 21 Oct 2004 18:10:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjDF-0007Tj-0y for mpls@megatron.ietf.org; Thu, 21 Oct 2004 16:07:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14950 for ; Thu, 21 Oct 2004 16:07:02 -0400 (EDT) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjPi-0005FE-DS for mpls@ietf.org; Thu, 21 Oct 2004 16:20:11 -0400 Received: from vkompellaxp ([192.168.2.8] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 13:06:16 -0700 From: "Vach Kompella" To: , Subject: RE: [mpls] Host Address FEC Date: Thu, 21 Oct 2004 13:06:18 -0700 Organization: Alcatel USA Message-ID: <019501c4b7a9$6ed16830$0802a8c0@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200410211924.i9LJObxT020386@rtp-core-1.cisco.com> Importance: Normal X-OriginalArrivalTime: 21 Oct 2004 20:06:16.0907 (UTC) FILETIME=[6C6411B0:01C4B7A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vach.kompella@alcatel.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Alternatively, it could mean that they use Host Address FEC as if it were a regular Prefix FEC, so the change in semantics is not material. In any case, they should clarify why they don't care if the semantics are changed, which may would help us decide if the request is meaningful. -Vach=20 > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Eric Rosen > Sent: Thursday, October 21, 2004 12:25 PM > To: mpls@ietf.org > Subject: [mpls] Host Address FEC=20 >=20 >=20 > We had originally agreed to remove the Host Address FEC =20 > on grounds of disuse, but this decision was deferred due to=20 > a liaison statement received from some forum which claims =20 > to have written specifications which depend on it.=20 >=20 > However, I find that liaison statement very confusing. In=20 > particular, the > liaison states:=20 >=20 > "In RFC 3036, there is a semantic difference between a=20 > Host Address and > a prefix with length 32. The new version proposes =20 > to remove the > semantic difference. This is not a problem for the MPLS=20 > Proxy Admission > Control; we are just requesting that the Host Address=20 > codepoint not be > deprecated." >=20 > This seems to be saying that they want the Host Address FEC=20 > to remain, but they don't care if its semantics are=20 > changed. That is somewhat peculiar. To me, it suggests that=20 > they are not actually using the Host Address FEC as it is=20 > specified in RFC 3036, but rather are overloading it to be=20 > used for another purpose entirely; in effect stealing the=20 > codepoint for a different use. One might think that the =20 > very fact that this codepoint is stealable is itself an=20 > indication of its lack of use. >=20 > It seems to me then that we should just go ahead and remove=20 > the Host Address FEC from rfc2026bis. If some other=20 > organization needs a TLV whose usage has not been specified =20 > in any IETF document, they should follow the usual=20 > procedures and write an internet draft requesting a code=20 > point assignment. If they want to reuse an existing=20 > codepoint in the "IETF consensus" range, they should obtain=20 > IETF consensus.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 21 21:20:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21588; Thu, 21 Oct 2004 21:20:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoJZ-0000H2-IP; Thu, 21 Oct 2004 21:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlVR-0007Br-Q5; Thu, 21 Oct 2004 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKke4-0005pP-4N for mpls@megatron.ietf.org; Thu, 21 Oct 2004 17:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04600 for ; Thu, 21 Oct 2004 17:38:49 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkqk-0002z3-5N for mpls@ietf.org; Thu, 21 Oct 2004 17:51:59 -0400 Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9LLcBnh014530 for ; Thu, 21 Oct 2004 17:38:11 -0400 Message-Id: <200410212138.i9LLcBnh014530@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: mpls@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Oct 2004 17:38:09 -0400 From: Markus Jork X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [mpls] new I-D draft-jork-ldp-igp-sync-00 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I'd like to make you aware of a new I-D posted recently which should be of interest to this wg. It addresses an operational problem in LDP networks, see abstract below. Comments are of course welcome and encouraged. Markus ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:48:05 -0400 Subject: I-D ACTION:draft-jork-ldp-igp-sync-00.txt List-Id: i-d-announce.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDP IGP Synchronization Author(s) : M. Jork, et al. Filename : draft-jork-ldp-igp-sync-00.txt Pages : 8 Date : 2004-10-18 In networks depending on edge-to-edge establishment of MPLS forwarding paths via LDP, blackholing of traffic can occur in situations where the IGP is operational on a link and thus the link is used for IP forwarding but LDP is not operational on that link for whatever reason. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.txt [...] ------- End of Forwarded Message _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 21 22:11:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00779; Thu, 21 Oct 2004 22:11:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKp6e-0002gr-O5; Thu, 21 Oct 2004 22:24:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoYZ-00089e-5I; Thu, 21 Oct 2004 21:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoDo-0001mJ-IQ for mpls@megatron.ietf.org; Thu, 21 Oct 2004 21:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23772 for ; Thu, 21 Oct 2004 21:27:57 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoQV-0000jC-PH for mpls@ietf.org; Thu, 21 Oct 2004 21:41:09 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i9M1RLBm047201; Thu, 21 Oct 2004 18:27:21 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9M1RKe33033; Thu, 21 Oct 2004 18:27:21 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 21 Oct 2004 18:27:20 -0700 (PDT) From: Ina Minei To: vach.kompella@alcatel.com Subject: RE: [mpls] Host Address FEC In-Reply-To: <019501c4b7a9$6ed16830$0802a8c0@eng.timetra.com> Message-ID: <20041021181549.N74899@garnet.juniper.net> References: <019501c4b7a9$6ed16830$0802a8c0@eng.timetra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Let us set aside for a moment the question of how the FEC is used. Once the Host FEC was defined, there is nothing to preclude use of it in many creative ways. If for example one needed to carry some kind of host information in LDP, would one define a new TLV, or just reuse the host address FEC? I would think the latter. Thus I don't think one should make the argument based on the use of the FEC. Ina On Thu, 21 Oct 2004, Vach Kompella wrote: > Alternatively, it could mean that they use Host Address FEC as if it > were a regular Prefix FEC, so the change in semantics is not material. > In any case, they should clarify why they don't care if the semantics > are changed, which may would help us decide if the request is > meaningful. > > -Vach > > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org > > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Eric Rosen > > Sent: Thursday, October 21, 2004 12:25 PM > > To: mpls@ietf.org > > Subject: [mpls] Host Address FEC > > > > > > We had originally agreed to remove the Host Address FEC > > on grounds of disuse, but this decision was deferred due to > > a liaison statement received from some forum which claims > > to have written specifications which depend on it. > > > > However, I find that liaison statement very confusing. In > > particular, the > > liaison states: > > > > "In RFC 3036, there is a semantic difference between a > > Host Address and > > a prefix with length 32. The new version proposes > > to remove the > > semantic difference. This is not a problem for the MPLS > > Proxy Admission > > Control; we are just requesting that the Host Address > > codepoint not be > > deprecated." > > > > This seems to be saying that they want the Host Address FEC > > to remain, but they don't care if its semantics are > > changed. That is somewhat peculiar. To me, it suggests that > > they are not actually using the Host Address FEC as it is > > specified in RFC 3036, but rather are overloading it to be > > used for another purpose entirely; in effect stealing the > > codepoint for a different use. One might think that the > > very fact that this codepoint is stealable is itself an > > indication of its lack of use. > > > > It seems to me then that we should just go ahead and remove > > the Host Address FEC from rfc2026bis. If some other > > organization needs a TLV whose usage has not been specified > > in any IETF document, they should follow the usual > > procedures and write an internet draft requesting a code > > point assignment. If they want to reuse an existing > > codepoint in the "IETF consensus" range, they should obtain > > IETF consensus. > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Oct 21 22:27:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02456; Thu, 21 Oct 2004 22:27:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpLp-00033I-Mo; Thu, 21 Oct 2004 22:40:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoyT-0006Rq-2o; Thu, 21 Oct 2004 22:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKol0-00036w-FJ for mpls@megatron.ietf.org; Thu, 21 Oct 2004 22:02:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29399 for ; Thu, 21 Oct 2004 22:02:14 -0400 (EDT) Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoxi-0002Lo-MR for mpls@ietf.org; Thu, 21 Oct 2004 22:15:27 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9M21h1l003657 for ; Thu, 21 Oct 2004 22:01:43 -0400 (EDT) Received: from sonusmail03.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Thu, 21 Oct 2004 22:01:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-4" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Host Address FEC Date: Thu, 21 Oct 2004 22:01:42 -0400 Message-ID: Thread-Topic: [mpls] Host Address FEC Thread-Index: AcS3plw8yhoBKnriQQmLWZmWHweaCgAIwLrQ From: "Phelan, Tom" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Hi Eric, See inline ... Tom Phelan > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, October 21, 2004 3:25 PM > To: mpls@ietf.org > Subject: [mpls] Host Address FEC >=20 >=20 > We had originally agreed to remove the Host Address FEC =20 > on grounds of > disuse, but this decision was deferred due to a liaison=20 > statement received > from some forum which claims to have written specifications=20 > which depend on > it.=20 >=20 > However, I find that liaison statement very confusing. In=20 > particular, the > liaison states:=20 >=20 > "In RFC 3036, there is a semantic difference between a=20 > Host Address and > a prefix with length 32. The new version proposes =20 > to remove the > semantic difference. This is not a problem for the MPLS=20 > Proxy Admission > Control; we are just requesting that the Host Address=20 > codepoint not be > deprecated." >=20 > This seems to be saying that they want the Host Address FEC=20 > to remain, but > they don't care if its semantics are changed. That is=20 > somewhat peculiar. > To me, it suggests that they are not actually using the Host=20 > Address FEC as > it is specified in RFC 3036, but rather are overloading it=20 > to be used for > another purpose entirely; in effect stealing the codepoint =20 > for a different > use. One might think that the very fact that this codepoint=20 > is stealable is > itself an indication of its lack of use. No, you've got it backwards. We want the Host Address FEC to remain, = with its current syntax. The MPLS Forum protocol uses the Host Address = FEC as a host address, as it's intended in RFC 3036. The proposed = semantic change was to the Prefix Address FEC (not the Host Address FEC) = - to make a Prefix Address with a 32-bit prefix equivalent to a Host = Address FEC. This change, to make a Prefix Address FEC able to = substitute for a Host Address FEC has no effect on our protocol. The = MPLS Forum protocol needs to have the Host Address FEC as it is in RFC = 3036, and uses it in the spirit of its meaning there. >=20 > It seems to me then that we should just go ahead and remove=20 > the Host Address > FEC from rfc2026bis. If some other organization needs a TLV=20 > whose usage has > not been specified in any IETF document, they should =20 > follow the usual > procedures and write an internet draft requesting a code=20 > point assignment. > If they want to reuse an existing codepoint in the "IETF=20 > consensus" range, > they should obtain IETF consensus.=20 Well, what we actually need is a TLV whose usage *has* been specified in = an IETF document, and would like to see it continue to be specified. = Something vastly different than what you're saying here. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 03:54:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09827; Fri, 22 Oct 2004 03:54:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuSW-0000Nq-Ec; Fri, 22 Oct 2004 04:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKu5n-0007bg-Im; Fri, 22 Oct 2004 03:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKu1j-0005p9-KX for mpls@megatron.ietf.org; Fri, 22 Oct 2004 03:39:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09106 for ; Fri, 22 Oct 2004 03:39:53 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuET-0008UF-DM for mpls@ietf.org; Fri, 22 Oct 2004 03:53:06 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 22 Oct 2004 08:40:23 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Oct 2004 08:40:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] new I-D draft-jork-ldp-igp-sync-00 Date: Fri, 22 Oct 2004 08:40:22 +0100 Message-ID: Thread-Topic: [mpls] new I-D draft-jork-ldp-igp-sync-00 Thread-Index: AcS31YiAhVRWWjgoToKjHNqDLKlVcAALLH9A To: , X-OriginalArrivalTime: 22 Oct 2004 07:40:23.0093 (UTC) FILETIME=[6373BE50:01C4B80A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Markus, If I understand correctly, the basic idea here is to advertise a link = with an artificially high IGP metric until LDP labels have been = exchanged between peers across that link. This is to avoid labelled VPN = packets being black holed if for example the link is up but LDP tunnel = LSP labels have not been exchanged yet, or perhaps LDP has not been = configured at one end of a link. Is this problem not Independent Label Distribution specific? If this is = considered to be a problem then why not implement Ordered Label = Distribution Control, as per RFC3036: "For each FEC for which the LSR is = not the egress and no mapping exists, the LSR MUST wait until a label = from a downstream LSR is received before mapping the FEC and passing = corresponding labels to upstream LSRs."? This will have the same effect = as a PE will not receive a label from a downstream P to reach a remote = PE until labels for that LSP have been fully exchanged by each hop = across the path.=20 If a router implementation has to be changed anyway, instead of changing = the implementation to advertise an artificially high IGP metric until = "some time after LDP session establishment before declaring LDP fully = operational in order to allow for the exchange of label bindings", why = not implement ordered label distribution control? Either I am missing something or this draft proposes a fix to a problem = with independent label distribution that can already be avoided by using = ordered label distribution as per the RFC3036 standard. In addition, what about providers using RSVP-TE in parallel with LDP = signalling across the same link? If a router detects that LDP has failed = across a link and increases the IGP metric, this may cause CSPF to = calculate alternate paths for the TE tunnels using that link.=20 IMO a solution that effects the routing of native IP traffic and traffic = being carried by TE tunnels across a link because of an LDP problem is = not acceptable. Regards, Richard > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org]On > Behalf Of Markus Jork > Sent: 21 October 2004 22:38 > To: mpls@ietf.org > Subject: [mpls] new I-D draft-jork-ldp-igp-sync-00 >=20 >=20 > I'd like to make you aware of a new I-D posted recently which > should be of interest to this wg. It addresses an operational > problem in LDP networks, see abstract below. > Comments are of course welcome and encouraged. >=20 > Markus >=20 >=20 > ------- Forwarded Message >=20 > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Date: Tue, 19 Oct 2004 07:48:05 -0400 > Subject: I-D ACTION:draft-jork-ldp-igp-sync-00.txt > List-Id: i-d-announce.ietf.org >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : LDP IGP Synchronization > Author(s) : M. Jork, et al. > Filename : draft-jork-ldp-igp-sync-00.txt > Pages : 8 > Date : 2004-10-18 > =09 > In networks depending on edge-to-edge establishment of MPLS > forwarding paths via LDP, blackholing of traffic can occur in > situations where the IGP is operational on a link and thus the link > is used for IP forwarding but LDP is not operational on=20 > that link for > whatever reason. This document describes a mechanism to avoid > traffic loss due to this condition without introducing any protocol > changes. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.txt >=20 > [...] > ------- End of Forwarded Message >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 06:36:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20049; Fri, 22 Oct 2004 06:36:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwzZ-00035N-HT; Fri, 22 Oct 2004 06:49:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwiJ-0001gA-TO; Fri, 22 Oct 2004 06:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwdE-0000SB-Nq for mpls@megatron.ietf.org; Fri, 22 Oct 2004 06:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18827 for ; Fri, 22 Oct 2004 06:26:45 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwq0-0002sV-EY for mpls@ietf.org; Fri, 22 Oct 2004 06:40:01 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 12:23:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] new I-D draft-jork-ldp-igp-sync-00 Date: Fri, 22 Oct 2004 12:23:14 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C010ECF7D@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [mpls] new I-D draft-jork-ldp-igp-sync-00 Thread-Index: AcS31YiAhVRWWjgoToKjHNqDLKlVcAALLH9AAAbW6xA= From: "DECRAENE Bruno RD-CORE-ISS" To: , , X-OriginalArrivalTime: 22 Oct 2004 10:23:52.0776 (UTC) FILETIME=[3A7A9480:01C4B821] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Richard, With ordered label distribution, the ingress PE gains the knowledge of the MPLS/LDP failure. But it still has no mean to reroute the traffic. So that does not solve the problem described in the draft. (VPN traffic is still dropped). > IMO a solution that effects the routing of native IP traffic=20 > and traffic being carried by TE tunnels across a link because=20 > of an LDP problem is not acceptable. I understand your point and I don't like either using one protocole (IGP) to advertise another protocole (LDP) status/failure. However, I believe the "acceptability" may depend on what the network is used for:=20 - MPLS VPN only --> I rather agree with the draft point of view (better to reroute all protocoles) - multiservice: IP, MPLS LDP, MPLS TE/FRR --> I rather agree with you. All, This may not be specific to MPLS LDP. The problem seems to be the same with any other protocol that IPv4. For example with IPv6 (and single IGP topology) if IPv6 is disabled on a link or a router. Regards, Bruno > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of=20 > richard.spencer@bt.com > Sent: Friday, October 22, 2004 9:40 AM > To: mjork@avici.com; mpls@ietf.org > Subject: RE: [mpls] new I-D draft-jork-ldp-igp-sync-00 >=20 > Markus, >=20 > If I understand correctly, the basic idea here is to=20 > advertise a link with an artificially high IGP metric until=20 > LDP labels have been exchanged between peers across that=20 > link. This is to avoid labelled VPN packets being black holed=20 > if for example the link is up but LDP tunnel LSP labels have=20 > not been exchanged yet, or perhaps LDP has not been=20 > configured at one end of a link. >=20 > Is this problem not Independent Label Distribution specific?=20 > If this is considered to be a problem then why not implement=20 > Ordered Label Distribution Control, as per RFC3036: "For each=20 > FEC for which the LSR is not the egress and no mapping=20 > exists, the LSR MUST wait until a label from a downstream LSR=20 > is received before mapping the FEC and passing corresponding=20 > labels to upstream LSRs."? This will have the same effect as=20 > a PE will not receive a label from a downstream P to reach a=20 > remote PE until labels for that LSP have been fully exchanged=20 > by each hop across the path.=20 >=20 > If a router implementation has to be changed anyway, instead=20 > of changing the implementation to advertise an artificially=20 > high IGP metric until "some time after LDP session=20 > establishment before declaring LDP fully operational in order=20 > to allow for the exchange of label bindings", why not=20 > implement ordered label distribution control? >=20 > Either I am missing something or this draft proposes a fix to=20 > a problem with independent label distribution that can=20 > already be avoided by using ordered label distribution as per=20 > the RFC3036 standard. >=20 > In addition, what about providers using RSVP-TE in parallel=20 > with LDP signalling across the same link? If a router detects=20 > that LDP has failed across a link and increases the IGP=20 > metric, this may cause CSPF to calculate alternate paths for=20 > the TE tunnels using that link.=20 >=20 > IMO a solution that effects the routing of native IP traffic=20 > and traffic being carried by TE tunnels across a link because=20 > of an LDP problem is not acceptable. >=20 > Regards, > Richard >=20 > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org > > [mailto:mpls-bounces@lists.ietf.org]On > > Behalf Of Markus Jork > > Sent: 21 October 2004 22:38 > > To: mpls@ietf.org > > Subject: [mpls] new I-D draft-jork-ldp-igp-sync-00 > >=20 > >=20 > > I'd like to make you aware of a new I-D posted recently=20 > which should=20 > > be of interest to this wg. It addresses an operational=20 > problem in LDP=20 > > networks, see abstract below. > > Comments are of course welcome and encouraged. > >=20 > > Markus > >=20 > >=20 > > ------- Forwarded Message > >=20 > > To: i-d-announce@ietf.org > > From: Internet-Drafts@ietf.org > > Date: Tue, 19 Oct 2004 07:48:05 -0400 > > Subject: I-D ACTION:draft-jork-ldp-igp-sync-00.txt > > List-Id: i-d-announce.ietf.org > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : LDP IGP Synchronization > > Author(s) : M. Jork, et al. > > Filename : draft-jork-ldp-igp-sync-00.txt > > Pages : 8 > > Date : 2004-10-18 > > =09 > > In networks depending on edge-to-edge establishment of MPLS > > forwarding paths via LDP, blackholing of traffic can occur in > > situations where the IGP is operational on a link and=20 > thus the link > > is used for IP forwarding but LDP is not operational on=20 > that link=20 > > for > > whatever reason. This document describes a mechanism to avoid > > traffic loss due to this condition without introducing=20 > any protocol > > changes. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.txt > >=20 > > [...] > > ------- End of Forwarded Message > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 10:15:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07131; Fri, 22 Oct 2004 10:15:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0P2-0007G7-B3; Fri, 22 Oct 2004 10:28:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL06P-00013O-Uv; Fri, 22 Oct 2004 10:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzvz-0002QQ-UP for mpls@megatron.ietf.org; Fri, 22 Oct 2004 09:58:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04855 for ; Fri, 22 Oct 2004 09:58:20 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL08n-0006n6-53 for mpls@ietf.org; Fri, 22 Oct 2004 10:11:37 -0400 Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9MDvgnh029299; Fri, 22 Oct 2004 09:57:43 -0400 Message-Id: <200410221357.i9MDvgnh029299@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: richard.spencer@bt.com In-reply-to: Your message of "Fri, 22 Oct 2004 08:40:22 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Oct 2004 09:57:41 -0400 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Subject: Re: [mpls] new I-D draft-jork-ldp-igp-sync-00 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Richard, > Is this problem not Independent Label Distribution specific? If this > is considered to be a problem then why not implement Ordered Label > Distribution Control, as per RFC3036: "For each FEC for which the > LSR is not the egress and no mapping exists, the LSR MUST wait until > a label from a downstream LSR is received before mapping the FEC and > passing corresponding labels to upstream LSRs."? This will have the > same effect as a PE will not receive a label from a downstream P to > reach a remote PE until labels for that LSP have been fully exchanged > by each hop across the path. > Bruno already gave a good answer to this. Ordered control gives you the advantage that a PE would know that an LSP is not available. But LDP has to follow IP routing and can't take an alternative path so you'd still be stuck. > > In addition, what about providers using RSVP-TE in parallel with > LDP signalling across the same link? If a router detects that LDP > has failed across a link and increases the IGP metric, this may > cause CSPF to calculate alternate paths for the TE tunnels using > that link. > > IMO a solution that effects the routing of native IP traffic and > traffic being carried by TE tunnels across a link because of an LDP > problem is not acceptable. Clearly, the solution is not applicable to all networks. It's a good fit for some but might not be for others. There is an applicability section in the draft but it probably needs to be expanded a bit to talk about RSVP-TE use in the network in conjunction with LDP. That is indeed a good point you raise. The IGP distributes an IGP cost and a TE cost for a link. So one could raise the IGP cost but leave the TE cost in place which would prevent RSVP-TE tunnels from rerouting. Markus > Regards, > Richard > > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org > > [mailto:mpls-bounces@lists.ietf.org]On > > Behalf Of Markus Jork > > Sent: 21 October 2004 22:38 > > To: mpls@ietf.org > > Subject: [mpls] new I-D draft-jork-ldp-igp-sync-00 > > > > > > I'd like to make you aware of a new I-D posted recently which > > should be of interest to this wg. It addresses an operational > > problem in LDP networks, see abstract below. > > Comments are of course welcome and encouraged. > > > > Markus > > > > > > ------- Forwarded Message > > > > To: i-d-announce@ietf.org > > From: Internet-Drafts@ietf.org > > Date: Tue, 19 Oct 2004 07:48:05 -0400 > > Subject: I-D ACTION:draft-jork-ldp-igp-sync-00.txt > > List-Id: i-d-announce.ietf.org > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : LDP IGP Synchronization > > Author(s) : M. Jork, et al. > > Filename : draft-jork-ldp-igp-sync-00.txt > > Pages : 8 > > Date : 2004-10-18 > > > > In networks depending on edge-to-edge establishment of MPLS > > forwarding paths via LDP, blackholing of traffic can occur in > > situations where the IGP is operational on a link and thus the link > > is used for IP forwarding but LDP is not operational on > > that link for > > whatever reason. This document describes a mechanism to avoid > > traffic loss due to this condition without introducing any protocol > > changes. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.txt > > > > [...] > > ------- End of Forwarded Message > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 11:14:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12672; Fri, 22 Oct 2004 11:14:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1Kn-0000BE-Bq; Fri, 22 Oct 2004 11:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL15B-0002SJ-OZ; Fri, 22 Oct 2004 11:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL114-00017P-GK for mpls@megatron.ietf.org; Fri, 22 Oct 2004 11:07:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12315 for ; Fri, 22 Oct 2004 11:07:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1Dr-0008VL-MG for mpls@ietf.org; Fri, 22 Oct 2004 11:20:56 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2004 11:28:38 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9MF74xT028702; Fri, 22 Oct 2004 11:07:04 -0400 (EDT) Message-Id: <200410221507.i9MF74xT028702@rtp-core-1.cisco.com> To: Ina Minei Subject: Re: [mpls] Host Address FEC In-reply-to: Your message of Thu, 21 Oct 2004 18:27:20 -0700. <20041021181549.N74899@garnet.juniper.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 2004 11:07:04 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mpls@ietf.org, vach.kompella@alcatel.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Ina> Once the Host FEC was defined, there is nothing to preclude use of it Ina> in many creative ways. Protocol elements have both syntax and semantics; reusing an existing syntax for a new semantics is a change in the protocol. The purpose of the Host FEC was the following. Some folks insisted that they needed the labels to distinguish between the following two cases: - a packet destined for some software module in a given router; - a packet which is being tunneled to a given router for further forwarding. If you don't need to make this distinction based on the label, then obviously there's no reason to ever use the Host Address FEC. Why did people think they needed this distinction? Because they had some hardware which, after the initial label lookup, needed to decide whether to send the packet into the CPU-accessible memory, or whether to run it through the forwarding logic. The forwarding logic in question could look up a second label or an IP address, but could then only send the packet to an output card, not to the CPU. AS it turned out, the need for this distinction never showed up in practice, and no one actually originates Host Address FECs. To me, this suggests pretty strongly that it needs to be removed as part of the progression to draft standard. > If for example one needed to carry some kind of host information in LDP, > would one define a new TLV, or just reuse the host address FEC? It depends on whether one is trying to avoid the IETF process or not. If you are trying to carry some new kind of host information, shouldn't you present an internet-draft explaining that, and requesting a codepoint for that information? If we keep the Host FEC in as it is described in RFC 3036, it has an impact on all LDP implementations, whether or not those implementations provide features which have been specified in some other forum. Since those features, and the related use of the Host Address FEC, have not been presented to or approved by this WG, I don't understand how this can be kept as part of the IETF standard. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 11:25:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13490; Fri, 22 Oct 2004 11:25:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1Un-0000Ni-T2; Fri, 22 Oct 2004 11:38:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1GA-0006eR-Ai; Fri, 22 Oct 2004 11:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL17e-0003Cb-3X for mpls@megatron.ietf.org; Fri, 22 Oct 2004 11:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12661 for ; Fri, 22 Oct 2004 11:14:26 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1KR-0000A0-D1 for mpls@ietf.org; Fri, 22 Oct 2004 11:27:44 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2004 11:35:27 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9MFDq7K024766; Fri, 22 Oct 2004 11:13:52 -0400 (EDT) Message-Id: <200410221513.i9MFDq7K024766@rtp-core-2.cisco.com> To: "Phelan, Tom" Subject: Re: [mpls] Host Address FEC In-reply-to: Your message of Thu, 21 Oct 2004 22:01:42 -0400. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 2004 11:13:53 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Tom> The proposed semantic change was to the Prefix Address FEC (not the Tom> Host Address FEC) - to make a Prefix Address with a 32-bit prefix Tom> equivalent to a Host Address FEC. This change, to make a Prefix Tom> Address FEC able to substitute for a Host Address FEC has no effect on Tom> our protocol Tom, this is not a correct understanding. Eliminating the Host Address FEC does not have any effect whatsoever on the semantics of the Prefix Address FEC. Tom> The MPLS Forum protocol needs to have the Host Address FEC as it is in RFC Tom> 3036, and uses it in the spirit of its meaning there. So you say, but it doesn't seem that way to me. Maybe you should write an Internet Draft explaining how you intend to use it. Suppose the Host Address FEC is removed from RFC 3036, and you write an Internet Draft proposing that the codepoint be reused for an MPLS Forum protocol. Can you explain why that doesn't meet your needs? _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 12:21:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17823; Fri, 22 Oct 2004 12:21:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2Ne-0001Yn-5e; Fri, 22 Oct 2004 12:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL28E-0000Th-1i; Fri, 22 Oct 2004 12:19:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL23T-0006p3-4x for mpls@megatron.ietf.org; Fri, 22 Oct 2004 12:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17383 for ; Fri, 22 Oct 2004 12:14:11 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2GH-0001Ow-1l for mpls@ietf.org; Fri, 22 Oct 2004 12:27:29 -0400 Received: from granados (b2vpnpc182.avici.com [10.2.103.182]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id i9MGDRni030658; Fri, 22 Oct 2004 12:13:28 -0400 Message-ID: <053501c4b852$1217b870$9900a8c0@granados> From: "Don Troshynski" To: References: Subject: Re: [mpls] new I-D draft-jork-ldp-igp-sync-00 Date: Fri, 22 Oct 2004 12:13:29 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.5 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1127938705==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 This is a multi-part message in MIME format. --===============1127938705== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0532_01C4B830.8AADE650" This is a multi-part message in MIME format. ------=_NextPart_000_0532_01C4B830.8AADE650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard, Take a look at the following topology. A---B-----\ | | \ \ C D---E---F | | / / G---H-----/ The network uses ordered control to distribute labels. A and G are = egress for an LDP FEC that is sent to F. IP and LDP are enabled on all = the links. Preferred paths (due to IGP metrics) are F-E-D-B-A and = F-E-D-H-G. Metrics for E-B and E-H are high; so high that the second = best path for E to A/G is via F. As you well know, the path selection = for LDP follows the IGP. Disable LDP on the link between D and E. Should E withdraw the label to = F? It has no idea about LDP state on F-B and F-H and therefore the label = remains distributed on the "upstream" link even with ordered control. F = relies on the IGP to determine that traffic should be moved to F-B-A and = F-H-G, but the IGP is perfectly happy flowing along F-E-D-B-A and = F-E-D-H-G. F points to E and E points to F in this steady state. Go back to steady state. Reboot node E and node D. Traffic moves along = the paths E-F-B-A and E-F-H-G for the reboot period. At what time should = the traffic begin to flow along the preferred path? Even ordered control = even allows E to distribute to F before the D has completed label = distribution to E. Why should F converge onto the best IGP path = (creating the black hole yet again) before LDP is in sync? There are always protocol interactions that require two protocols to = have some level of sync and this is an important one. BTW -- WRT to you comment about RSVP-TE LSPs beign rerouted, recall that = RSVP-TE has a separate set of traffic engineering metrics such that it = is perfectly happy to stay on a link when the IGP metric is set high = according to Markus' draft. You can decouple these metrics from the IGP = metrics if you don't have lossless TE LSP reroutes. Don ----- Original Message -----=20 From: To: ; Sent: Friday, October 22, 2004 3:40 AM Subject: RE: [mpls] new I-D draft-jork-ldp-igp-sync-00 > Markus, >=20 > If I understand correctly, the basic idea here is to advertise a link = with an artificially high IGP metric until LDP labels have been = exchanged between peers across that link. This is to avoid labelled VPN = packets being black holed if for example the link is up but LDP tunnel = LSP labels have not been exchanged yet, or perhaps LDP has not been = configured at one end of a link. >=20 > Is this problem not Independent Label Distribution specific? If this = is considered to be a problem then why not implement Ordered Label = Distribution Control, as per RFC3036: "For each FEC for which the LSR is = not the egress and no mapping exists, the LSR MUST wait until a label = from a downstream LSR is received before mapping the FEC and passing = corresponding labels to upstream LSRs."? This will have the same effect = as a PE will not receive a label from a downstream P to reach a remote = PE until labels for that LSP have been fully exchanged by each hop = across the path.=20 >=20 > If a router implementation has to be changed anyway, instead of = changing the implementation to advertise an artificially high IGP metric = until "some time after LDP session establishment before declaring LDP = fully operational in order to allow for the exchange of label bindings", = why not implement ordered label distribution control? >=20 > Either I am missing something or this draft proposes a fix to a = problem with independent label distribution that can already be avoided = by using ordered label distribution as per the RFC3036 standard. >=20 > In addition, what about providers using RSVP-TE in parallel with LDP = signalling across the same link? If a router detects that LDP has failed = across a link and increases the IGP metric, this may cause CSPF to = calculate alternate paths for the TE tunnels using that link.=20 >=20 > IMO a solution that effects the routing of native IP traffic and = traffic being carried by TE tunnels across a link because of an LDP = problem is not acceptable. >=20 > Regards, > Richard >=20 > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org=20 > > [mailto:mpls-bounces@lists.ietf.org]On > > Behalf Of Markus Jork > > Sent: 21 October 2004 22:38 > > To: mpls@ietf.org > > Subject: [mpls] new I-D draft-jork-ldp-igp-sync-00 > >=20 > >=20 > > I'd like to make you aware of a new I-D posted recently which > > should be of interest to this wg. It addresses an operational > > problem in LDP networks, see abstract below. > > Comments are of course welcome and encouraged. > >=20 > > Markus > >=20 > >=20 > > ------- Forwarded Message > >=20 > > To: i-d-announce@ietf.org > > From: Internet-Drafts@ietf.org > > Date: Tue, 19 Oct 2004 07:48:05 -0400 > > Subject: I-D ACTION:draft-jork-ldp-igp-sync-00.txt > > List-Id: i-d-announce.ietf.org > >=20 > > A New Internet-Draft is available from the on-line=20 > > Internet-Drafts directories. > >=20 > >=20 > > Title : LDP IGP Synchronization > > Author(s) : M. Jork, et al. > > Filename : draft-jork-ldp-igp-sync-00.txt > > Pages : 8 > > Date : 2004-10-18 > >=20 > > In networks depending on edge-to-edge establishment of MPLS > > forwarding paths via LDP, blackholing of traffic can occur in > > situations where the IGP is operational on a link and thus the = link > > is used for IP forwarding but LDP is not operational on=20 > > that link for > > whatever reason. This document describes a mechanism to avoid > > traffic loss due to this condition without introducing any = protocol > > changes. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.txt > >=20 > > [...] > > ------- End of Forwarded Message > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > ------=_NextPart_000_0532_01C4B830.8AADE650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Richard,
 
Take a look at the following = topology.
 
A---B-----\
|   | \    = \
C   D---E---F
|   | /   =  /
G---H-----/
 
The network uses ordered control to distribute = labels. A=20 and G are egress for an LDP FEC that is sent to F. IP and LDP are = enabled on all=20 the links. Preferred paths (due to IGP metrics) are F-E-D-B-A and = F-E-D-H-G.=20 Metrics for E-B and E-H are high; so high that the second best path for = E to A/G=20 is via F. As you well know, the path selection for LDP follows the=20 IGP.

Disable LDP on the link between D and E. Should = E withdraw=20 the label to F? It has no idea about LDP state on F-B and F-H and = therefore the=20 label remains distributed on the "upstream" link even with ordered = control. F=20 relies on the IGP to determine that traffic should be moved to F-B-A and = F-H-G,=20 but the IGP is perfectly happy flowing along F-E-D-B-A and F-E-D-H-G. F = points=20 to E and E points to F in this steady state.

Go back to steady state. Reboot node E and node = D. Traffic=20 moves along the paths E-F-B-A and E-F-H-G for the reboot period. At what = time=20 should the traffic begin to flow along the preferred path? Even ordered = control=20 even allows E to distribute to F before the D has completed label = distribution=20 to E. Why should F converge onto the best IGP path (creating the black = hole yet=20 again) before LDP is in sync?

There are always protocol interactions that = require two=20 protocols to have some level of sync and this is an important = one.

BTW -- WRT to you comment about RSVP-TE LSPs = beign=20 rerouted, recall that RSVP-TE has a separate set of traffic engineering = metrics=20 such that it is perfectly happy to stay on a link when the IGP metric is = set=20 high according to Markus' draft. You can decouple these metrics from the = IGP=20 metrics if you don't have lossless TE LSP reroutes.

Don

----- Original Message -----
From: <richard.spencer@bt.com>
To: <mjork@avici.com>; = <mpls@ietf.org>
Sent: Friday, October 22, 2004 3:40 = AM
Subject: RE: [mpls] new I-D=20 draft-jork-ldp-igp-sync-00

> Markus,
>
> If I understand correctly, the = basic idea=20 here is to advertise a link with an artificially high IGP metric until = LDP=20 labels have been exchanged between peers across that link. This is to = avoid=20 labelled VPN packets being black holed if for example the link is up but = LDP=20 tunnel LSP labels have not been exchanged yet, or perhaps LDP has not = been=20 configured at one end of a link.
>
> Is this problem not=20 Independent Label Distribution specific? If this is considered to be a = problem=20 then why not implement Ordered Label Distribution Control, as per = RFC3036: "For=20 each FEC for which the LSR is not the egress and no mapping exists, the = LSR MUST=20 wait until a label from a downstream LSR is received before mapping the = FEC and=20 passing corresponding labels to upstream LSRs."? This will have the same = effect=20 as a PE will not receive a label from a downstream P to reach a remote = PE until=20 labels for that LSP have been fully exchanged by each hop across the = path.=20
>
> If a router implementation has to be changed anyway, = instead=20 of changing the implementation to advertise an artificially high IGP = metric=20 until "some time after LDP session establishment before declaring LDP = fully=20 operational in order to allow for the exchange of label bindings", why = not=20 implement ordered label distribution control?
>
> Either I = am=20 missing something or this draft proposes a fix to a problem with = independent=20 label distribution that can already be avoided by using ordered label=20 distribution as per the RFC3036 standard.
>
> In addition, = what=20 about providers using RSVP-TE in parallel with LDP signalling across the = same=20 link? If a router detects that LDP has failed across a link and = increases the=20 IGP metric, this may cause CSPF to calculate alternate paths for the TE = tunnels=20 using that link.
>
> IMO a solution that effects the = routing of=20 native IP traffic and traffic being carried by TE tunnels across a link = because=20 of an LDP problem is not acceptable.
>
> Regards,
>=20 Richard
>
> > -----Original Message-----
> > = From:=20 mpls-bounces@lists.ietf.org
>=20 > [mailto:mpls-bounces@lists.ietf.org]On
> > Behalf Of = Markus=20 Jork
> > Sent: 21 October 2004 22:38
> > To: mpls@ietf.org
> = > Subject:=20 [mpls] new I-D draft-jork-ldp-igp-sync-00
> >
> > =
>=20 > I'd like to make you aware of a new I-D posted recently = which
> >=20 should be of interest to this wg. It addresses an operational
> = >=20 problem in LDP networks, see abstract below.
> > Comments are = of course=20 welcome and encouraged.
> >
> > Markus
> > =
>=20 >
> > ------- Forwarded Message
> >
> > = To:=20 i-d-announce@ietf.org
> >=20 From: Internet-Drafts@ietf.org
> >=20 Date: Tue, 19 Oct 2004 07:48:05 -0400
> > Subject: I-D=20 ACTION:draft-jork-ldp-igp-sync-00.txt
> > List-Id:=20 i-d-announce.ietf.org
> >
> > A New Internet-Draft is = available from the on-line
> > Internet-Drafts = directories.
>=20 >
> >
> > Title : LDP IGP Synchronization
> = >=20 Author(s) : M. Jork, et al.
> > Filename :=20 draft-jork-ldp-igp-sync-00.txt
> > Pages : 8
> > Date = :=20 2004-10-18
> >
> > In networks depending on = edge-to-edge=20 establishment of MPLS
> >    forwarding paths = via LDP,=20 blackholing of traffic can occur in
> >    = situations=20 where the IGP is operational on a link and thus the link
>=20 >    is used for IP forwarding but LDP is not = operational on=20
> > that link for
> >    whatever=20 reason.  This document describes a mechanism to avoid
>=20 >    traffic loss due to this condition without = introducing=20 any protocol
> >    changes.
> > =
> >=20 A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.t= xt
> >
> > [...]
> > ------- = End of=20 Forwarded Message
> >
> >
> >
> > =
> > _______________________________________________
> = > mpls=20 mailing list
> > mpls@lists.ietf.org
>=20 > https://www1.ietf.org/mailman/listinfo/mpls
> >
>
>=20 _______________________________________________
> mpls mailing=20 list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> ------=_NextPart_000_0532_01C4B830.8AADE650-- --===============1127938705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1127938705==-- From mpls-bounces@ietf.org Fri Oct 22 12:45:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19505; Fri, 22 Oct 2004 12:45:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2kY-0001zC-SI; Fri, 22 Oct 2004 12:58:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2T1-0007TF-S9; Fri, 22 Oct 2004 12:40:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2NS-0005S7-O4 for mpls@megatron.ietf.org; Fri, 22 Oct 2004 12:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18763 for ; Fri, 22 Oct 2004 12:34:50 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2aE-0001lr-F3 for mpls@ietf.org; Fri, 22 Oct 2004 12:48:09 -0400 Received: from default.mail.com (unknown[12.46.111.109]) by comcast.net (rwcrmhc11) with SMTP id <2004102216341601300am6s1e> (Authid: agmalis@comcast.net); Fri, 22 Oct 2004 16:34:17 +0000 Message-Id: <6.1.2.0.2.20041022122624.083c4eb0@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 22 Oct 2004 12:34:14 -0400 To: erosen@cisco.com From: "Andrew G. Malis" Subject: Re: [mpls] Host Address FEC In-Reply-To: <200410221513.i9MFDq7K024766@rtp-core-2.cisco.com> References: <200410221513.i9MFDq7K024766@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Eric, >Tom> The proposed semantic change was to the Prefix Address FEC (not the >Tom> Host Address FEC) - to make a Prefix Address with a 32-bit prefix >Tom> equivalent to a Host Address FEC. This change, to make a Prefix >Tom> Address FEC able to substitute for a Host Address FEC has no effect on >Tom> our protocol > >Tom, this is not a correct understanding. Eliminating the Host Address FEC >does not have any effect whatsoever on the semantics of the Prefix Address >FEC. In Ina's first draft, the Prefix Address FEC was GOING TO change as a result of elimination of the Host Address FEC. Re-read her original draft and you'll see it in the list of proposed changes to RFC 3036. Both of those changes were backed out of the current draft. >Tom> The MPLS Forum protocol needs to have the Host Address FEC as it is >in RFC >Tom> 3036, and uses it in the spirit of its meaning there. > >So you say, but it doesn't seem that way to me. Maybe you should write an >Internet Draft explaining how you intend to use it. The document is publicly available at http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf . It could be copied into an internet draft, but that's just makework, since you can read the document right now with one click. >Suppose the Host Address FEC is removed from RFC 3036, and you write an >Internet Draft proposing that the codepoint be reused for an MPLS Forum >protocol. Can you explain why that doesn't meet your needs? Again, that's just unnecessary makework, plus makework to remove the FEC in the first place. Why are you so opposed to leaving it in place? Cheers, Andy _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 13:18:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21862; Fri, 22 Oct 2004 13:18:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3Gv-0002Zb-A8; Fri, 22 Oct 2004 13:32:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2zf-0001Fx-34; Fri, 22 Oct 2004 13:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2ts-00081U-If for mpls@megatron.ietf.org; Fri, 22 Oct 2004 13:08:24 -0400 Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21078 for ; Fri, 22 Oct 2004 13:08:19 -0400 (EDT) Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.8.) id 6.1b5.c3c3b43 (22682); Fri, 22 Oct 2004 13:07:32 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in04.mx.aol.com (v102.9) with ESMTP id MAILININ43-589a41793e53fe; Fri, 22 Oct 2004 13:07:31 -0400 Message-ID: <41793E4C.8020906@netscape.net> Date: Fri, 22 Oct 2004 13:07:24 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Leonardo Balliache , Ina Minei Subject: Re: [mpls] Some question about LDP References: <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041015101130.00a107d0@opalsoft.net> <5.2.1.1.0.20041019100446.00a1c8f0@opalsoft.net> <5.2.1.1.0.20041021103121.00a12d00@opalsoft.net> In-Reply-To: <5.2.1.1.0.20041021103121.00a12d00@opalsoft.net> X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@graiymage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1039315363==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 --===============1039315363== Content-Type: multipart/alternative; boundary="------------020808010809080507000800" --------------020808010809080507000800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Leonardo, Thanks for being persistent. :-) See below... -- Eric Leonardo Balliache wrote: > Eric, > > ... SNIP ... > > >> The reason why the procedure is not meant to be pseudo code is that >> it describes what it is that the implementation is supposed to do. >> There is >> no strict ordering or contextual mapping of the things your >> implementation >> has to do to the way in which your implementation does them. If you >> take >> a broad look at how many ways there are to do the rest of the things >> that >> any label switching implementation might do, you will quickly realize >> how >> pointless it would be to try to cover all the ways in which this >> particular >> set of "steps" might be done. > > > I agree, but perhaps the specification shouldn't be so specific. > Working and revising > the spec and coding it I have realized that you are right. Many > questions are answered > when one understand better the LDP logic. > > Talking about "Recognize New FECs", I insist that: > > 1.- In "unsolicited independent control" function > "prepare_label_mapping_attribute" is > called. This function requires the argument "propagating_" which is > set (before calling > the function) to true if the LSR has received previously a label > mapping for fec from > nexthop. It is set to false otherwise. > > 2.- In "unsolicited ordered control" the function > "prepare_label_mapping" is also called. > But this time the argument it needs (propagating_) is not previously > set. Can I suppose > that it should be false if the LSR is the egress for that fec and true > if the LSR has received > previously a label mapping for fec from nexthop? Okay, good question. In the Label Request case (LRq.9), careful reading will show that the value passed to a prepare label mapping attributes function is the "constant" isPropagating in the Ordered Control mode (sub-step 2). This step is not reached if the local LSR is not either the egress, or in receipt of a previous label from its next hop for the FEC. The wording difference is subtle, and easy to miss - but once you catch the difference, it is clear. The same applies in processing a Label Mapping (LMp.20, LMp.24 and LMp.29). You would only reach one of these steps if A) you are currently in the process of processing a Label Mapping (in which case you are - by definition - propagating). However, in the "Recognize New FEC" case - specifically FEC.1, Downstream Unsolicited Ordered Control, substep 2 - the value of the "variable" Propagating is not set (as it was in Downstream Unsolicited Independent Control). This is a good catch on your part, and may be an indication that either nobody has run into this mode (as is true for me), or they were able to figure it out (as is the case for you). In fact, the setting of "Propagating" should not be part of the iteration, since the local LSR has only one next hop for the given FEC, no matter how many upstream peers it may have. That being the case, it is silly to set this "variable" at each iteration. Also, as a result of that consideration, it is clear that all of the steps in FEC.1, Downstream Unsolicited Ordered Control, should be skipped if the local LSR is neither the egress nor in receipt of a Label Mapping from its next hop. Ina should fix this either by removing part of this section, or by changing it to read - FEC.1 Perform LSR Label Distribution procedure: For Downstream Unsolicited Independent Control 1. Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating. 2. Iterate through 5 for each Peer. 3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)). 4. Execute procedure Send_Label (Peer, FEC, SAttributes) 5. End iteration from 1. Goto FEC.2. For Downstream Unsolicited Ordered Control 1. Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, set Propagating to IsPropagating and Goto 3. If not, set Propagating to NotPropagating. 2. Is LSR egress for the FEC? If not, Goto 6. 3. Iterate through 5 for each Peer. 4. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount). 5. Execute procedure Send_Label (Peer, FEC, SAttributes) 6. End iteration from 1. Goto FEC.2. For Downstream On Demand Independent Control OR For Downstream On Demand Ordered Control 1. Goto FEC.2. (See Note 2.) > > ... SNIP ... > >> -- >> Eric > > > Best regards, > > Leonardo Balliache > > > > > > --------------020808010809080507000800 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Leonardo,

    Thanks for being persistent.  :-)

    See below...

--
Eric

Leonardo Balliache wrote:
Eric,

... SNIP ...


   The reason why the procedure is not meant to be pseudo code is that
it describes what it is that the implementation is supposed to do. There is
no strict ordering or contextual mapping of the things your implementation
has to do to the way in which your implementation does them.  If you take
a broad look at how many ways there are to do the rest of the things that
any label switching implementation might do, you will quickly realize how
pointless it would be to try to cover all the ways in which this particular
set of "steps" might be done.

I agree, but perhaps the specification shouldn't be so specific. Working and revising
the spec and coding it I have realized that you are right. Many questions are answered
when one understand better the LDP logic.

Talking about "Recognize New FECs", I insist that:

1.- In "unsolicited independent control" function "prepare_label_mapping_attribute" is
called. This function requires the argument "propagating_" which is set (before calling
the function) to true if the LSR has received previously a label mapping for fec from
nexthop. It is set to false otherwise.

2.- In "unsolicited ordered control" the function "prepare_label_mapping" is also called.
But this time the argument it needs (propagating_) is not previously set. Can I suppose
that it should be false if the LSR is the egress for that fec and true if the LSR has received
previously a label mapping for fec from nexthop?
Okay, good question. In the Label Request case (LRq.9), careful reading will show that the
value passed to a prepare label mapping attributes function is the "constant" isPropagating
in the Ordered Control mode (sub-step 2). This step is not reached if  the local LSR is
not either the egress, or in receipt of a previous label from its next hop for the FEC.

The wording difference is subtle, and easy to miss - but once you catch the difference,
it is clear.

The same applies in processing a Label Mapping (LMp.20, LMp.24 and LMp.29). You
would only reach one of these steps if A) you are currently in the process of processing a
Label Mapping (in which case you are - by definition - propagating).

However, in the "Recognize New FEC" case - specifically FEC.1, Downstream Unsolicited
Ordered Control, substep 2 - the value of the "variable" Propagating is not set (as it was in
Downstream Unsolicited Independent Control).  This is a good catch on your part, and may
be an indication that either nobody has run into this mode (as is true for me), or they were
able to figure it out (as is the case for you).

In fact, the setting of "Propagating" should not be part of the iteration, since the local LSR
has only one next hop for the given FEC, no matter how many upstream peers it may have.
That being the case, it is silly to set this "variable" at each iteration.  Also, as a result of that
consideration, it is clear that all of the steps in FEC.1, Downstream Unsolicited Ordered
Control, should be skipped if the local LSR is neither the egress nor in receipt of a Label
Mapping from its next hop.

Ina should fix this either by removing part of this section, or by changing it to read -

      FEC.1   Perform LSR Label Distribution procedure:

            For Downstream Unsolicited Independent Control

               1. Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If so, set Propagating to IsPropagating.
                  If not, set Propagating to NotPropagating.

               2. Iterate through 5 for each Peer.

               3. Execute procedure Prepare_Label_Mapping_Attributes
                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
                  Unknown hop count(0)).

               4. Execute procedure Send_Label (Peer, FEC, SAttributes)

               5. End iteration from 1.
                  Goto FEC.2.

            For Downstream Unsolicited Ordered Control

               1. Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If so, set Propagating to IsPropagating and Goto 3.
                  If not, set Propagating to NotPropagating.

               2. Is LSR egress for the FEC?
                  If not, Goto 6.

               3. Iterate through 5 for each Peer.

               4. Execute procedure Prepare_Label_Mapping_Attributes
                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
                  StoredHopCount).

               5. Execute procedure Send_Label (Peer, FEC, SAttributes)

               6. End iteration from 1.
                  Goto FEC.2.

            For Downstream On Demand Independent Control OR
            For Downstream On Demand Ordered Control

               1. Goto FEC.2.  (See Note 2.)

...  SNIP ...

--
Eric

Best regards,

Leonardo Balliache






--------------020808010809080507000800-- --===============1039315363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1039315363==-- From mpls-bounces@ietf.org Fri Oct 22 13:26:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22580; Fri, 22 Oct 2004 13:26:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3O3-0002hq-Du; Fri, 22 Oct 2004 13:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL31x-0002K5-EM; Fri, 22 Oct 2004 13:16:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2x3-0000dx-Aa for mpls@megatron.ietf.org; Fri, 22 Oct 2004 13:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21302 for ; Fri, 22 Oct 2004 13:11:36 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL39r-0002PN-8E for mpls@ietf.org; Fri, 22 Oct 2004 13:24:56 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2004 13:32:39 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9MHB4xT002164; Fri, 22 Oct 2004 13:11:04 -0400 (EDT) Message-Id: <200410221711.i9MHB4xT002164@rtp-core-1.cisco.com> To: "Andrew G. Malis" Subject: Re: [mpls] Host Address FEC In-reply-to: Your message of Fri, 22 Oct 2004 12:34:14 -0400. <6.1.2.0.2.20041022122624.083c4eb0@mail.comcast.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 2004 13:11:04 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d > In Ina's first draft, the Prefix Address FEC was GOING TO change as a > result of elimination of the Host Address FEC. I was getting ready to send her comments on that when it was brought to my attention that she had removed the changes. No change to the Address Prefix FEC is necessary. (I wrote the original text for section 2.1, and it was always my intention that the Host Address FEC be optional and easily removable, as I always thought it was a bad idea and had no plans to implement it.) > It could be copied into an internet draft, but that's just makework, since > you can read the document right now with one click. I think you mean that I can access the document with one click ;-) I believe that the liaison statement is really requesting a codepoint in an IETF protocol, to be used for a purpose which is specified in a non-IETF document. This is no different than any other attempt by non-IETF groups to extend IETF protocols, and I believe the usual process for that involves an internet-draft, as well as review within the IETF. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 14:07:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25538; Fri, 22 Oct 2004 14:07:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL420-0003Sp-6Z; Fri, 22 Oct 2004 14:20:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3nS-0000Nw-54; Fri, 22 Oct 2004 14:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3lB-0007UZ-Me for mpls@megatron.ietf.org; Fri, 22 Oct 2004 14:03:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25211 for ; Fri, 22 Oct 2004 14:03:26 -0400 (EDT) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3xz-0003NW-GJ for mpls@ietf.org; Fri, 22 Oct 2004 14:16:44 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r3.8.) id c.1b0.c4a4104 (22681); Fri, 22 Oct 2004 14:02:33 -0400 (EDT) Received: from [192.168.7.129] (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.197.198]) by air-in04.mx.aol.com (v102.9) with ESMTP id MAILININ42-589941794b38154; Fri, 22 Oct 2004 14:02:33 -0400 Message-ID: <41794B32.6030104@netscape.net> Date: Fri, 22 Oct 2004 14:02:26 -0400 From: Eric Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: erosen@cisco.com Subject: Re: [mpls] Host Address FEC References: <200410221711.i9MHB4xT002164@rtp-core-1.cisco.com> In-Reply-To: <200410221711.i9MHB4xT002164@rtp-core-1.cisco.com> X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.5 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@graiymage.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0083995340==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb --===============0083995340== Content-Type: multipart/alternative; boundary="------------010406090008020204020904" --------------010406090008020204020904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric, It may be rediculous to assert that we should remove something from the LDP specification because nobody is using it only to then say that - if someone is using it - they should use the usual IETF process to put it back in. The problem here is that an outside organization defined a dependency on a piece of the protocol then believed to be part of the standard. We could uphold the traditional IETF argument and say - "where then is the implementation?" However, if we want to do that, then I would strongly urge that we hold off pushing LDP to Draft Standard until we have "sufficient operational experience." The fact that we have other organizations who want to use some of the currently (at least allegedly) unimplemented features of the current specification is probable cause to suspect that the current Proposed Standard has not yet received enough of an experiential work-out. So, either we allow that an external dependency constitutes a "use" under the aegis of the IETF process, or we defer progressing the Proposed Standard at this time. -- Eric Gray Eric Rosen wrote: >>In Ina's first draft, the Prefix Address FEC was GOING TO change as a >>result of elimination of the Host Address FEC. >> >> > >I was getting ready to send her comments on that when it was brought to my >attention that she had removed the changes. No change to the Address Prefix >FEC is necessary. (I wrote the original text for section 2.1, and it was >always my intention that the Host Address FEC be optional and easily >removable, as I always thought it was a bad idea and had no plans to >implement it.) > > > >>It could be copied into an internet draft, but that's just makework, since >>you can read the document right now with one click. >> >> > >I think you mean that I can access the document with one click ;-) > >I believe that the liaison statement is really requesting a codepoint in an >IETF protocol, to be used for a purpose which is specified in a non-IETF >document. This is no different than any other attempt by non-IETF groups to >extend IETF protocols, and I believe the usual process for that involves an >internet-draft, as well as review within the IETF. > > > > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > --------------010406090008020204020904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Eric,

    It may be rediculous to assert that we should remove something from the
LDP specification because nobody is using it only to then say that - if someone
is using it - they should use the usual IETF process to put it back in.

    The problem here is that an outside organization defined a dependency on a
piece of the protocol then believed to be part of the standard. We could uphold
the traditional IETF argument and say - "where then is the implementation?"

    However, if we want to do that, then I would strongly urge that we hold off
pushing LDP to Draft Standard until we have "sufficient operational experience."
The fact that we have other organizations who want to use some of the currently
(at least allegedly) unimplemented features of the current specification is probable
cause to suspect that the current Proposed Standard has not yet received enough
of an experiential work-out.

    So, either we allow that an external dependency constitutes a "use" under the
aegis of the IETF process, or we defer progressing the Proposed Standard at
this time.

--
Eric Gray

Eric Rosen wrote:
In Ina's  first draft,  the Prefix Address  FEC was  GOING TO change  as a
result of elimination of the Host Address FEC. 
    

I was getting ready  to send her comments on that when  it was brought to my
attention that she had removed the changes.  No change to the Address Prefix
FEC is  necessary.  (I wrote the original  text for section 2.1,  and it was
always  my  intention that  the  Host Address  FEC  be  optional and  easily
removable,  as I  always thought  it was  a  bad idea  and had  no plans  to
implement it.) 

  
It could be copied into an internet draft, but that's just makework, since
you can read the document right now with one click. 
    

I think you mean that I can access the document with one click ;-)

I believe that the liaison statement  is really requesting a codepoint in an
IETF protocol,  to be used  for a purpose  which is specified in  a non-IETF
document.  This is no different than any other attempt by non-IETF groups to
extend IETF protocols, and I believe  the usual process for that involves an
internet-draft, as well as review within the IETF. 




_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
--------------010406090008020204020904-- --===============0083995340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0083995340==-- From mpls-bounces@ietf.org Fri Oct 22 14:41:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28030; Fri, 22 Oct 2004 14:41:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4YN-000454-9f; Fri, 22 Oct 2004 14:54:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4Ea-0008Ng-PS; Fri, 22 Oct 2004 14:33:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4Cn-0007gq-CU for mpls@megatron.ietf.org; Fri, 22 Oct 2004 14:32:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27337 for ; Fri, 22 Oct 2004 14:31:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4Pb-0003sY-TM for mpls@ietf.org; Fri, 22 Oct 2004 14:45:17 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2004 14:31:27 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9MIVO7K014254; Fri, 22 Oct 2004 14:31:24 -0400 (EDT) Message-Id: <200410221831.i9MIVO7K014254@rtp-core-2.cisco.com> To: ewgray@graiymage.com Subject: Re: [mpls] Host Address FEC In-reply-to: Your message of Fri, 22 Oct 2004 14:02:26 -0400. <41794B32.6030104@netscape.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 2004 14:31:24 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > It may be ridiculous to assert that we should remove something from the > LDP specification because nobody is using it only to then say that - if > someone is using it - they should use the usual IETF process to put it > back in. That is a somewhat misleading paraphrase of my position. I believe that they have specified a new use for a codepoint which has been assigned but not used, and I don't see why that should be treated any differently than a request for a new codepoint. Since they don't have deployment yet, this seems like a good time for them to fix their specs and remove the unfortunate dependency. It seems like there are many ways for them to do this, as there is no real dependency on the semantics of the Host Address FEC. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 15:10:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00351; Fri, 22 Oct 2004 15:10:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL50T-0004ZF-Qk; Fri, 22 Oct 2004 15:23:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4bg-0007Xm-2o; Fri, 22 Oct 2004 14:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4ZO-0006cw-OI for mpls@megatron.ietf.org; Fri, 22 Oct 2004 14:55:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29226 for ; Fri, 22 Oct 2004 14:55:19 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4mD-0004KX-FG for mpls@ietf.org; Fri, 22 Oct 2004 15:08:38 -0400 Received: from default.mail.com (unknown[12.46.111.109]) by comcast.net (rwcrmhc13) with SMTP id <2004102218543501500o5rk1e> (Authid: agmalis@comcast.net); Fri, 22 Oct 2004 18:54:36 +0000 Message-Id: <6.1.2.0.2.20041022144621.05494eb0@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 22 Oct 2004 14:54:32 -0400 To: erosen@cisco.com From: "Andrew G. Malis" Subject: Re: [mpls] Host Address FEC In-Reply-To: <200410221831.i9MIVO7K014254@rtp-core-2.cisco.com> References: <200410221831.i9MIVO7K014254@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Eric, It specifies a use for a codepoint documented in a published standards track RFC. It's no different than using a published codepoint in any other standards track RFC. There's no established WG consensus to remove the FEC from LDP. It was proposed in the initial revision of the 3036 update, but then the change was removed after several people spoke up in favor of retaining the FEC. If it turns out the WG consensus is to remove the FEC, then Ina will have to restore the two changes she removed, including changing the semantics of the Prefix Address FEC to provide equivalent functionality. But at this point, no such consensus exists. Cheers, Andy ----------- At 10/22/2004 02:31 PM -0400, Eric Rosen wrote: > > It may be ridiculous to assert that we should remove something from the > > LDP specification because nobody is using it only to then say that - if > > someone is using it - they should use the usual IETF process to put it > > back in. > >That is a somewhat misleading paraphrase of my position. > >I believe that they have specified a new use for a codepoint which has been >assigned but not used, and I don't see why that should be treated any >differently than a request for a new codepoint. > >Since they don't have deployment yet, this seems like a good time for them >to fix their specs and remove the unfortunate dependency. It seems like >there are many ways for them to do this, as there is no real dependency on >the semantics of the Host Address FEC. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 15:20:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01618; Fri, 22 Oct 2004 15:20:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5Ac-0004l3-B4; Fri, 22 Oct 2004 15:33:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4wg-0007JM-4c; Fri, 22 Oct 2004 15:19:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4vU-0006ly-J9 for mpls@megatron.ietf.org; Fri, 22 Oct 2004 15:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01350 for ; Fri, 22 Oct 2004 15:18:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL58J-0004iJ-Gf for mpls@ietf.org; Fri, 22 Oct 2004 15:31:28 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2004 15:39:11 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9MJHZxT002450; Fri, 22 Oct 2004 15:17:36 -0400 (EDT) Message-Id: <200410221917.i9MJHZxT002450@rtp-core-1.cisco.com> To: mjork@avici.com (Markus Jork) Subject: Re: [mpls] new I-D draft-jork-ldp-igp-sync-00 User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 2004 15:17:34 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I think you will find that the technique recommended by your draft is already implemented by at least one large vendor. As the draft proposes no protocol changes, it does not appear to be a candidate for standards track; what are your intentions for it? _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 15:55:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04356; Fri, 22 Oct 2004 15:55:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5im-0005WB-GO; Fri, 22 Oct 2004 16:09:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5LC-0001Cb-Q6; Fri, 22 Oct 2004 15:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5JL-0008NT-Lo for mpls@megatron.ietf.org; Fri, 22 Oct 2004 15:42:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03523 for ; Fri, 22 Oct 2004 15:42:48 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5W9-000593-HN for mpls@ietf.org; Fri, 22 Oct 2004 15:56:07 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2004 16:03:49 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9MJgC7K000753; Fri, 22 Oct 2004 15:42:13 -0400 (EDT) Message-Id: <200410221942.i9MJgC7K000753@rtp-core-2.cisco.com> To: "Andrew G. Malis" Subject: Re: [mpls] Host Address FEC In-reply-to: Your message of Fri, 22 Oct 2004 14:54:32 -0400. <6.1.2.0.2.20041022144621.05494eb0@mail.comcast.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 2004 15:42:12 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > If it turns out the WG consensus is to remove the FEC, then Ina will have > to restore the two changes she removed, including changing the semantics of > the Prefix Address FEC to provide equivalent functionality. We really need to get clear on the technical issue here. The ONLY difference between the Host Address FEC and an Address Prefix FEC which specifies a /32 is the following. If these two FECs are both present, and each is bound to a different LSP, then a packet whose IP destination address matches both of these FECs will be assigned to the LSP with the Host Address FEC. Further, a packet whose IP destination address does not match these FECS cannot be assigned to the LSP with the Host Address FEC, though it can be assigned to the LSP with the Address Prefix FEC (i.e., the LSP with the Host Address FEC can only be used for packets which are destined to the LSP egress, not for packets which are to be further forwarded by the LSP egress). Hence it simply does not make any sense to say that if the Host Address FEC is eliminated, the Address Prefix FEC needs to be changed to provide equivalent functionality! The reason for eliminating the Host Address FEC is to eliminate the associated functionality, because that functionality has never been used. It's already been stated that the MPLS Forum work could have used the Address Prefix FEC with a /32 prefix. If that's the case, then it is not using the Host Address FEC correctly. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 17:33:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21687; Fri, 22 Oct 2004 17:33:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7Ez-0002R1-GU; Fri, 22 Oct 2004 17:46:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6g6-00079s-Nb; Fri, 22 Oct 2004 17:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5kP-0000MF-L1 for mpls@megatron.ietf.org; Fri, 22 Oct 2004 16:10:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06238 for ; Fri, 22 Oct 2004 16:10:45 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5xE-0005qo-Tq for mpls@ietf.org; Fri, 22 Oct 2004 16:24:06 -0400 Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9MKA0nh023239; Fri, 22 Oct 2004 16:10:00 -0400 Message-Id: <200410222010.i9MKA0nh023239@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: erosen@cisco.com In-reply-to: Your message of "Fri, 22 Oct 2004 15:17:34 EDT." <200410221917.i9MJHZxT002450@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Oct 2004 16:09:57 -0400 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Subject: Re: [mpls] new I-D draft-jork-ldp-igp-sync-00 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > I think you will find that the technique recommended by your draft is > already implemented by at least one large vendor. Yes, I'm aware of that. And I also know of another existing implementation by a second vendor who isn't quite as large as the one you're thinking of :-) > As the draft proposes no protocol changes, it does not appear to be a > candidate for standards track; what are your intentions for it? I thought it would be a good service to the community to actually document this. I see the draft as a candidate for an Informational RFC just like RFC3137. Markus _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Oct 22 19:02:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10288; Fri, 22 Oct 2004 19:02:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8dd-00089A-J5; Fri, 22 Oct 2004 19:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7r2-0008J7-3r; Fri, 22 Oct 2004 18:25:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7Rp-0002H1-Ct for mpls@megatron.ietf.org; Fri, 22 Oct 2004 17:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27025 for ; Fri, 22 Oct 2004 17:59:40 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7ef-000491-4u for mpls@ietf.org; Fri, 22 Oct 2004 18:13:02 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9MLx9979477; Fri, 22 Oct 2004 14:59:09 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9MLx4e61525; Fri, 22 Oct 2004 14:59:04 -0700 (PDT) (envelope-from ina@juniper.net) Date: Fri, 22 Oct 2004 14:59:04 -0700 (PDT) From: Ina Minei To: Eric Rosen Subject: Re: [mpls] Host Address FEC In-Reply-To: <200410221942.i9MJgC7K000753@rtp-core-2.cisco.com> Message-ID: <20041022144815.B95080@garnet.juniper.net> References: <200410221942.i9MJgC7K000753@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f > > It's already been stated that the MPLS Forum work could have used the > Address Prefix FEC with a /32 prefix. If that's the case, then it is not > using the Host Address FEC correctly. I agree with you that to represent a host address, one could use an Address Prefix with a /32 prefix. However, one would then have to define the error handling for an incorrect length and the procedures that must be applied in case one expects to receive a host address but gets a length different than 32. Why not have a FEC that represents a host address in this case? Ina _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Oct 25 07:24:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15255; Mon, 25 Oct 2004 07:24:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3BS-00049r-Mf; Mon, 25 Oct 2004 07:38:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2uy-0003l6-AV; Mon, 25 Oct 2004 07:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2pM-0003Bw-IT for mpls@megatron.ietf.org; Mon, 25 Oct 2004 07:15:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14392 for ; Mon, 25 Oct 2004 07:15:49 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM32m-0003vj-32 for mpls@ietf.org; Mon, 25 Oct 2004 07:29:46 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFkO5027374; Mon, 25 Oct 2004 20:15:46 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFjYH027409; Mon, 25 Oct 2004 20:15:45 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFjCm027406; Mon, 25 Oct 2004 20:15:45 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFjOR012362; Mon, 25 Oct 2004 20:15:45 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFi7E012359; Mon, 25 Oct 2004 20:15:44 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFiV1007129; Mon, 25 Oct 2004 20:15:44 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFh8s013619; Mon, 25 Oct 2004 20:15:44 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PBFhXT013614; Mon, 25 Oct 2004 20:15:43 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA08116; Mon, 25 Oct 2004 20:15:43 +0900 (JST) Message-Id: <5.0.2.5.2.20041025200256.061fd088@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Mon, 25 Oct 2004 20:28:34 +0900 To: mpls@ietf.org From: Seisho Yasukawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: zali@cisco.com Subject: [mpls] Fwd: I-D ACTION:draft-yasukawa-mpls-p2mp-lsp-ping-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Hi, We have produced a preliminary draft for P2MP LSP ping/trace route extensions which we would like to discuss at upcoming IETF meeting. We are not sure whether our draft should be merged with original LSP ping draft at this moment. Please review the proposal and feedback your comments on this effort. Regards, Seisho >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Detecting Data Plane Failures in > Point-to-Multipoint MPLS > Traffic Engineering - Extensions to LSP Ping > Author(s) : S. Yasukawa, et al. > Filename : draft-yasukawa-mpls-p2mp-lsp-ping-00.txt > Pages : 18 > Date : 2004-10-19 > >Recent proposals have extended the scope of Multi-Protocol Label > Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) > to encompass point-to-multipoint (P2MP) TE LSPs. > > The requirement for a simple and efficient mechanism that can be > used to detect data plane failures in point-to-point (P2P) MPLS LSPs > has been recognized and has led to the development of techniques > for fault detection and isolation commonly referred to as "LSP Ping" > [LSP-PING]. > > This documents does not replace any of the mechanism of LSP Ping, but > clarifies their applicability to P2MP MPLS TE LSPs, and extends the > techniques and mechanisms of LSP Ping to the P2MP TE > environment. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-lsp-ping-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-yasukawa-mpls-p2mp-lsp-ping-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-yasukawa-mpls-p2mp-lsp-ping-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-20104852.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-yasukawa-mpls-p2mp-lsp-ping-00.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Oct 25 10:57:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02079; Mon, 25 Oct 2004 10:57:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6V0-0008Iq-PJ; Mon, 25 Oct 2004 11:11:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6AG-0003fd-Is; Mon, 25 Oct 2004 10:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM66M-0003LD-3Z for mpls@megatron.ietf.org; Mon, 25 Oct 2004 10:45:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01240 for ; Mon, 25 Oct 2004 10:45:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6Jm-000853-QO for mpls@ietf.org; Mon, 25 Oct 2004 10:59:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2004 10:45:05 -0400 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9PEj2WT016208; Mon, 25 Oct 2004 10:45:02 -0400 (EDT) Message-Id: <200410251445.i9PEj2WT016208@rtp-core-1.cisco.com> To: Ina Minei Subject: Re: [mpls] Host Address FEC In-reply-to: Your message of Fri, 22 Oct 2004 14:59:04 -0700. <20041022144815.B95080@garnet.juniper.net> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 25 Oct 2004 10:45:01 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 > I agree with you that to represent a host address, one could use > an Address Prefix with a /32 prefix. However, one would then have to > define the error handling for an incorrect length and the procedures that > must be applied in case one expects to receive a host address but gets a > length different than 32. Why not have a FEC that represents a host > address in this case? The question before us is not whether it would be good to have such a thing, but whether the Host Address FEC as defined in RFC 3036 is that thing. According to RFC 3036, if an LSP is associated with a host address FEC, then a packet can be assigend to that LSP only if the packet's destination IP address is the same as the "host address" of the FEC. As I have endeavored unsuccessfully to explain, this was intended for use when the egress PE needed to infer from a packet's incoming top label whether the packet is addressed to the egress PE or not. I believe that the MPLS Forum document in question does not adhere to the rules specified in section 2.1 of RFC 3036, and hence is in violation of the LDP spec. In effect, they are redefining the Host Address FEC to meet their needs. The only thing that enables them to get away with this is the fact that the Host Address FEC, as defined in RFC 3036, is not used. I don't care if they use a /32 Address Prefix FEC or if they define their own FEC that always has a /32 address. I just would like to follow the proper process here, and I think the proper process is for them to specify, in their own documents, the FEC they want, and then request a codepoint for it. Given that the Host Address FEC as specified in RFC 3036 is not used, I think it must be removed before progression to Draft Standard. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Oct 25 18:57:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07513; Mon, 25 Oct 2004 18:57:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDzk-0000mM-QO; Mon, 25 Oct 2004 19:11:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBU8-00040f-Fl; Mon, 25 Oct 2004 16:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB5t-0006qS-VA; Mon, 25 Oct 2004 16:05:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29680; Mon, 25 Oct 2004 16:05:27 -0400 (EDT) Message-Id: <200410252005.QAA29680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 25 Oct 2004 16:05:27 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsr-self-test-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 : Label Switching Router Self-Test Author(s) : G. Swallow, et al. Filename : draft-ietf-mpls-lsr-self-test-03.txt Pages : 14 Date : 2004-10-25 This document defines a means of self test for a Label-Switching Router (LSR) to verify that its dataplane is functioning for certain key Multi-Protocol Label Switching (MPLS) applications including unicast forwarding based on LDP [LDP] and traffic engineering tunnels based on [RSVP-TE]. A new Loopback FEC type is defined to allow an upstream neighbor to assist in the testing at very low cost. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] messages are extended to do the actually probing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-self-test-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-self-test-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsr-self-test-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-self-test-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-self-test-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162155.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Mon Oct 25 20:03:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21313; Mon, 25 Oct 2004 20:03:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMF1k-00054C-85; Mon, 25 Oct 2004 20:17:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEW6-0003vD-43; Mon, 25 Oct 2004 19:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDhF-0004od-Pu for mpls@megatron.ietf.org; Mon, 25 Oct 2004 18:52:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06389 for ; Mon, 25 Oct 2004 18:52:05 -0400 (EDT) Received: from [203.236.4.72] (helo=hqmail6.netswork.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDuh-0000Lr-4V for mpls@ietf.org; Mon, 25 Oct 2004 19:06:08 -0400 Received: from 203.236.1.20 by hq_smtp (InterScan E-Mail VirusWall NT); Mon, 25 Oct 2004 23:58:00 +0900 Received: from 132.151.6.71 by mail.sktelecom.com( <73e7ecc90dff@mail.sktelecom.com> ); Tue, 26 Oct 2004 00:03:17 +0900 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6AG-0003fd-SF; Mon, 25 Oct 2004 10:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM66M-0003LD-3Z for mpls@megatron.ietf.org; Mon, 25 Oct 2004 10:45:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01240 for ; Mon, 25 Oct 2004 10:45:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6Jm-000853-QO for mpls@ietf.org; Mon, 25 Oct 2004 10:59:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2004 10:45:05 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9PEj2WT016208; Mon, 25 Oct 2004 10:45:02 -0400 (EDT) From: =?EUC-KR?B?vcW/673E?= To: mpls@ietf.org Subject: Re : Re: [mpls] Host Address FEC MIME-Version: 1.0 Date: Tue, 26 Oct 2004 07:52:23 +0900 Message-ID: X-MIMETrack: Serialize by Router on HQ_MAIL6/SKTelecom(Release 6.5.3|September 14, 2004) at 2004-10-26 07:53:01 AM MIME-Version: 1.0 X-Spam-Score: 1.8 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1783172624==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --===============1783172624== Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable unsubscribe=20


----- Original Message -----
Fr= om : Eric Rosen (erosen@cisco.com)
SendTo : Ina Minei (ina@ju= niper.net)
CopyTo : mpls@ietf.org
Sent : 2004-10-25 11:= 58:19 PM
Subject : Re: [mpls] Host Address FEC

> I agree with you that to represent a host address, one could use
> an Address Prefix with a /32 prefix. However, one would then have to
> define the error handling for an incorrect length and the procedures t=
hat
> must be applied in case one expects to receive a host address but gets=
 a
> length different than 32. Why not have a FEC that represents a host
> address in this case?=20

The question before us is not whether it would be good to have such a thing,
but whether the Host Address FEC as defined in RFC 3036 is that thing.

According to RFC 3036, if an LSP is associated with a host address FEC, then
a packet  can be assigend  to that LSP  only if the packet's  destination IP
address is the same as the "host address" of the FEC.=20

As I  have endeavored unsuccessfully to  explain, this was  intended for use
when  the egress  PE needed  to  infer from  a packet's  incoming top  label
whether the packet is addressed to the egress PE or not.

I believe  that the MPLS Forum document  in question does not  adhere to the
rules specified in section 2.1 of RFC 3036, and hence is in violation of the
LDP spec.=20

In effect,  they are redefining  the Host Address  FEC to meet  their needs.
The only thing that enables them to  get away with this is the fact that the
Host Address FEC, as defined in RFC 3036, is not used.=20

I don't care  if they use a /32  Address Prefix FEC or if  they define their
own FEC  that always has  a /32  address.  I just  would like to  follow the
proper process here, and I think  the proper process is for them to specify,
in their own documents, the FEC  they want, and then request a codepoint for
it.=20

Given that  the Host Address  FEC as  specified in RFC  3036 is not  used, I
think it must be removed before progression to Draft Standard. =20






=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
= --===============1783172624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1783172624==-- From mpls-bounces@ietf.org Mon Oct 25 20:52:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25981; Mon, 25 Oct 2004 20:52:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFn9-00064I-Fq; Mon, 25 Oct 2004 21:06:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFYl-00062K-GN; Mon, 25 Oct 2004 20:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLdsz-0005jh-KM for mpls@megatron.ietf.org; Sun, 24 Oct 2004 04:37:57 -0400 Received: from web51407.mail.yahoo.com (web51407.mail.yahoo.com [206.190.38.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10266 for ; Sun, 24 Oct 2004 04:37:55 -0400 (EDT) Message-ID: <20041024083727.57833.qmail@web51407.mail.yahoo.com> Received: from [82.205.146.122] by web51407.mail.yahoo.com via HTTP; Sun, 24 Oct 2004 01:37:26 PDT Date: Sun, 24 Oct 2004 01:37:26 -0700 (PDT) From: noureen wajeh To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 25 Oct 2004 20:51:33 -0400 Subject: [mpls] mns simulator on linux X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 i am simulating MPLS-VPN .for this reason i want to use MNS simulator.i want to know that MNS simulator is compatible with LINUX 7.2. because in MNS documentation i have read that this module is extends by using SUN UNIX. Reply me earlier. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Oct 26 19:30:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26250; Tue, 26 Oct 2004 19:30:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMazg-0001r7-JU; Tue, 26 Oct 2004 19:44:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYym-0004VP-BR; Tue, 26 Oct 2004 17:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYKi-0005y8-75; Tue, 26 Oct 2004 16:54:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19173; Tue, 26 Oct 2004 16:54:17 -0400 (EDT) Message-Id: <200410262054.QAA19173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 16:54:17 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-07.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Detecting MPLS Data Plane Failures Author(s) : K. Kompella, G. Swallow Filename : draft-ietf-mpls-lsp-ping-07.txt Pages : 32 Date : 2004-10-26 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS 'echo request' and 'echo reply' for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-ping-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161104.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Fri Oct 29 16:18:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03198; Fri, 29 Oct 2004 16:18:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdR7-00085D-Bw; Fri, 29 Oct 2004 16:33:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNclX-0004zU-Dp; Fri, 29 Oct 2004 15:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcOq-0002vM-2o for mpls@megatron.ietf.org; Fri, 29 Oct 2004 15:27:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28161 for ; Fri, 29 Oct 2004 15:26:58 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcdA-0006hC-R5 for mpls@ietf.org; Fri, 29 Oct 2004 15:41:49 -0400 Received: from du-069-0564.access.clara.net ([217.158.156.55] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.34) id 1CNcOd-000GZK-Cd for mpls@ietf.org; Fri, 29 Oct 2004 20:26:48 +0100 Message-ID: <0dfe01c4bdea$8015dd50$5d919ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 29 Oct 2004 20:01:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [mpls] Heads-up Multi-area/AS work in CCAMP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hi all, I just wanted to give you a heads-up on the multi-area and multi-AS work being done in CCAMP and to solicit the MPLS WG's input on this. In the first instance, we would really appreciate review comments on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt. Send them to the authors, or to the CCAMP and/or MPLS mailing lists. But please, if you have an interest in this work, come along to the CCAMP meeting in Washington DC and voice your thoughts. Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sat Oct 30 15:05:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11763; Sat, 30 Oct 2004 15:05:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNymI-0007vm-Ck; Sat, 30 Oct 2004 15:20:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNyL2-0007fq-EM; Sat, 30 Oct 2004 14:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNyAe-0004ft-10; Sat, 30 Oct 2004 14:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10053; Sat, 30 Oct 2004 14:41:46 -0400 (EDT) Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNyP9-0007Oi-Ro; Sat, 30 Oct 2004 14:56:49 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmdd41840eef; Sun, 31 Oct 2004 02:43:17 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd417ef33e; Wed, 27 Oct 2004 07:34:36 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4417edfcc; Wed, 27 Oct 2004 07:34:36 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 27 Oct 2004 07:34:36 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYyp-0004X8-NK; Tue, 26 Oct 2004 17:35:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYKi-0005y8-75; Tue, 26 Oct 2004 16:54:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19173; Tue, 26 Oct 2004 16:54:17 -0400 (EDT) Message-Id: <200410262054.QAA19173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 16:54:17 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-07.txt X-BeenThere: mpls@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --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 : Detecting MPLS Data Plane Failures Author(s) : K. Kompella, G. Swallow Filename : draft-ietf-mpls-lsp-ping-07.txt Pages : 32 Date : 2004-10-26 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS 'echo request' and 'echo reply' for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-ping-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161104.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart--